keldaris

Isn't that switch basically a downgrade? You get some more single core performance and some weight savings, but also a worse (and smaller) screen, less multicore performance, less GPU performance, less video encoding performance and a smaller battery? I'm on an M2 Max myself, and glad they introduced a larger form factor Air, but it seems like a long way from an upgrade.

Is that actually true? I've never looked into the API differences or how YouTube ads actually work, but I'm using a current Google Chrome version on MacOS, with uBlock Origin Lite and SponsorBlock, and I'm watching YouTube with no ads as far as I can tell (logged in, not subscribed to Premium). Is that supposed to be impossible now?

I actually haven't - I tried Gemini 3.0 Pro in Antigravity and was disappointed enough that I didn't pay much attention to the 3.1 release, it was notably worse than Opus and GPT at the time, and much more prone to "think" in circles or veer off into irrelevant tangents even with fairly precise instruction. I'll give 3.1 a try tomorrow, see what happens.

I've had reasonable success using GPT for both neighbor list and Barnes-Hut implementations (also quad/oct-trees more generally), both of which fit your description, haven't tried Ewald summation or PME / P3M. However, when I say "reasonable success", I don't mean "single shot this algo with a minimal prompt", only that the model can produce working and decently optimized implementations with fairly precise guidance from an experienced user (or a reference paper sometimes) much faster than I would write them by hand. I expect a good PME implementation from scratch would make for a pretty decent benchmark.

As a scientist (computational physicist, so plenty of math, but also plenty of code, from Python PoCs to explicit SIMD and GPU code, mostly various subsets of C/C++), I can confirm - Codex is qualitatively better for my usecases than Claude. I keep retesting them (not on benchmarks, I simply use both in parallel for my work and see what happens) after every version update and ever since 5.2 Codex seems further and further ahead. The token limits are also far more generous (and it matters, I found it fairly easy to hit the 5h limit on max tier Claude), but mostly it's about quality - the probability that the model will give me something useful I can iterate on as opposed to discard immediately is much higher with Codex.

For the few times I've used both models side by side on more typical tasks (not so much web stuff, which I don't do much of, but more conventional Python scripts, CLI utilities in C, some OpenGL), they seem much more evenly matched. I haven't found a case where Claude would be markedly superior since Codex 5.2 came out, but I'm sure there are plenty. In my view, benchmarks are completely irrelevant at this point, just use models side by side on representative bits of your real work and stick with what works best for you. My software engineer friends often react with disbelief when I say I much prefer Codex, but in my experience it is not a close comparison.

Out of curiosity, how does the size and performance of the generated WASM compare to just compiling the same Raylib example from the equivalent C code via Emscripten? In other words, how much overhead does the choice to use Swift add here or in general?

It's not crazy, it's just what happens if you write mostly C with some conveniences where they actually make sense instead of "modern C++". I generally write very performance sensitive code, so it's naturally fairly low on abstraction, but usually most of my projects take between one and two seconds to build (that's a complete rebuild with a unity build, I don't do incremental builds). Those that involve CUDA take a bit longer because nvcc is very slow, but I generally build kernels separately (and in parallel) with the rest of the code and just link them together at the end.

Thankfully, you can still write C++ just fine without the "modern" stuff and have not only readable code, but also sane compile times. The notion, explicitly mentioned in the article, that all this insane verbosity also adds 5 seconds to your build for a single executor invocation is just crazy to me (it is far longer than my entire build for most projects).

Same here, I have multiple decades of experience running Linux on desktops and servers alike, and Omarchy just saves me time and manages to be productive and fun at the same time.

Personally, I don't feel any moral obligation to investigate the personal views of people who write the software I use. Using software, especially free software, doesn't constitute an endorsement of the authors' views. Before this thread, I was blissfully unaware of this entire silly controversy, since Omarchy doesn't mention any politics anywhere as far as I can tell. If that ever changes, I'll delete it in a heartbeat (regardless of the kind of politics it happens to be), but so far the only people politicizing the issue seem to be its detractors.

and then released Vulkan years later as a response that has had incredibly slow adoption due to the same over complexity that OpenCL died from.

I agree with everything else you said, but as someone who has used both OpenCL and Vulkan, the complexity is not comparable in the slightest. Even for pure compute applications, Vulkan is radically more annoying to use than OpenCL, though of course both are much worse than CUDA (or even Metal). OpenCL is somewhat annoying, but usable if you're okay with a basic C API, whereas Vulkan feels like an insufferable waste of time.

There's nothing wrong with using LTO, but I prefer simply compiling everything as a single translation unit ("unity builds"), which gets you all of the LTO benefits for free (in the sense that you still get fast compile times too).

Generally, the reason to bother with this approach is if you have a project that only needs tensor cores in a tiny part of the code and otherwise benefits from the cross platform nature of OpenCL, so you have a mostly shared codebase with a small vendor-specific optimization in a kernel or two. I've been in that situation and do find that approach valuable, but I'll be the first to admit the modern GPGPU landscape is full of unpleasant compromises whichever way you look.

WebGPU has no support for tensor cores (or their Apple Silicon equivalents). Vulkan has an Nvidia extension for it, is there any way to make MoltenVK use simdgroup_matrix instructions in compute shaders?

Technically, OpenCL can also include inline PTX assembly in kernels (unlike any compute shader API I've ever seen), which is relevant for targeting things like tensor cores. You're absolutely right about the language limitation, though.

How are you writing compute shaders that work on all platforms, including Mac? Are you just writing Vulkan and relying on MoltenVK?

AFAIK, the only solution that actually works on all major platforms without additional compatibility layers today is OpenCL 1.2 - which also happens to be officially deprecated on MacOS, but still works for now.

In practice, you're going to test the next version of the compiler anyway if you want to be sure your code actually works. Agreements or not, compilers have bugs on a regular basis. From the point of view of a programmer, it doesn't matter if your code broke because you missed some fine point in the standard or because the compiler got it wrong, either way you're going to want to fix it or work around it.

In my experience, if you don't try to be excessively clever and just write straightforward C code, these issues almost never arise. Instead of wasting my time on the standard, I'd rather spend it validating the compilers I support and making sure my code works in the real world, not the one inhabited by the abstract machine of ISO C.

Luckily, little of it matters if you simply write C for your actual target platforms, whatever they may be. C thankfully discourages the very notion of "general purpose" code, so unless you're writing a compiler, I've never really understood why some C programmers actually care about the standard as such.

In reality, if you're writing C in 2025, you have a finite set of specific target platforms and a finite set of compilers you care about. Those are what matter. Whether my code is robust with respect to some 80s hardware that did weird things with integers, I have no idea and really couldn't care less.

I’m convinced there’s a contingent of devs who don’t like/grok abstraction.

I am one of those. I grok abstractions just fine (have commercially written idiomatically obtuse Scala and C#, some Haskell for fun, etc.), but I don't enjoy them.

I use them, of course (writing everything in raw asm is unproductive for most tasks), but rather than getting that warm fuzzy feeling most programmers seem to get when they finish writing a fancy clever abstraction and it works on the first try, I get it when I look at a piece of code I've written and realize there is nothing extraneous to take away, that it is efficient and readable in the sense of being explicit and clear, rather than hiding all the complexity away in order to look pretty or maximize more abstract concerns (reusability, DRY, etc.).

This mindset is a very good fit for writing compute-heavy numerical code, GPU stuff and lots of systems level code, not so much for being a cog in a large team on enterprise web backends, so I mostly write numerical code for physics simulations. You can write many other things this way and get very fast and bloatfree websites or anything else, but it doesn't work well in large teams or people using "industry best practices". It also makes me prefer C to Rust.

If that's true, how are they so much more reasonable in most developed countries with far greater government involvement still? Is the US government just uniquely bad at healthcare somehow? Why?

This looks like a nice case study for when you're already using Rust for other reasons and just want to make a bit of numerical code go fast. However, as someone mostly writing C++ and Julia, this does not look promising at all - it's clear that the Julia implementation is both more elegant and faster, and it seems much easier to reproduce that result in C++ (which has no issues with compile time float constants, SIMD, GPU support, etc.) than Rust.

I've written very little Rust myself, but when I've tried, I've always come away with a similar impression that it's just not a good fit for performant numerical computing, with seemingly basic things (like proper SIMD support, const generics without weird restrictions, etc.) considered afterthoughts. For those more up to speed on Rust development, is this impression accurate, or have I missed something and should reconsider my view?

It depends on what you're doing. For writing FP32 number crunching code from scratch (meaning you don't care about something like Torch, or even cuBLAS/cuDNN), I haven't encountered cases where I couldn't match CUDA performance and if I did, I could always just use a bit of PTX assembly where absolutely necessary (which OpenCL lets you do, whereas Vulkan does not). This also gets me good performance on MacOS without rewriting the whole thing in Metal. There is no native FP16 support and there are other limitations that may matter to your usecase or be completely irrelevant.

I'm definitely not saying OpenCL is any sort of a reasonable default for cross platform GPGPU work. In truth, I don't think there is any reasonable "general" default for that sort of thing. Vulkan has its own issues (only works via a compatibility layer on MacOS, implementation quality varies widely, extension hell, boilerplate hell, some low level things are just impossible, etc.) and everything else is a higher level approach that can't work for everything by definition.

It's a pretty sad situation overall and every solution has severe tradeoffs. Personally, I just write CUDA when I can get away with it and try to stick to OpenCL otherwise, but everyone needs to make that choice for their own set of tradeoffs.

While this is completely true, it is also true that OpenCL 1.2 is the one compute API that just works on every major platform and the drivers don't seem that unusably bad (though I'm not claiming experience of every platform here, just Nvidia on Windows/Linux and Apple Silicon on MacOS). Writing a limited dialect of C and sticking to 1.2 limitations is far from ideal, but it does at least work reliably. Sadly, that is more than can be said about most competitors.

Is there a way to directly use these developments to already write a reasonable subset of C/C++ for simpler usecases (basically doing some compute and showing the results on screen by just manipulating pixels in a buffer like you would with a fragment/pixel shader) in a way that's portable (across the three major desktop platforms, at least) without dealing with cumbersome non-portable APIs like OpenGL, OpenCL, DirectX, Metal or CUDA? This doesn't require anything close to full libc functionality (let alone anything like the STL), but would greatly improve the ergonomics for a lot of developers.

Completely agree with all of that, but I would add that even if you never have to write any assembly at all, just the ability to read your own code in disassembled form is a superpower. It's not hard to learn the basics and, in addition to the ability to debug performance issues, it will forever inoculate you against the "magic compiler" delusion and keep your code somewhat grounded when you actually see what any new abstraction actually turns into.

I don't own a Tesla, but if I refused to buy any product with misleading marketing, I'm not sure I'd ever buy anything more sophisticated than a loaf of bread. Then again, I also don't use any driver assist features beyond parking sensors and don't expect to see any actual autopilot within my lifetime, so maybe I just haven't been as annoyed by Tesla's nonsense. Regardless, for a purchase most people regard as rather significant, it doesn't seem unreasonable to expect them to look at least marginally beyond a marketing misnomer.

Certainly not arguing that it's fair or just, but it's important to distinguish the mechanisms to have any hope of potentially improving the situation.

How much of that effect could be explained by the ability to afford better legal representation rather than direct preferential treatment?

Can you elaborate on your experience? There's a lot of negative D opinions from people who've barely used it and, for obvious self-selection reasons, a lot of positive ones from long term true believers. It would be interesting to see a negative experience from someone who used it extensively nonetheless.

Then they can just say so and spin it as a PR win - "look how security conscious we are these days". Very publicly removing a formerly-headline feature with no explanation and then even failing at that is just mind boggling.

That's what people generally expected when the whole P-core vs E-core on different microarchitectures design was announced. Instead of going for this, Intel went out of their way to state that there would be no AVX-512 even on P-cores and that's that. Ignoring this obvious solution is part of why I'm so flabbergasted at the situation.