Not sure why you're picking apart the wording. They're clearly stating an opinion, and writing "seems like" makes it clear that it's an opinion. There is no "to me" but IMO it's implicit.
Maybe they've updated it in the last couple weeks and my comment is out of date - I hope so! Because the 5th option definitely wasn't there when I recently used it, and the 4th you're mentioning looks familiar but I'm pretty sure in that case to it didn't (used to?) write it to a file.
IMO it was mostly that people didn't want to rewrite (and maintain) their code for a new proprietary programming model they were unfamiliar with. People also didn't want to invest in hardware that could only run code written in CUDA.
Lots of people wanted (and Intel tried to sell, somewhat succesfully) something they could just plug-and-play and just run the parallel implementations they'd already written for supercomputes using x86. It seemed easier. Why invest all of this effort into CUDA when Intel are going to come and make your current code work just as fast as this strange CUDA stuff in a year or two.
Deep learning is quite different from the earlier uses of CUDA. Those use cases were often massive, often old, FORTRAN programs where to get things running well you had to write many separate kernels targeting each bit. And it all had to be on there to avoid expensive copies between GPU and CPU, and early CUDA was a lot less programmable than it is now, with huge performance penalties for relatively small "mistakes". Also many of your key contributers are scientists rather than profressional programmers who see programming as getting in the way of doing what they acutally want to do. They don't want to spend time completely rewriting their applications and optimizing CUDA kernels, they want to keep on with their incremental modifications to existing codebases.
Then deep learning came along and researchers were already using frameworks (Lua Torch, Caffe, Theano). The framework authors only had to support the few operations required to get Convnets working very fast on GPUs, and it was minimal effort for researchers to run. It grew a lot from there, but going from "nothing" to "most people can run their Convnet research" on GPUs was much eaiser for these frameworks than it was for any large traditional HPC scientific application.
It seems funny though: The advantages of GPGPU are so obvious and unambiguous compared to AI. But then again, with every new technology you probably also had management pushing to use technology_a for <enter something inappropriate for technology_a>.
Like in a few decades when the way we work with AI has matured and become completely normal it might be hard to imagine why people nowadays questioned its use. But they won't know about the million stupid uses of AI we're confronted with every day :)
> The advantages of GPGPU are so obvious and unambiguous
I remember being a bit surprised when I started reading about GPUs being tasked with processes that weren't what we'd previously understood to be their role (way before I heard of CUDA). For some reason that I don't recall, I was thinking about that moment in tech just the other day.
It wasn't always obvious that the earth rotated around the sun. Or that using a mouse would be a standard for computing. Knowledge is built. We're pretty lucky to stand atop the giants who came before us.
I didn't know about CUDA until however many years ago. Definitely didn't know how early it began. Definitely didn't know there was pushback when it was introduced. Interesting stuff.
I'm dealing with someone in 2026 insisting that everything has to be written in Python and rely on entirely torch.compile for acceleration rather than any bespoke GPU kernels. Times change, people don't.
The completely low information and amateur hour aspect of what our HPC Welfare Queens were pushing above was that a couple hours invested into coding Intel's Xeon Phi alternative to GPUs demonstrated the folly of their BS "recompile and run" strategy and any attempt to code the thing exposed how much better a design CUDA was than their series of APIs of The Month that followed*. And I was all but blacklisted by the HPC community over standing up to this and insisting on CUDA or I walk, my favorite quote was "You lack vision and you probably wouldn't have backed the Apollo program or Lewis and Clark." Good times, good times...
*But TBF Xeon Phi was not a complete disaster for if you coded it in assembler you could squeeze out Fermi class GPU performance. Good luck getting the "recompile and run" crowd to do that though as they segued from that to relying on compiler directives going forward and that's how NVDA got a decade+ headstart that should never have happened, but did. Today a lot of these sorts are insisting that because of autograd, everything should be written in Python and compiled with an autograd DSL like torch. I am so glad I am close to retirement on that front. I already trust coding agents more than I trust this mindset.
Phi was cool, I think it could have been leveraged into something great. Imagine all consumer CPUs coming with 512 little pentiums in them or something like that.
And ahead of GPUs in some ways at the time. But that was entirely squandered by their idiotic recompile and run marketing. There was some serious denial that thread blocks that could synchronize without thunking back to the CPU along with the intuitive nature of warp programming were pretty much a hardware mode against anything that couldn't do the equivalent.
But good luck explaining that to technical leaders who hadn't written a line of code in over a decade and yet somehow were in charge of things. People really need to consider the backstory here if they want to do better going forward, but I don't think they will. I think history is going to rhyme again.
Alas, Planets.nu has no source code available. That's OK if you just want to play, but I really always wanted to make some changes, and to self-host (like you kinda could in the original vga planets)
The UI and server are relatively simple though, so it should be a fun exercise to vibe-code a clone based on phost and openplanets.
> Fwiw nothing beats ‘implement the game logic in full (huge amounts of work) and with pruning on some heuristics look 50 moves ahead’. This is how chess engines work and how all good turn based game ai works.
For board games this is mostly true. For turn based games in general, it is not. It's certainly not true to say "all good turn based game ai" works like this.
Turn based games where multiple "moves" are allowed per turn can very quickly have far too many branches to look ahead more than a very small number of turns. On board games you might have something like Warhammer, or Blood Bowl where there are many possible actions and order of actions within a turn matters.
For computer games you may Screeps [2] or the Lux multi-agent AI competitions [3] which both have multiple "units" per player, where each unit may have multiple possible actions. You can easily reach a combinatorial explosion where any attempt at modeling future states of the world fails and you have to fall back on pure heuristics.
The person who wrote the post says that they can produce the same quality content in "2-3 days" instead of "several weeks", and that there are two people working in essentially the same position.
If the amount of content to be produced remains constant, then from a purely financial point of view the company should be looking at cutting one of them. AI would have then taken their job.
For the amount of content to be produced to not remain constant either the studio would have to go for increased art quality, or scale up the rest of the business to keep up with the new art productivity. It's not clear they'd make that decision over cutting their art department spending in two. At the very least their job is at risk.
Oof. Firing isn't free, comrade. Reducing redundancy to a single point of failure has two major effects: the latency penalty becomes quadratic as workload scales, and if any person quits, you lose the whole team.
In general, creative roles like artists are the sum value of their education and experience, not just their measured output. If you don't possess art history vocabulary, you're going to be very limited in prompting or designing more advanced embeddings and LoRA or training models. I'm seeing this a lot right now - people don't want to share their prompts because they don't want everyone to know how much the model carried them and how little any actual "prompt engineering" went into it.
The smart thing for their boss to do would be to scale projects and have one of them focus on managing and filtering the new volume of assets. Since it sounds like they like working from scratch, even adding external time to "research tooling and methods" would probably keep them happy until they find the challenge in their new duties.
> people don't want to share their prompts because they don't want everyone to know how much the model carried them and how little any actual "prompt engineering" went into it.
Right. Because this whole "prompt engineering" is just another job title, not an applied science, and then again, prompts can and will be automated away.
The majority of managers would jump at the opportunity to reduce their number of direct reports? Owners might want to cut salaries but managers want to increase direct reports.
If I understand you correctly, this doesn't work because ChatGPT isn't the only language model in the world. It's only the most popular at this point in time.
reply