Wake me up from this nightmare

That’s a race condition, not a data race.

A race condition is an application invariant violation under concurrency, so it has no application-independent definition. A data race is unsynchronized access by two concurrent threads to the same memory location where at least one access is a write. Ergo, the definition of a data race has nothing to do with application logic.

I think this should make the distinction between data races and race conditions pretty clear.

A data race is by definition a class of an race condition. This is basic compsci literature, and there is no other way to put it, as even a non programmer can see the similarity.

Not sure why you would be that nitpicky for something so trivial?

I find this distinction extremely useful in practice because it explains why a static analyzer like Rust's type checker can prevent all data races but can do nothing about race conditions. (Similarly, a dynamic analyzer like ThreadSanitizer can detect data races but not race conditions, because it knows nothing about application logic.)

He’s very wrong about this. Just because ‘tptacek posts a lot and did security once upon a time does not make him “broad consideration”.

Well, you're right about one thing: the fact that I've spent my career in software security doesn't make me "broad consideration". The cites I give on what "memory safe" means, though, do.

My argument has never been "memory safe means what I say it does because I say so", but I get how that's a much more convenient argument to knock down than the ISRG site built specifically to talk about this.

ISRG is wrong too, definition-wise. Go is not memory safe. It is much safer, and I wouldn’t fault you for taking a C codebase and porting it to Go to avoid memory safety problems, but that does not make it memory safe in the same way Rust et al are memory safe. This is the same way that MTE does not thwart all memory corruption but it stops a lot of them. I accept your premise that Go has brought memory safety over the line to where it is apparently easier to find logic bugs than exploit memory corruption, which is laudable since C(++) has never been able to do this and likely never will, but in line with the pedantry that started this whole chain of comments, it’s not memory safe.

How are you checking that the AI is not just gaming your correctness tests? It's very easy to write incorrect synchronization for example.

It cant if you be cautious about it because the inputs can set manually and outputs are generated through the cuda harness by executing the reference kernel, again can be provided externally.

Comparison is simply byte by byte equalness check of reference kernel outputs with candidate (optimized) outputs.

Why I added ai generated inputs then? I was just being lazy and this was more of a langgraph playground for me:)

Yes, but the AI can totally make a kernel that passes your test inputs but is not correct

And the guys outside the AI labs are saying they won't even reach adulthood.

And the teachers are saying they can't even read and that they're dumber than the previous generation.

Maybe reading is going the same way as a typewriter or knowing how to mill grain between two big stones?

We don't need the ability to read. We need the ability to convey and understand -- audiobooks can do this, for example.

Teachers have said that about every generation since time immemorial.

Thankfully anyone who dealt with a teacher knows how much value their opinion holds.

Most languages do not provide direct eval.

Caltrain does exactly this.

There seem to be a fair number of commuter train lines that do this, but I don’t really consider a train to be the same as an urban tram/bus system. The latter has orders of magnitude more daily passengers, and it’s a far wider breadth of people compared to the typically better-off suburban commuter lines.

And as someone that’s ridden the bus in LA many times: the culture of acceptable behavior there is infinitely lower than the typical Central European bus.

To be fair I did have NYC in mind when writing the comment though, and I should have looked into west coast systems more.

> Despite our test suites almost quadrupling since the start of the year

Did the tests produce four times as much value, though?

Unknowable. How much did a bug that was caught by those tests, and did not reach production save the company? What if there were many such bugs? Or none? How much extra time was lost to developers waiting around for tests to run?

I think the power itself will probably be more than you're paying in a subscription

<500W draw at peak, so maybe not?