I don't really get the hate. Everyone here uses AI for just about everything yet they almost never credit the models. I think this misrepresents the work so I credited the tools. But I'm by no means just handing a blank script to a model and hoping for the best.
That’s actually a fairly good answer. I think I’d summarize the meat of it as: even a non-atomic, non volatile store can be observable in the sense that it can transform data-race-free code into racy code, and the compiler may not do this in a manner that changes observable behavior.
I’m starting to wonder whether newly designed programming languages should explicitly distinguish probably terminating loops from potentially infinite loops. Lean does, for good reason.
Is it a good answer though? How often does this opportunity come up? And if you have two trivial infinite loops one after the other, do you really need to insert `yield()` in order to be able to merge them?
void func()
{
for ( int *p = head; p; p = p->next )
sum1 += p->val1;
for ( int *p = head; p; p = p->next )
sum2 += p->val2;
}
The compiler really wants to merge the loops (this will be a nearly 2x speedup in this contrived case). In other words, the compiler would like to generate this instead:
void func()
{
for ( int *p = head; p; p = p->next ) {
sum1 += p->val1;
sum2 += p->val2;
}
}
Naively, this optimization looks obviously correct: since there is no synchronization in func(), nothing could validly observe the changes in the order of the stores.
Here's the problem. While C and C++ consider data races to be UB (which is why the compiler is allowed to mess with the order in which potentially shared state is written here), the presence of a data race is still observable in a problematic sense. Suppose thread 2 is doing something like this:
while (true) {
printf("%d\n", sum2);
}
If thread 1 calls func() while this loop is running, then the program has undefined behavior [0]. Except there's a really nasty corner case. If the linked list has a cycle, then func() contains an infinite loop. (All it takes to cause this is head->next == head.) And, if func() has an infinite loop then, as originally written, sum2 is never modified and there is not a data race. So a sneaky programmer could set up the infinite loop, call func() in one thread, do the printf loop in another thread, and the compiler would need to run that code correctly because it's not UB. If the compiler transforms func() as above, then it introduces a data race where none existed, and it's a bug.
But this optimization seems important, and C and C++ sidestep this issue by declaring that func() itself is UB if the linked list contains a cycle. So the transformation does not introduce UB in my example because, in the problematic case, the UB is already there in the original code. Problem solved. Yuck.
(Realistically the compiler will also probably accumulate the sum in registers and add to sum1 and sum2 at the end. One could quibble that this subsequent transformation invalidates my point, but it's easy enough to make a slightly more complex example that doesn't have this problem.)
None of this is to say that I like C and C++'s solution. It's gross. The new C++ change to sort-of-solve it is extremely gross.
FWIW (and I sort of alluded to this above), there is an IMO much more interesting reason that compilers should care about infinite loops that doesn't apply to C/C++. In languages like Lean (but borrowing C-like syntax), you can write something like:
ProofType proof()
{
// some body here
}
The entire basis of the proof model in Lean is that the existence of a "term" like proof() that returns the type ProofType implies that an object of ProofType can be constructed (I think this is usually described as saying that ProofType is "inhabited"). This is pretty concrete -- you could literally run proof() to obtain this object.
But infinite loops completely break it: you could just write:
ProofType proof()
{
while (true)
;
}
(Sure, a clever compiler could reject this particular function. But a clever programmer can out-clever the compiler.)
So, in Lean, you either need to prove to the compiler that all your loops terminate or you need to mark the function as "partial", which tells the compiler that it cannot assume that the existence of the function means that the return type is inhabited. This would be a pretty radical change to C and C++, but it would fully solve forward-progress problem :)
[0] This one is no joke. I can come up with examples that would jump to inappropriate addresses using a construct like this if there's a data race -- just replace sum2 with a function pointer.
Yes. Loops that manipulate data are extremely common. Combining memory accesses and increasing cache locality are extremely beneficial to performance. Transformations that rewrite loops to increase the chances of locality/combining are therefore likely to be worthwhile.
> If Samsung and everyone else said "sorry Google', or even a large majority, you're out. Gone. Nada.
The OEMs are incapable of writing a competent operating system, and don't particularly care to.
> Google is also getting more and more pushy with Chrome. What if everyone depending upon that backend, shrugs and says "Sorry Google, we're hard-forking Chrome and we'll all maintain it".
That would be a reasonable argument if it were indeed their private lives, and they didn't go around offering to throw gangbangs for AI safety researchers.
That's not even the fundamental problem. Even if the payload runs optimally in the browser, the cost of CPU is so small that it's basically irrelevant.
If you waste your user's time with something that would take a full minute to run on a datacenter core, you're costing the scraper something like $0.000005: 360 W TDP on a 128-core EPYC 9754 * $0.10/kWh. In reality, it'll be substantially less than that, because CPUs don't use 0W at idle.
The only way this would make any sense is if there were many more scrapers than users and scrapers cared more about latency than real users, but that's the exact opposite of reality. The entire endeavor is so fundamentally misguided that it almost seems like a psyop.
Most new construction with heat pumps are going to use similar thermostats, both because of improved efficiency since the outside unit wants to know how much heating/cooling load is being requested, and more importantly, because builders are lazy and would rather use a battery-powered wireless option than run thermostat wires.
Off the top of my head, Mitsubishi, Rheem, Lennox, and Carrier all have similar default options, with converter boxes for retrofits to 24V controls.
> Somewhat functional in the trivial problem domains, and always useless where design choices mattered.
This is laughable when you consider that semiconductor design is the least "trivial" problem domain, and it happens entirely in RTL. There's basically zero human intervention when it comes to layout: even floorplanning is being automated nowadays.
Fab standard cell libraries are already the practical optimization of their current capabilities, and even FPGA try to minimize routing proximity with various levels of success. However, there are again named problems that constrain what naive people can get away with....
Procedural generation or parametric design is not the same, as the behavior and constraints were rationally engineered by people.
LLM would simply look at the outputs during training, abstract it as looking similar to a potato-chip factory, and generate a nonsense answer some fool assumes is appropriate.
Humans are wired to see meaningful patterns in chaotic systems even when they aren't really there. Neuromorphic computing may create real "AI" someday, but it almost certainly won't be from LLM cults. =3
Have they actually announced that they're charging less than the marginal cost of inference, or that the revenue they're taking in doesn't make up for the cost of training each newer and better model?
The former does not pass the smell test when there are random providers selling tokens for competitive open weight models.
Why would I hire you when I could pay $17 for a Claude subscription?
reply