“One of the goals of our architecture is to have it be completely transparent to software, because software is hard to change.”
Software is hard to change. How ironic, and yet of course completely true.
Software is hard to change. How ironic, and yet of course completely true.
Most software is sold with “works with existing hardware” as a selling point.
Most vendors don't have the luxury of being able tailor both to eachother.
We saw the result with Intel Itanium: great concept, absolute failure due to software incompatibility. On the other hand, the PS3's Cell architecture demonstrated that innovative platforms aren't impossible given the right incentives.
On the contrary, even if you better not access memory too randomly to get full performance with GPU compute, today you can often access gigabytes of memory randomly IF needed (PS3 Cell had 256kb.. but you were double or triple-buffering for send/receive so effectively it was less) and even if it's better avoided it gives a whole lot of freedom in practice. Doing RTX style raytracing would've been doomed on the Cell.
Which are the same kind of features driving mesh shaders, or more recently, DirectX work graphs.
It doesn't have to be RTX style raytracing.
I took RTX style raytracing as my own current demoscene stuff is doing raytracing with just compute shaders (not needing actual RTX support)
- A flawed theoretical basis (super-smart compilers and VLIW CPU architectures were the key to faster general-purpose computing performance)
- Many, many years of design/development delays before Intel actually shipped working hardware
- Competing CPU architectures (x86, RISC, etc.) increased their performance enormously during Itanium's delay years
- When you finally could get Itanium systems with decent performance...they were damned expensive, and their bang-for-the-buck performance was mediocre at best.
Apple did it three times with the Mac 68K -> PPC -> x86 -> ARM
The same was true for x86 - by the time Apple started selling x86 machines, the x86's were so much faster than even G5's it was hard to notice any slowdown.
And, while I assume there are uses in which some x86 MacPros still perform better than their ARM counterparts (1.5 TB of RAM must help), those are far and in-between.
There were situations:
> The 603 was intended to be used for portable Apple Macintosh computers but could not run 68K emulation software with performance Apple considered adequate, due to the smaller processor caches. As a result, Apple chose to only use the 603 in its low-cost desktop Performa line.[12][13] This caused the delay of the Apple PowerBook 5300 and PowerBook Duo 2300, as Apple chose to wait for a processor revision. Apple's use of the 603 in the Performa 5200 line led to the processor getting a poor reputation.
- from https://en.wikipedia.org/wiki/PowerPC_600#PowerPC_603
(The original PowerPC 601 had a 32KB unified cache, the problematic 603 had separate 8KB I- and D-caches, and the "problem-fix" 603e had separate 16KB I- and D-caches. My recollection is that the 68K emulation software was developed for and on the 601, and relied on some clever lookup and/or jump tables fitting into that CPU's large - for the time - L1 cache.)
It’s a shame I didn’t have A/UX on the IIci though (and don’t have the IIci anymore) but Unix didn’t look like it was the future at the time.
The 6100/60 (PPC 601-60Mhz) was definitely slower with emulated applications.
Besides that, the 68K emulator didn’t emulate the floating point unit in 68040s making it incompatible with higher end applications.
Only the high end 8100/80 was always faster than most 68K macs under emulation. But still high end 68040s were faster running 68K Macs.
But this was largely alleviated with the third party SpeedDoubler extension that was a much better emulator.
This isn’t even to mention the awful emulator performance of the 603 Macs.
But this is the only benchmark I could find between PPC vs x86 for emulation.
https://barefeats.com/quad06.html
On a semi related note: Apple still doesn’t have an answer on the high end when it comes to competing with the fastest x86 PCs + GPUs
I think they decided not to pursue that market segment. Their current high-end is quite a lot of computer (the lack of support for dGPUs on the MacPro is disappointing, and while 192GB ought to be enough for anyone, it could sport an external memory controller and a DDR5 bus for those crazy people who really want terabytes of RAM).
When you go beyond that you enter the midrange tower server market and those machines don’t come cheap either. The day after the Pro’s release I priced a similarly equipped Dell (same number of cores, same memory and storage) and it was the same price (a bit less), but it could be expanded much further.
It was also much hotter, louder, and uglier.
> Most vendors don't have the luxury of being able tailor both to eachother.
Microsoft has to care about niche vertical market apps that will never be updated.
But compared to the Xbox, PS3 "won" at the tail end of the generation, I would credit this to the supperior exclusive titles and the sales outside US. In Europe, Japan an South America, Playstation sells a lot more than Xbox. Where I live (Brazil) almost no one buys Xbox. As an anecdote, in 20 years, I met only one person who owned one (a X360) and several who had Playstations. And the X360 owner only had it because she worked at Microsoft and got it as a gift from the company.
I bought a slim as soon as they came out as a BluRay and media player. It was cheaper than about 95% of the other offerings at the time, had a way better UI and remote, and wasn't going to get locked out when content keys were rolled. It supported upnp media playback, so I could stick a mediatomb machine in a closet and use a nice remote and UI in the living room. A side benefit being that you can get dirt cheap laser modules and keep it going forever.
What open source software does is to turn hardware architecture into a commodity.
Itanium and Alpha, it seems, were a bit too early to this party.
I.e., to the extent they reduce the need for source code to cater to the underlying CPU, less effort is needed to port software to a new CPU.
I think GCC and especially LLVM are really reducing the barriers to bringing new CPUs to market.
Maybe for GPUs as well because of shader compilers?
And there are lots of temporary solutions in programming.
Once, we get a reasonable lean and modular software stack for most usage contexts, we can start to deal with new hardware models with their specific software optimizations.
A big mistake from AMD software teams is their worshipping of c++... they should have sticked to plain and simple C (not the gcc/iso extented one), actually I'll one step higher: plain and simple assembly for their hardware.
It also makes writing big old messes easier than C.
Writing simple, elegant and efficient code is hard. It takes "polish", which usually means not stopping the moment as you have "something that works", going back, refactoring, shaking out those TODO comments...questioning all the assumptions and abstractions you added earlier, etc etc.
It is less worse to write and try to keep sane plain and simple C, that to be dependent on a c++ compiler, not to mention that c++ code is no more immune from toxic code than C. Actually, this is the other way around: since the syntax is beyond-reasonable complex, c++ toxic code is way worse than c toxic code.
C is a lesser evil than c++.