Alpha and PA-RISC died before the smartphone revolution (end 90s vs mid 00s). x86-32 killed them, before AMD64 (x86-64) took off.

Laptops were all x86-32/64. There has been an UltraSPARC laptop (one AFAIK), and Apple switched away from POWER because of power inefficiency. Also before the smartphone revolution.

Intel was busy with Moblin and PowerTOP back in the 00s. This before iPhone.

MIPS and RISC-V also exist. Without ARM it would've happened but slower/later.

None of those 3 even tried to have a product for applications with low cost and low power consumption.

The only competition was from Motorola/IBM POWER (and MIPS in some niche products), but neither Motorola nor IBM ever tried to offer low cost products.

During 2000 to 2005, I have ported some products with embedded computers from POWER to ARM.

The porting was not very easy, because the ARM CPUs had much lower performance, but they were much cheaper, so the conversion was done anyway.

The ARM advantage has always been in its business model, which created a lot of competing CPU vendors, willing to give you the best price, not in any technical advantages of its CPU architecture.

The NVIDIA acquisition certainly threatens this business model, despite all contrary claims of the NVIDIA management.

This is ridiculous. ARM was already pretty much well-settled-in in the PDA way before the smartphone, so it definitely didn't "single-handedly made it happen". And during the early PDA era, when they got settled in that market, it most certainly did not win due to "low power draw". Back in the day where SH(-3) PDAs where still a thing, the battery life was measured in days out of 2 AAA cells (even for ARM devices). That was destroyed due to forced backlight usage in most screen techs rather than any change in ISA.

Today MIPS is still used in network devices, SH is still used in things like optical drives, SPARC is still used on some servers, x86 is still used on many servers and desktops and mobile devices, and so on and so forth. Do you think that there is something technical that warrants the choice of these architectures for their usecases ? Do you think that there is something in SH that makes it a better ISA particularly for CD-ROM drives ? Or that there is something in SH that made it a better ISA for some videogame console generations, then something changed and the better ISA was PPC, then ARM, then x86 again ?

It's mostly arbitrary marketing decisions, which manufacturer happened to be doing well that day, and some "historical reasons"/network effects which define these choices. There's very little difference at this ISA/architectural level, and a lot in the actual design and manufacturing level, where ARM is not doing poorly but hardly shines. Apple, Intel, AMD, Qualcomm, even nVidia all do better than ARM there.

If we the wind had blown even slightly differently some day 20 years ago, we may very well be using anything else, even say Itanium in our smartphones. And before you complain that Itanium/EPIC are hardly suited for low power, remember that Transmeta made their money selling _low-power_ VLIW processors emulating x86 instructions. And actually they were lower power than their x86 competition those days. Perhaps Torvalds would still be there rather than making Linux...

There were many other CPUs with the same or lower power draw.

The advantage of ARM has always been the cost. For given requirements of performance and power draw, you could find much cheaper ARM CPUs than the existing alternatives.

This happened because there were many competing ARM CPU vendors.

Motorola could give you a PowerPC CPU with the same or better performance and power draw, but they were not willing to lower their prices, falsely believing that there are no alternatives.

Therefore everybody abandoned the other CPU architectures and switched to the cheaper ARM solutions.

Actually, it's kind of the other way around.

When Nokia and Ericsson switched to ARM the company was probably saved from bankruptcy.

That’s fair, for me it never worked with any of the hardware or software I wanted it to and I’m not enough of a GPU expert to really fix that myself, so for me and many others I found with similar problems it definitely has yet to become a workable solution, but I was probably a bit harsh if I came across like I thought it didn’t work at all, I’ve seen it demoed and I know it works, but for such a restrictive set of hardware and software that Ive never seen it in use myself outside of demonstrations.

As for Vulkan, I tend to think of CUDA at the driver level given how closely coupled it is to Nvidia’s hardware. So I wasn’t really thinking about broader cross compatible APIs like Vulkan which tend to get implemented on top of the drivers providing low level access like CUDA gives… but with the exception of Apple (because we know they will never change their mind) I’m hoping the broader industry gets behind Vulkan compute shaders enough we finally get something that delivers on the promises made when the OpenCL effort began. I want clean understandable abstractions over the top of all the different SIMD and MIMD capabilities we have these days it doesn’t have to magically compile my code down to FPGA hardware but how about actually being able to get the best matrix multiplication performance out of both my CPU or GPU or both if I have a CPU with the right kind of integrated GPU that they can efficiently enough share memory and both work together without slowing each other down when working on an embarrassingly parallel matrix multiplication task. Is this really too much to ask of software in an an era that gives us near magical JIT performance in multiple languages, and manages to build cross compile/transpilation tools that can convert entire assembly code bases into JavaScript and all the other nice things we have as software developers… it never felt like too much to me but the fate of OpenCL appears to disagree.

They also hire software engineers to integrate CUDA into open source projects. On the one hand, those projects can now take advantage of advances in hardware. On the other, users will have to buy NVIDIA to use it, so how open is it? Also NVIDIA will not provide any help with CI, so those costs are borne by the project – or the code isn't tested.