In the case of the Toyota/Denso mess, the code in question had both auto-generated and hand-written elements, including places where the autogenerated code had been modified by hand later. That is the worst place to be, where you no longer have whatever structure and/or guarantees the code gen might provide, but you also don't have the structure and choices that a good SWE team would have to develop that level of complexity by hand.
The toyota code was a case of truly abysmal software development methodology. The resultant code they released was so bad that neither NASA, nor Barr, nor Koopman could successfully decipher. (Although Barr posited that the issue was VERY LIKELY in one of a few places with complex multithreaded interactions).
Which therein lies the clue. They wrote software that was simply unmaintainable. Autogenerated code isnt any better.
Fwiw, unused-cast-to-void is a case that GCC and Clang ignore when using -Wno-old-style-cast, which is what most projects prohibiting C-style casts are going to be using (or whatever the equivalent their compiler provides).
In Itanium's heyday, the compilers and libraries were pretty good at handling HPC workloads, which is really the closest anyone was running then to modern NN training/inference. The problem with Itanium and its compilers was that people obviously wanted to run workloads that looked nothing like HPC (databases, web servers, etc) and the architecture and compilers weren't very good at that. There have always been very successful VLIW-style architectures in more specialized domains (graphics, HPC, DSP, now NPU) it just hasn't worked out well for general-purpose processors.
> I do have a semi-unrelated question though: does using the recursive approach prevent it from being calculated efficiently on the GPU/compute shaders?
Historically speaking, the use of recursion in shaders and GPGPU kernels (e.g. OpenCL "C" prior to 1.2) was effectively prohibited. The shader/kernel compiler would attempt to inline function calls, since traditional GPU models had little in the way of supporting call stacks like normal CPU programs have, and thus recursion would be simply banned in the shader/kernel language.
RISC-V the ISA is open; RISC-V implementations need not be. There's no reason to believe that any truly high-performance implementations will be usefully open.
There are also many high-performance Chinese implementations that are open-source (e.g., XuanTie C910, XiangShan, etc.).
While achieving an open-core design comparable to Zen 5 is unlikely in the near term, a sustained open-source collaborative effort could, in the long run, significantly change the situation. For example, current versions of XiangShan are targeting ~20 SPECint 2006/GHz (early where at ~9).
Until there's a common, well-supported, and sufficiently performant family of RISC-V SoCs or CPUs with support for existing well-supported GPUs, RISC-V support will be a massive pain in the ass of a moving/fragmented target.
This has held back Arm for years, even today the state of poor GPU drivers for otherwise good Arm SoCs. There is essentially a tiny handful of Arm systems with good GPU support.
> Airbus is much more transparent about its automation.
Airbus is OK, but could be better. There is a long history of Airbus crews facing unexpected corner cases in their flight control laws, and fortunately only a few of them have had fatal outcomes. While there are only a few "major" modes, there are a surprisingly large number of edge cases that can be encountered.
In some cases, it is exactly the case of multiple independent actuators, such that the "voting" is effectively performed by the physical mechanism of the control surface.
In other cases all of the subsystems implement the comparison logic and "vote themselves out" if their outputs diverge from the others. A lot of aircraft control systems are structured more as primary/secondary/backup where there is a defined order of reversion in case of disagreement, rather than voting between equals.
But, more generally, it is very hard to eliminate all possible single points of failure in complex control systems, and there are many cases of previously unknown failure points appearing years or decades into service. Any sort of multi-drop shared data bus is very vulnerable to common failures, and this is a big part of the switch to ethernet-derived switched avionics systems (e.g. Afdx) from older multi-drop serial busses.
> Americans don't like diesel cars... It makes no sense to regulate emissions on diesel passenger cars in the USA.
That doesn't follow. Americans don't like diesel cars because emissions-compliant diesel cars are a massive pain in the ass. Diesel emissions treatment systems are a maintenance pain, as indicated by how many people with diesel trucks perform illegal emissions "deletes". The "magic" of VW's cheating was that it minimized or eliminated this pain, so all the owner was left with was the increased MPG, and this was pretty popular. It wasn't more popular because (1) plenty of people who would have considered a diesel with this ease-of-use would not have considered a VW, and (2) none of the other automakers could compete, because, you know, the cheating.
> It's worth noting that Google actually did succeed with a wildly different architecture a couple years later. They figured "Well, if CPU performance is hitting a wall - why use just one CPU? Why not put together thousands of commodity CPUs that individually are not that powerful, and then use software to distribute workloads across those CPUs?" And the obvious objection to that is "If we did that, it won't be compatible with all the products out there that depend upon x86 binary compatibility", and Google's response was the ultimate in hubris: "Well we'll just build new products then, ones that are bigger and better than the whole industry." Miraculously it worked, and made a multi-trillion-dollar company (multiple multi-trillion-dollar companies, if you now consider how AWS, Facebook, TSMC, and NVidia revenue depends upon the cloud).
Except "the cloud" at that point was specifically just a large number of normal desktop-architecture machines. Specifically not a new ISA or machine type, running entirely normal OS and libraries. At no point did Google or Amazon or Microsoft make people port/rewrite all of their software for cloud deployment.
At the point that Google's "bunch of cheap computers" was new, CPU performance was still rapidly improving. The competition was traditional "big iron" or mainframe systems, and the novelty was in achieving high reliability through distribution, rather than building on fault-tolerant hardware. By the time the rate of CPU performance improvement was slowing in the mid 2000s, large clusters smaller machines were omnipresent in supercomputing and HPC applications.
The real "new architecture(s)" of this century are GPUs, but much of the development and success of them is the result of many iterations and a lot of convergent evolution.
> At the point that Google's "bunch of cheap computers" was new
It wasn't even new, people just don't know the history. Inktomi and HotBot were based on a fleet of commodity PC servers with low reliability, whereas other large web properties of the time were buying big iron like Sun E10K. And of course Beowulf clusters were a thing.
And as far as I know, google's early ethos didn't come as some far sighted strategy, but just the practical reality of Page and Brin building the first versions of their search engine on borrowed/scavenged hardware as grad students and then continuing that trajectory.
Not revisionist I think just more that a lot of people first encountered the concept with the story of Google and don't know it had plenty of precedent.
reply