SiFive Shifting Production Focus To Next-Gen HiFive Development Board

[PerformanceExpert]

But that's a different discussion than the point zxy_thf made.

Again, I'm not anti-ARM. However, we do ourselves no favors by over-inflating its progress, nor by downplaying how long it took to happen.

RISC-V can be competitive, if/when it gets the resources pumped into making a competitive RISC-V core. It'll happen. We just don't know exactly when, by whom, or precisely how it'll stack up to comparable x86 and ARM offerings of the day.

I'll tell you this: if Intel decides to dive directly into the RISC-V game, ARM should be worried. Intel is at its best when it's in catch-up mode, like what we're seeing with their latest x86 cores.

I've often made the point that it took Arm far longer than originally expected. Many companies tried designing a high-end Arm core and went down. Even large companies like Qualcomm and Samsung tried and failed. That should tell you that it's not easy to do a competitive high-end design and turn a profit.

There is no doubt several companies will try doing high-end RISC-V designs. Like we saw with Arm, some will go bust, and eventually some may succeed. Intel may well pump a few billion into RISC-V (and seem to be willing already given there were rumours to buy out SiFive). However I expect it just to be a minor irritation. Remember the 10+ billion Intel spent on trying to get x86 into mobile phones? It didn't even make a dent in Arm's market share. Intel would have to spend many times that to become a threat to Arm.

[coder]

A single guy cannot create an ecosystem from scratch. Manpower and money (lots!) are as essential as expertise in the industry.

Did you see where he was head of engineering? He will have known who to hire to quickly ramp up their compiler efforts. And SiFive has enough money & backing that they could afford to rebuff an acquisition by Intel.

Here is an example of their "expertise": make late breaking ISA changes, sit on them for years before creating incompatibility in tools and distros...

Reminds me of the ARMv7 hf issue. That was an incompatible ABI.

You just have to build your toolchain for one or the other, depending on your hardware. And since most RISC-V are used in embedded platform devices, it's basically a non-issue. The point where it starts to matter is when you need binary compatibility between different machines, which is mainly something needed to support commercial software.

https://linuxhint.com/about-arm64-armel-armhf/

[coder]

Even large companies like Qualcomm and Samsung tried and failed.

Qualcomm killed off Centriq to fend off a hostile takeover bid.

The mobile cores of QC and Samsung failed because they were cost-constrained by the license fees of ARM's stock cores. If their in-house efforts had been viewed as an existential necessity, then they could have put enough resources into them to keep them competitive.

Remember the 10+ billion Intel spent on trying to get x86 into mobile phones?

That was like fitting a square peg into a round hole. Doomed to fail. Intel also failed at Xeon Phi, which is another place x86 didn't belong. Eventually, and every once in a while, Intel does get things right.

[mdedetrich]

You simply can't compare RISC-V with IA64. And anyway, there's been 2 decades of advancements in compilers since then.

I am not directly comparing them, I am making a point which is that compiler support is both important and critical.

Furthermore you also cannot just compare RISC-5 with ARM, although they are both RISC ISA's, RISC itself is just a general concept and the 2 ISA's are quite different from eachother (deliberately so also because of patents). Them being broadly RISC is probably the only similarity between them.

Putting this under the rug as "compiler's getting better" is also misleading and leaves a huge amount of detail.

[PerformanceExpert]

Qualcomm killed off Centriq to fend off a hostile takeover bid.

The mobile cores of QC and Samsung failed because they were cost-constrained by the license fees of ARM's stock cores. If their in-house efforts had been viewed as an existential necessity, then they could have put enough resources into them to keep them competitive.

In all cases the main issue was the high cost and the slow/difficult path to recoup that cost. The fact that many of these custom designs weren't even outperforming much cheaper Arm cores was not helping the cost/benefit calculation. At least QC seems to be on the right track now after acquiring NUVIA, but it shows just how expensive a top CPU team is.

That was like fitting a square peg into a round hole. Doomed to fail. Intel also failed at Xeon Phi, which is another place x86 didn't belong. Eventually, and every once in a while, Intel does get things right.

It didn't seem doomed to them even if it did to most of the rest of the world. Same with Itanium, Larrabee, Quark, Optane - the list goes on and on... The jury is still out on their new GPU or whether they can match EPYC with next-gen servers. The new Atom is finally decent after more than a decade of trying. So yes they can get things right, but it typically takes several tries and many years.

[microcode]

For those who wanted access to one of these, I can provide virtual access to one on a stable network connection (200-980Mbit/s down, 5-30Mbit/s up, sub-1ms latency to the Azure datacenter in Wyoming) with virtualized storage and ssh to the hardware serial console, for a reasonable fee. Hit me up! <[email protected]>

[microcode]

Even if RISC-V CPU core design gets closer to the performance of the current ARM designs, it will probably take a few more years after that until the compilers catch up.

I still remember that on the early days of the medium/high-performance ARM cores there was still a lot of software that performed quite poorly due to lack of code optimisations compared to their x86 counterparts. Not too long ago I still had to use a Linaro modified version of GCC to compile the Linux kernel, fortunately everything is now upstreamed.

The work involved in getting RISC-V compiler targets up to par with AArch64 is much less than the work that was involved in getting AArch64 there; because a lot of that work was around making toolchains more portable and configurable, and that work is now done.

[brucehoult]

Crypto is so slow it's useless as a NAS
https://forum.odroid.com/viewtopic.php?f=149&t=30103

That puts is very similar to a RPI 3, which is what you'd expect if neither are using hardware crypto or SIMD instructions. The Unmatched has neither crypto instructions nor SIMD -- those ISA extensions have just in November been ratified and will appear in RISC-V chips *maybe* later in the year, maybe next year. I don't recall if the A53 has Crypto instructions (the A72 does), but it certainly has SIMD, so I don't know why the gap is so small.

[brucehoult]

I didn't expect it to outperform a $5000 64-core AMD Threadripper, but I didn't expect it to get destroyed by a cheap, little, low-power $35 Raspberry Pi.

Then your expectations need recalibrating.

Performance is related to technology, specifically micro-architecture and process node. In these, the HiFive Unmatched is very similar to a PI 3.

Price is very strongly related to production volume. The PI is made in millions, the HiFive in hundreds. Also the HiFive has much higher spec RAM and I/O with 16 GB, M.2, PCIe etc.