Pinned Tweet
Assassin's Creed Valhalla - 170 GB, hour+ long download on Steam at 120 Mbit/s
With Via you are in game in <5 min with <5 gigs of data on disk.
Ubisoft's Anvil engine tech seems pretty good to me, good loading code and no fps stutters due to streaming.
perf 10x'd because you switched to boost's hash table, good one
my first job (on Amazon EFS's storage layer) was what you might call "TIGER STYLE" in a hybrid of ANSIC/C99 (e.g. we were allowed "//" comments, but not booleans because those embedded too much behavior, and certainly not dependencies)
it was originally written by some of the most wildly smart people i'd ever met: out of MIT CSAIL, working on wide-area storage network research, then sucked into Amazon -- led by the author of fftw.
i had interned on this team in college, where i was tasked with coming up with a predictive model for how capacity would be used in storage system. i wasn't allowed to use numpy because of the ban on adding dependencies (i did not, in fact, write a fast linear regression algorithm in pure python) and because of the deep research that these folks had done in numerical stability around floating point numbers
we had our code that touched disk, our own on-disk format (dbuf == "disk buffers") and our own network wire protocol (nbuf == "network buffers")
we had a stringent (but undocumented) style guide -- mutexes needed to be wrapped in their own C scope for visibility. we had a lot of "void *", wrappers around malloc/free that manually counted allocations, and one of them wrote an entire work-stealing async framework in this style.
the point is that these folks were the *most qualified* to write this code. joining this team, i thought that this was how all software was written -- and led to a lot of my thinking even today.
a few years later, folks cycled out, and we hired more ridiculously smart people (now out of MathWorks, yes boston was strong on this team) and they proposed moving us over to C++
this was seen as apocalyptic to me and some of the other old timers -- folks were recommending that we include... dynamic allocations?? boost as a dependency? if we started allowing these things, where would the performance slippery slope stop?
the C++ tides won, and i went off to become a product manager (for unrelated reasons). and, what happened?
performance like 10x'd.
why?
it turned out that the people writing these dependencies (e.g. hash tables in boost) had spent their entire careers working on this *one thing*, and deeply optimizing it for a variety of different hardware. this meant that, out of the box, many of these data structures would outperform our home-rolled ones in C and assembler.
when you go at it alone, you spread yourself too thin to build the best possible product, unless you're totally divorced from time constraints.
now, i'm still guilty of believing that it's better to just write the whole stack than include dependencies, but there are folks on the team who have helped me see the light, and it's helpful to have been in a professional setting on both sides of the tiger style world.
did allowing dynamic allocation reduce performance? probably.
did it allow us to move faster and deliver more value to our customers in shorter time? also probably true.
Regardless of how useful the tool is, I find reading the output of LLM's to be deeply unpleasant
I’m convinced that a large % of programmers don’t actually like computers.
As a side effect, are also perfectly happy to throw away their reasoning to a model as soon as they can.
I don’t get it, at ALL. Don’t you *LIKE* understanding the magic of the machine?
You do realize hand-programming (I hate that I even have to specify hand now) is fun…right?
I thought Starbucks sold coffee, why are they a software company?
We started 8090 a few years ago on the belief this motion would become widespread. We’ve been surprised by how fast it has taken hold. That said, it’s still so early in this game.
Software license revenue is $1T annually. Services and T&M consulting around those licenses is $4T annually.
All of this will merge into a new $5T super-category and whatever happens from there is anyone’s guess. But I applaud $SBUX for ripping off the bandaid - they clearly see the forest from the trees.
You'd think one of these days someone would ask fable to make something that doesn't already exist
not to down play the author's skill or anything, but this entire video reads like the parody microservices video but for 3d, is this really what people have to deal with?
youtube.com/watch?v=GMcPeHB3…
added the the EXRs from NASA for the galaxy background, naively using uncompressed texture formats puts this scene at 5+ GiB of VRAM
stumbled on Carl-August's "Late Cretaceous" map (66 million years ago) and was totally captivated so decided to spend some time building a little planet renderer for it from scratch
The last time I tried these services my biggest complaint was actually image quality, the compressed video is really quite horrible compared to native. That said we are firmly in the DLSS slop world at this point anyway so image quality sucks either way
you’ll get mad at me for saying this…but cloud gaming is so obviously more economically efficient than physical hardware I think it’s going to be the default soon.
your home console / pc is idle 90%+ of the day. meanwhile, data centers targets what, 5%, maybe at worst 10% idle.
every second a cloud gamer isn’t gaming, that hardware is being used for someone else, training, etc.
I think there should be a new measurement, something like cost-per effective FLOP hour that takes into account the TCO + effective utilization.
If a gamer spends $500 on a GPU, uses it for 3 years, but it’s only fully active ~5% of that period…the cost-per relative FLOP hour is crazy high! Meanwhile, a $50,000 datacenter GPU might have a *LOWER* cost-per FLOP hour just because the effective utilization is 90+%.
Looks like I was a couple years too early when I tried joining. Leadership and priorities must have changed a lot.
SpaceX has almost finished writing V1.0 of an in-house AI training stack in C that exact-maps to 220k GB300s with 800G NICs, making heavy use of pipeline parallelism and getting as close to bare metal as possible.
The potential speed improvement vs JAX for large training runs is over an order of magnitude.
You literally can't fix the code. The company has to be willing to cut and start over for a new release version, which none of them are. They'd prefer to waste their engineer's time on extremely expensive incremental tiny nudges on the existing system.



















