They were advertising tickets three days before they announced everything was cancelled: https://archive.ph/Uimqj
> What happens to my in-person or virtual registration fee?
> Information regarding GHC registration and other financial matters will be communicated to you promptly once we obtain a clearer understanding of AnitaB.org ’s financial condition.
Something like 1% of corn grown in the U.S. is used to feed people directly. The majority of it is used to inefficiently make gasoline (via ethanol) or plastic, because farm subsidies make it profitable.
While ethanol requirements are a hand out to corn farmers, it’s false to say the majority goes into gas and plastic, an equal share (~40%) goes to animal feed.
And growing at that scale makes that 1% super affordable as a food source. all these 'we need AI data centers at crazy huge scales' people suddenly don't understand scale when it comes to feeding the brokies.
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.
Although I don't fully agree. With AI the focus now shifts a lot from 'being able to implement the thing' to 'being able to know/figure out exactly what you want the thing to look like', also against the siren song of the LLMs constantly having ideas of what you could _also_ build.
So, I agree that it's not a direct translation from 'pro pizza cook' is 'pro pizza orderer', but I'm quite sure the pro pizza cooks would generally have the better pizzas in the end, if there were infinite variations of pizza on the menu and the ordering agent was constantly trying to upsell you on slathering on another layer of sauce and cheese.
Which is not to say there aren't exceptions in both directions, because as a pro pizza connoisseur you could even be better positioned to 'know exactly what you want', without ever having made a pizza; and as a pro cook you might still be overwhelmed by the ordering process.
Though all of this still assumes of course that we are in the 'complexity region' where we can expect the LLM/the pizza agent to deliver _exactly_ what we wanted, without issue. As soon as we leave that region (though it expands every week, it feels like), the skills of the cook are still very much necessary to make sure things are as they should be, and fix them if not.
there are two completely different activities both called "writing software using AI".
At work, for important stuff, I go through every change, mine or LLM's, edit it, clean it up, rewrite, until I am satisfied with the code.
At home and for one-off unimportant stuff I go "computer make me sandwich".
The second is nothing like the first. No amount of design and pro I have can make sure stuff coming out of LLM actually implements it, as opposed to me be tricked into thinking it does. After all, that is exactly the training criteria – convince the "eval" that task is accomplished, isn't it?
And the second kind of activity takes skill that no amount of "I am pro dev" can compensate.
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.
> What happens to my in-person or virtual registration fee?
> Information regarding GHC registration and other financial matters will be communicated to you promptly once we obtain a clearer understanding of AnitaB.org ’s financial condition.
Incredible.
reply