gpderetta

There is, of course, an xkcd for that: https://xkcd.com/810/

> Obviously you're taking torque from the engine to do so, but that's a strategic consideration.

but drivers dislike do not being in control the harvesting and deployment (which apparently would be too complex to be manual), while fans dislike cars clipping out on straights.

Regenerative brakes (maybe even on front wheels!) would be great, but they are not enough to charge the battery given the current split. MGU-H was also a great invention, but was phased out apparently for complexity.

Next year the power output split will be tweaked to make clipping less extreme, but won't solve allt he issues.

I don't think it is the hybrid per se that is the issue. It is the heavy computer directed control of harvesting and deployment that it is disliked by both drivers and fans.

In 2020 Hungarian GP, Red Bull rebuilt the front end of Max's car, /on the grid/, after he crashed out during a recon lap[1]. They had 20 minutes, but but finished comfortably early with 25 seconds to spare. Max finished that race in second position.

[1] it was a wet race so the race start was delayed after the initial recon lap.

life imitates art.

or if it is there, it is definitely, surely, cross my heart, not enabled in prod [1]!

[1] https://en.wikipedia.org/wiki/Allegations_of_cheating_during...

In fact there is a very specific cap on CFD simulations beyond the normal cost cap, to prevent an HPC arm race. Used to be an actual flop cap, but of course teams found way around it, now it is more complicated.

Indeed. Haas is the only team that failed to hit the budget cap (while still being significantly ahead of AM and Williams).

> And the first thing he did was to onboard Atlassian / Jira and redesigned the process of communication / car production from the basics.

Ah, that explains the incredible results Williams has had since then!

> This is not much different from an auto insurance company raising your rates (or cancelling coverage) because you've received a number of speeding tickets

This is more like your insurer following you around and evaluating your driving skills.

And yes black boxes are a thing but a) are opt-in and b) universally reviled.

I would say that classical simd with explicit vector registers is plain parallelism, not concurrency. You can build concurrent abstractions on top of it (ISPC, any of the high level GPU languages), but when you move beyond simple simd hardware and have multiple hardware threads executing simd groups on multiple cpus, possibly with the ability to migrate threads between groups, the strong synchronization is a bit lost. But I'll admit I'm not an expert.

how do you implement, for example, a general purpose OS kernel without concurrency?

For some tasks, the static scheduling you described is appropriate (although you could still consider it a form of concurrency), but it needs complete cooperation between tasks and an overall design.

But as soon as you need some sort of fairness, responsiveness, and tasks that are not designed for full cooperation if not outright hostile, you need not only concurrency, but full preemption.

So I actually had this exact issue where we suspected a deadlock, but the application was limping along and we couldn't justify attaching a debugger. I managed to confirm my suspicions with judicious use of perf and /proc/<pid>/task/<tid>/wchan .

... until you realize you can have race conditions with queues as as well.

ah, that's probably a missed wakeup problem! Much nastier. Still seeing where your thread is blocked might hint you to where the missing signal should have been.

Agree completely. But they become harder when you eschew standard constructs like threads and mutexes and bring-your-own losing nice things like debugger supports and stack traces. Now your logical tasks might be deadlocked, while your threads appear to be running correctly. This is surprisingly common this day with async runtimes and less than stellar debugging support.

deterministic scheduling is possible, but most theoretical concurrency models assume non-determinism.

And even with deterministic scheduling, concurrency might be dictated by external stimuli (for example request arrival) that are not deterministic.

> True concurrency that is absolutely absent of parallelism is a bit pointless

It is very important in interactive or realtime systems.

> concurrency without parallelism is usually cooperative

preemptive concurrency is almost as old as interactive computers. Until fairly recently, most computers were single core, but you wouldn't have wanted to use a cooperatively scheduled OS [1], especially on a multiuser machine.

[1] yes, in the '80s some popular microcomputer OSs were single threaded (DOS) or cooperatively scheduled (classic macos and 16bit windows), but even then preemptive OSs were available (amigados).

C++ is the same as C here. In fact enums with no values are an idiomatic way to have strong integer typedefs.

At the very least that would warrant an explicit std::abort() or std::unreachable() at the end (or the C equivalent).

one could already add loads off a volatile and portably prevent the loop from being optimized. But there was already a lot of existing embedded code that had this sort of loop, (and more will be written as it is an existing idiom) which the committee wanted to un-break.

As the only observable behaviour of this_thread::yield is forward progress, because of the as-if rule, the compiler doesn't actually need to replace the loop, when running on a runtime that guarantees preemption. That's the case when std::threads are backed by kernel threads. On a M:N implementation, then yes, a yield would need to be added, but that would be desirable.

Interestingly, posix realtime FIFO scheduling doesn't preempt even on kernel thread based implementations, so one reading of the standard would require yield on this case. But that can actually be potentially catastrophic as FIFO scheduling is expected to be deterministic. But realtime scheduling is already beyond the standard: I doubt gcc and clang will do the transformation by default.

In practice the equivalence is necessary to make some obscure corner of the memory model work and prevent some undesirable optimizations; I expect that in practice the compilers, if they implement this at all, will provide an opt-in flag, but they will optimize as-if the call was there.

right, but the issue was that if an application was linked with a library that happened to link with a fast-math shared library, it would unknowingly bring along the crt code. Now the only way to get it is to use the fast-math flag when linking the final binary, which at least is an explicit request.

IEEE 754 defines bit exact results for a lot of FP operations, including denormals.

larger SIMD ALUs, which also have been around for longer?

IIRC that has been since split out of the flag and need to be asked for separately at link time.

Fujitsu has a long history of designing their own micro but using a standard ISA for HPC. Used to be SPARC, now it is ARM. IIRC Fujitsu were the main architects behind the SVE ARM extension.

Things get complicated when a lambda that capture by reference is capturing things that are not on a single stack frame (or a stack frame at all). Then you have references to references. You could rely on the optimizer, but the capture has ABI implications.

It is undemocratic when the democratically elected people wants to subvert the democratic order. Most (but not all!) democratic countries have constitutions that actually limit the power of elected people exactly for this reason. Especially those countries that ended up democratically electing dictators on the eve of WWII have constitutions that severely limit the power of the executive.