I never liked Softbank owning it, but hey someone has to.
Regarding the federal investment in FOSS thread that was here perhaps CPU architecture would be a good candidate.
I know momentum is currently towards ARM over POWER, but... OpenPOWER is certainly a thing, and has IBM / Red Hat support. IBM may be expensive, but they already were proven "fair partners" in the OpenPOWER initiative and largely supportive of OSS / Free Software.
I don't see OpenPOWER going there, but I can easily see RISC-V going there. So, for the moment, that is the horse I'm betting on.
To be honest, I don't think that NVidia/ARM will screw over their Cortex-M0 or Cortex-M0+ customers over. I'm more worried about the higher-end, whether or not NVidia will "play nice" with its bigger rivals (Apple, Intel, AMD) in the datacenter.
https://www.nxp.com/part/FS32R274VCK2VMM
https://www.digikey.com/product-detail/en/nxp-usa-inc/FS32R2...
The two related devkits list for $529 and $4,123: https://www.digikey.com/products/en/development-boards-kits-...
--
Those processors make quite a few reference to an "e200", which I think is the CPU architecture. I discovered that Digi-Key lists quite a few variants of this under Core Processor; and checking the datasheets of some random results suggests that they are indeed Power architecture parts.
https://www.digikey.com/products/en/integrated-circuits-ics/...
The cheapest option appears to be the $2.67@1000, up-to-48MHz SPC560D40L1B3E0X with 256KB ECC RAM.
Selecting everything >100MHz finds the $7.10@1000 SPC560D40L1B3E0X, an up-to-120MHz part that adds 1MB flash (128KB ECC RAM).
Restricting to >=200MHz finds the $13.32@500 SPC5742PK1AMLQ9R has which has dual cores at 200MHz, 384KB ECC RAM and 2.5MB flash, and notes core lock-step.
--
After discovering the purpose of the "view prices at" field, the landscape changes somewhat.
https://www.digikey.com/products/en/integrated-circuits-ics/...
The SPC574S64E3CEFAR (https://www.st.com/resource/en/datasheet/spc574s64e3.pdf) is 140MHz, has 1.5MB code + 64KB data flash and 96KB+32KB data RAM, and is available for $14.61 per 1ea.
The SPC5744PFK1AMLQ9 (https://www.nxp.com/docs/en/data-sheet/MPC5744P.pdf) is $20.55@1, 200MHz, 2.5MB ECC flash, 384KB ECC RAM, and has two cores that support lockstep.
The MPC5125YVN400 (https://www.nxp.com/docs/en/product-brief/MPC5125PB.pdf) is $29.72@1, 400MHz, supports DDR2@200MHz (only has 32KB onboard (S)RAM), and supports external flash. (I wonder if you could boot Linux on this thing?)
No different than say, Cortex-M0 or M0+ in many regards (although ARM scales down to lower spec'd pieces).
Its really too bad the dev boards are so expensive but I get you need a lot of layers to route that sort of BGA.
There are still new chips using the Cortex-M3 today. Microcontroller devs do NOT want to be changing their code that often.
New chips move the core to lower-and-cheaper process nodes (and lower the power consumption), while otherwise retaining the same overall specifications and compatibility.
The use some desoldering braid to soak up the excess solder. It will remove all the bridges and leave perfect joints.
In mobile form, it would have made a large leap in both performance and battery life. And it would have been a fairly easy market to break into: the average life of a mobile device is a few years, not a few decades. Recompilation and redistribution of software is the status quo.
Each machine instruction on NVidia Volta has the following information:
* Reuse Flags
* Wait Barrier Mask
* Read/Write barrier index (6-bit bitmask)
* Read Dependency barriers
* Stall Cycles (4-bit)
* Yield Flag (1-bit software hint: NVidia CU will select new warp, load-balancing the SMT resources of the compute unit)
Itanium's idea of VLIW was commingled with other ideas; in particular, the idea of a compiler static-scheduler to minimize hardware work at runtime.
To my eyes: the benefits of Itanium are implemented in NVidia's GPUs. The compiler for NVidia's compiler-scheduling flags has been made and is proven effective.
Itanium itself: the crazy "bundling" of instructions and such, seems too complex. The explicit bitmasks / barriers of NVidia Volta seems more straightforward and clear in describing the dependency graph of code (and therefore: the potential parallelism).
----------
Clearly, static-compilers marking what is, and what isn't, parallelizable, is useful. NVidia Volta+ architectures have proven this. Furthermore, compilers that can emit such information already exist. I do await the day when other architectures wake up to this fact.
I'm talking about Volta's ability to detect dependencies. Which is null: the core itself probably can't detect dependencies at all. Its entirely left up to the compiler (or at least... it seems to be the case).
AMD's GCN and RDNA architecture is still scanning for read/write hazards like any ol' pipelined architecture you learned in college. The NVidia Volta thing is new, and probably should be studied from a architectural point of view.
Yeah, its a GPU-feature on NVidia Volta. But its pretty obvious to me that this explicit dependency-barrier thing could be part of a future ISA, even one for traditional CPUs.
https://www.anandtech.com/show/5699/nvidia-geforce-gtx-680-r...
> NVIDIA has replaced Fermi’s complex scheduler with a far simpler scheduler that still uses scoreboarding and other methods for inter-warp scheduling, but moves the scheduling of instructions in a warp into NVIDIA’s compiler. In essence it’s a return to static scheduling
and I think this is describing more or less the same thing in Maxwell: https://github.com/NervanaSystems/maxas/wiki/Control-Codes
Speculative execution is something you would want to do with the itanium as well, otherwise the machine is going to be stalling all the time waiting for branches/etc. Similarly, later itaniums went OoO (dynamically scheduled) because it turns out, the compiler can't know runtime state..
https://www.realworldtech.com/poulson/
Also while googling for that, ran across this:
https://news.ycombinator.com/item?id=21410976
PS: speculative execution is here to stay, it might be wrapped in more security domains and/or its going to just be one more nail in the business model of selling shared compute (something that was questionably from the beginning).
questionably from the beginning
I wonder which cloud provider is the first to offer this in a coherent way.
ISTR that Intel & HP spent well over a $billion on VLIW compiler R&D, with crickets to show for it all.
How much are you suggesting should be spent this time for a markedly different result?
His explanation centred on the fact that Intel decided early on that Itanium would only ever be an ultra high end niche product and only built devices which Intel could demand very high prices for. This in turn meant that almost no one outside of the few companies who were supporting Itanium development and certainly not most of the people who were working on other compilers and similar developer tools at the time, had any interest in working on Itanium because they simply could not justify the expense of obtaining the hardware.
So all the organic open source activity that goes on for all the other platforms which are easily obtainable by pedestrian users simply did not go on for Itanium. Intel did not plan on that up front (though in hindsight it seemed obvious) and by the time that was widely recognised within the management team no one was willing to devote the sort of scale of resources that were required for serious development of developer tools on a floundering project.
https://dl.acm.org/doi/book/10.5555/923366 https://dl.acm.org/doi/10.1145/349299.349318
and many, many others (it produced so many PhDs in 90s). And, needless to say, HP and Intel hired so many excellent researchers during the heydays of Itanium. So I don't know on what basis you think there wasn't enough investment. So I have no choice but to assume you're ignorant of the actual history here, both in academics and industry.
It turns out instruction scheduling can not overcome the challenge of variable memory and cache latency, and branch prediction, because all of those are dynamic and unpredictable, for "integer" application (i.e. bulk of the code running on the CPUs of your laptop and cell phones). And, predication, which was one of the "solutions" to overcome branch misprediction penalties, turns out to be not very efficient, and is limited in its application.
For integer applications, it turns out the instruction level parallelism isn't really the issue. It's about how to generate and maintain as many outstanding cache misses at a time. VLIW turns out to be insufficient and inefficient for that. Some minor attempts are addressing that through prefetches and more elaborate markings around load/store all failed to give good results.
For HPC type workload, it turns out data parallelism and thread-level parallelism are much more efficient way to improve the performance, and also makes ILP on a single instruction stream play only a very minor role - GPUs and ML accelerators demonstrate this very clearly.
As for the security and the speculative execution, speculative execution is not going anywhere. Naturally, there are many researches around this like:
https://ieeexplore.ieee.org/abstract/document/9138997 https://dl.acm.org/doi/abs/10.1145/3352460.3358306
and while it will take a while before the real pipeline implements ideas like above thus we may continue to see some smaller and smaller vulnerabilities as the industry collectively plays whack-a-mole game, I don't see a world where the top of the line general-purpose microprocessor giving up on speculative execution, as the performance gain is simply too big.
I have yet to meet any academics or industry processor architects or compiler engineer who think VLIW / Itanium is the way to move forward.
This is not to say putting as much work to the compiler is a bad idea, as nVidia has demonstrated. But what they are doing is not VLIW.
And the compiler doesn't even come close to having as much information as the CPU has. Which basically means that most of the VLIW stuff just ends up needing to be broken up inside the CPU for good performance.
The compiler has nearly all of the information that the CPU has, and it has orders of magnitude more. At best, your CPU can think a couple dozen cycles ahead of what it is currently executing. The compiler can see the whole program, can analyze it using dozens of methodologies and models, and can optimize accordingly. Something like Link Time Optimization can be done trivially with a compiler, but it would take an army of engineers decades of work to be able to implement in hardware.
The 200-sized reorder buffer says otherwise.
Loads/stores can be reordered for 200+ different concurrent objects on modern Intel skylake (2015 through 2020) CPUs. And its about to get a bump to 300+ sized reorder buffers in Icelake.
Modern CPUs are designed to "think ahead" almost the entirety of DDR4 RAM Latency, allowing reordering of instructions to keep the CPU pipes as full as possible (at least, if the underlying assembly code has enough ILP to fill the pipelines while waiting for RAM).
> Something like Link Time Optimization can be done trivially with a compiler, but it would take an army of engineers decades of work to be able to implement in hardware.
You might be surprised at what the modern Branch predictor is doing.
If your "call rax" indirect call constantly calls the same location, the branch predictor will remember that location these days.
You get instructions scheduled based on actual dynamically measured usage patterns, but you don't pay for dedicated circuits to do it, and you don't re-do those calculations in hardware for every single instruction executed.
It's not a guaranteed win, but I think it's worth exploring.
Morpheus: No, Neo. I'm trying to tell you that when you're ready, you won't need "call rax".
---
Compiler has access to optimizations that are at the higher level of abstraction than what CPU can do. For example, the compiler can eliminate the call completely (i.e. inline the function), or convert a dynamic dispatch into static (if it can prove that an object will always have a specific type at the call site), or decide where to favor small code over fast code (via profile-guided optimization), or even switch from non-optimized code (but with short start-up time) to optimized code mid-execution (tiered compilation in JITs), move computation outside loops (if it can prove that the result is the same in all iterations), and many other things...
My point was simply that the compiler may be in position to disprove the assumption that this call is in fact dynamic (it may actually be static) or that it has to be a call in the first place (and inline the function instead).
I'm certainly not arguing against branch predictors.
The CPU has something the compiler can never have.
Runtime information.
That's why VLIW works great for DSP which is 99.9 % fixed access patterns, while being bad for general purpose code.
But what have we learned in these past 20 years?
* Computers will continue to become more parallel -- AMD Zen2 has 10 execution pipelines, supporting 4-way decode and 6-uop / clock tick dispatch per core, with somewhere close to 200 registers for renaming / reordering instructions. Future processors will be bigger and more parallel, Ice Lake is rumored to have over 300-renaming registers.
* We need assembly code that scales to all different processors of different sizes. Traditional assembly code is surprisingly good (!!!) at scaling, thanks to "dependency cutting" with instructions like "xor eax, eax".
* Compilers can understand dependency chains, "cut them up" and allow code to scale. The same code optimized for Intel Sandy Bridge (2011-era chips) will continue to be well-optimized for Intel Icelake (2021 era) ten years later, thanks to these dependency-cutting compilers.
I think a future VLIW chip can be made that takes advantage of these facts. But it wouldn't look like Itanium.
----------
EDIT: I feel like "xor eax, eax" and other such instructions for "dependency cutting" are wasting bits. There might be a better way for encoding the dependency graph rather than entire instructions.
Itanium's VLIW "packages" is too static.
I've discussed NVidia's Volta elsewhere, which has 6-bit dependency bitmasks on every instruction. That's the kind of "dependency graph" information that a compiler can provide very easily, and probably save a ton on power / decoding.
Perhaps from your perspective, a VLIW architecture that fixes these problems wouldn't necessarily be VLIW anymore. Which... could be true.
It's not only about reducing the need for figuring out dependencies at runtime, but you could also partly reduce the need for the (power hungry and hard to scale!) register file to communicate between instructions.
That's why today's CPUs can have 4-way decoders and 6-way dispatch (AMD Zen and Skylake), because they can "pick up more latent parallelism" that the compilers have given them many years ago.
"Classic" VLIW limits your potential parallelism to the ~3-wide bundles (in Itanium's case). Whoever makes the "next" VLIW CPU should allow a similar scaling over the years.
-----------
It was accidental: I doubt that anyone actually planned the x86 instruction set to be so effectively instruction-level parallel. Its something that was discovered over the years, and proven to be effective.
Yes: somehow more parallel than the explicitly parallel VLIW architecture. Its a bit of a hack, but if it works, why change things?
VLIW is a compromise product: its more parallel than a traditional CPU, but less parallel than SIMD/GPUs.
And modern CPUs have incredibly powerful SIMD engines: AVX2 and AVX512 are extremely fast and parallel. There are compilers that auto-vectorize code, as well as dedicated languages (such as ipsc) which work for SIMD.
Encoders, decoders, raytracers, and more have been rewritten for Intel AVX2 SIMD instructions, and then re-rewritten for GPUs. The will to find faster execution has always existed, but unfortunately, Itanium failed to perform as well as its competition.
GPUs do work like this – shaders recompiled all the time – so VLIW was used in GPUs (e.g. TeraScale). But on CPUs we have a world of optimized, "done" binaries.
Unless your CPU has a means for profiling where your pipeline stalls are coming from, combined with dynamic recompilation/reoptimization similar to IBM's project DAISY or HP's Dynamo.
It's not going to do well as out-of-order CPUs that make instruction re-optimization decisions for every instruction, but I wouldn't rule out software-controlled dynamic re-optimization getting most of the performance benefits of out-of-order execution with a much smaller power budget, due to not re-doing those optimization calculations for every instruction. There are reasons most low-power implementations are in-order chips.
I understand what you're saying and this seems to be the prevailing pattern but I really don't understand it. ARM could easily be a standalone company. For some reason, mergers are in.
I have always assumed that their shareholders were offered so much of a premium on their shares that they chose to sell them rather than hold onto them. Clearly based on their fiscal 2015 results[1] they were a going concern.
[1] https://www.arm.com/company/news/2016/02/arm-holdings-plc-re...
Clearly, if a buyer is willing to pay a premium for shares, it's because they believe the company is worth that premium. If the shareholders were optimistic, they might consider that as a signal of the company's underlying value and choose not to sell.
Sometimes activist shareholders will pressure a company to sell, like in the case of the Whole Foods sale to Amazon. Jana Partners owned ~8% and they motivated Whole Foods to look for buyers. They dumped their shares after the sale was announced and before it was executed. Whether that was the best for the other 92% of shareholders, the company's employees, and its customers is another question entirely.
My question is really outside of that. There will always be banks, investors, and companies that are motivated to consolidate and integrate companies to be increasingly competitive to the point of being anti-competitive. What is the counter force that helps maintain moderately sized companies that are profitable on their own?
Apple could of course Afford to invest in RISC-V (and surely has played with it internally) but they have enough control of their future under the current arrangement that it will be a long long time before they feel any need to switch — 15 years at least.
This could change.
Given that the CEO was the supply chain guy at the time I suspect the latter, as I’d imagine he’d be more dispassionate than Jobs.
In any case I seriously doubt nvidia could, much less would benefit from cancelling Apple’s agreement.
I've seen this argument made before.
It would be a valid point if Apple stopped using Nvidia GPUs in 2008 (they did), and then never used them again. And yet, 4 years later, they used Nvidia GPUs on the 2012 MacBook Retina 15" on which I'm typing this.
And then that was that. We haven't seen Nvidia GPU again.
That said: AMD GPUs have also had their share of issues on MacBooks.
https://riscv.org/membership/members/
While some like Google and Alibaba are listed as platinum founding members.