13,578 karma · joined May 15, 2013
> Being able to pay for _just_ email from a company that isn't also harvesting my mail contents for ad targeting and search relevance is honestly a huge relief to me.
GMail (consumer) stopped scanning your mail for ads personalization five years ago [1]. IIUC, the paid version already wasn't (never did?).
[1] https://blog.google/products/gmail/g-suite-gains-traction-in...
The unified memory support in CUDA (originally intended for Denver, IIRC) is mostly a response to people finding it too hard to decide (a la mmap, really).
So it's not that CUDA doesn't have these. It's that it does, but many people never have to understand anything beyond "there's a thing called malloc, and there's host and device".
DirectX and GL predated CUDA and already had opaque buffer allocation things (e.g., vertex buffers). Partly this was a function of limited fixed-function units, maximum sizes of frame buffers and texture dimensions, and so on.
But yes, CUDA had a memory model that wasn't necessarily "magic" but just like regular malloc and free, it's pretty obvious what it does. (And you just live with pinned memory, host <=> device copies, and so on).
My basic question would be: why not go back to flex/bison/yacc/whatever via C-FFI? (But I think it would still be bad, since you'll want to get to a Swift data structure for your ops and those will still have the Arc issues)
Can you say more about the parse tree impact on performance?
Is the expression left in a tree form and effectively "interpreted" from the AST for all points? Is that the critical path?
(I read the article hours ago and didn't notice you'd posted. Btw, I think we would have gotten better conversation if you had said "Hey, this is me! AMA" as a top-level comment)
Amusing typo :).
Billions of searches per year is just a weird metric that obscures what you'd actually want to know.
You could guesstimate DAU from qps by choosing a "queries per day" number (e.g., 10?) and assume the queries are done over just 8 hours. That's 1.25 queries per hour per user. Multiplying these terms out, you get ~500k DAU.
I wish companies wouldn't try to make something seem big by using "billions". It took me billions of nanoseconds to write this comment...
As feedback, I find that new executives, even with external credibility won't be able to get the "innovation heroes" to talk to them at first. You have to make time, make space, and follow through.
Don't just have a single all-hands meeting to say "Come to me with your stories of friction", but continually do "skip level meetings" and "meet the team 'lunches'". And then boost that signal personally.
If you want an organization to value the removal of friction and apathy, it requires the most senior executives to actually celebrate the groups that were fighting that fight. Otherwise, these folks would rather remain nameless and wait for this new executive to go away like all the rest have. They're already doing their job, and it's too emotionally taxing to believe that this new executive means what they said.
> The prototype delivers 100% heating at 5°F at double the efficiency, and 70% to 80% heating at -5°F and -10°F. DOE’s Oak Ridge National Laboratory validated the performance and efficiency of Lennox’s prototype.
> Lennox is one of nine manufacturers competing in the CCHP Technology Challenge. Its product and others that meet the CCHP Technology Challenge will undergo trials in cold climate regions over the next two years to demonstrate performance, efficiency, and comfort when applied in the field throughout a winter. Deployment and commercialization are planned for 2024.
So, conveniently, the F-150 is a tested, self-enclosed array of batteries :).
The article seems to focus on working too much due to fear of competition. I would add that working in a fast-paced field (the author is doing ML at the Vector Institute) can feel like you're always in competition, but that it's important to remind yourself that you can choose your topic of research (if you have some horrible advisor that dictates what you do, I'm sorry, but recommend you find someone / someplace else). Even within ML, there are tons of pockets that nobody is really working on. That does make it harder to publish though, as your work will be "weird" or "not very hot".
tl;dr: people should choose topics and fields that fit their desired work profile. If you decide to compete in a heavily competitive subject, expect a competitive environment.
EC2 has historically not focused much on instance boot time. We did for GCE and drove it down pretty heavily. The post here from fly has a good set of sequence diagrams for "what are the various phases of creating an instance from scratch" that are generally applicable.
I'll note though that different users have different targets. Some people care about "time from request to first instruction ticks over" while others only care about "time from request to ssh'able from the public internet". There's an interesting middle ground of "time from request to being able to talk to other services like GCS or S3".
It's not clear to me what the networking / discovery story is for a Fly Machine that is stopped and then starts. That is, how long does fly-proxy take to update (globally? within a metro?) to add and remove the new Fly Machine? I vaguely recall that only external endpoints support IPv4, so I assume Fly is reserving and registering the internal IPv6 endpoints in the more expensive "create" step and then "start" is just about propagating liveness.
For diversified investors, it's more valuable to have some of your companies return higher gains even if others don't work out. For an employee though, their income is totally concentrated in their one job.
The employees can be rational in not wanting investors, and the investors are rational in not wanting to invest in those firms (at terms the co-op would accept).
The table is also pernicious, as it shows cars sold in a year per model vs deaths in a year per model. Almost sounds legit, until you realize "no wait, sold per year doesn't matter, just how many were operating".
However, LLVM is extremely heavyweight. Which "latency" did you mean? Are you going to run these functions 1M times, so that the quality of the generated code is paramount (and you can afford really long compile time) or do you care more about "I hit enter and get the answer"? You can tune LLVM (disable almost all passes, use fast instruction selection) but it's really not focused on millisecond-ish compilation.
There are a lot of "simple JIT" libraries for the latter case (you just want to feed in a simple IR and get machine code out, do an okay job at register allocation, but nothing fancy). None of them has "won" and most only have C bindings (to my knowledge).
Edit to add: Dolby <anything> is also a bit of a fiasco. LG TVs went through multiple firmware updates to attempt to correctly negotiate Dolby Vision. I appreciate that they want to push audio / video quality, but it seems weird that the industry testing process for integration is so poor.
I think for Onkyo, they just fell in an awkward middle. Not as high end as Denon/Marantz/etc. and not as cheap as < cheapest thing you can find >. Combined with the drastic decrease in people "needing" receivers and speakers (many people now just get a sound bar, or Bluetooth speakers) and the market squeezed them.
So it's more like both groups knew what the other was doing, but LRBni was free to focus primarily on graphics and a clean slate, while the AVX folks shot for "SSE but wider, and a few more".
AVX-512 is sort of a franken-combo of what AVX3 would have been, plus many of the LRBni instructions that shipped in the poorly named MIC parts, plus some more (e.g., now including a VNNI dialect, bf16 ops, etc.).
Let's start with bytecode. It "requires" (except for AOT work) a warm-up / JIT phase that tends towards slower start times. This isn't hard and fast, but in practice it's true. (And when you search for "jvm startup", you end up at lots of pages about how to tune things to try to make this better). For some people, just as bad or even worse (remember, distributed system) is the impact that JIT-compilation and warm-up has on tail latencies. The static nature of most compiled languages mean this isn't a thing you worry about. You've got enough tail latency problems in your life, you don't need "oh hey, I just saw this loop for the Nth time, I took 10ms to hot compile it!".
That leads into the runtime and some of the language choices around it. Java GCs are generally fighting a harder problem than Go's GC, and with a very different tuning point. Java making everything an object and support classloading and so on, has real knock-on effects for the amount of work required to get high-quality, low-pause GC to work. This is much better today than it was in 2008 when the Go team started, but it's still the case that Go has an out-of-the-box better GC experience. Yes there exist special, tuned GCs (e.g., Azul's C4, Shenandoah) but Java GCs have to really be super clever compared to the fairly simple strategies that work in Go; I applaud the ingenuity in Java GC work, but if what you care about is "reasonably good at collecting memory, never pauses for long", the Go language decisions made the GC problem easier.
I think it's fair to ask "Shouldn't Google have just improved Java?", but I think you miss out on lots of the concurrency ergonomics. Again, this has to be compared to a decade ago. Especially post 2010 (Oracle acquisition) it was super unclear that you'd want to attempt to "bet on Java".
To be clear, I do think Go is at the wrong point on the language/type-system sophistication curve for my tastes. That said, I find myself shaking my head at most Java code, while looking at the Go code and thinking "sigh, lots of repetition. I hope one day that gets better, but at least it's obvious".