Ventana’s Unconventional Veyron V1
chipsandcheese.com
chipsandcheese.com
Then he went on his way and I tried following him to see if he brings some quality independent content but it's so derivative. There's no deep insight, no originality. He's just reprocessing info from primary sources. At one point I felt like watching reaction videos and eventually decided to stick with those primary sources. I hope he finds his niche though.
Is it some kind of Indian effort to create indigenous CPUs?
RISC-V enables the best processors.
There's definitely better and worse ISAs e.g. some are unjustifiably complex.
Yet the key advantage of RISC-V is not at all technical, and lies in its licensing scheme.
There is no need to ask for permission to implement RISC-V and thus be able to leverage the best ecosystem out there, which RISC-V is rapidly building.
There is also no need to ask for permission to extend it with custom extensions, to suit your specialized needs.
Using the RISC-V trademarks is only a little more complicated, as it requires proving standard compliance.
Yet this aligns well with most implementations; Compliance is desirable as it enables tapping into existing software and tooling, which is much cheaper than building and maintaining bespoke solutions.
As for licensing I agree that it can be seen as a step in the right direction, but at the same time it seems like we absolutely refuse to learn.
All standards inevitably deprecate, I'd prefer every hardware manufacturers to come up with their own one-off ISA and an easy way to run/interpret existing applications.
Software ecosystems are more about locking you to a specific vendor/standard, they prevent the emergence of better systems.
> Our software is order of magnitudes slower than it could be, RISC-V or x86 doesn't change anything.
That's not really true, the most critical bits of the stack or often implemented pretty fast.
This is what DEC learned: "The conclusion was clear: for any given amount of investment, the RISC designs would outperform a VAX by 2-to-1."
- DEC is dead, long live DEC
I'm not suggesting that it is 2-to-1 now but its still relevant.
I notice your "the best" actually is artificially restricted to something very narrow, I have to assume you mean "the fastest" at some specific TDP, which happens to be the one M1/M2 target. This is evident, as if you had more watts available, there are faster chips out there which were not designed by Apple.
And the reason there's no RISC-V chips targeting M1 out there yet is quite simple: Hardware development cycles are long.
Most RISC-V CPUs out there are based on the very first ratified privileged and unprivileged specs from 2019.
Next year, the first ones based on the batch of specs ratified in 2021, which are important for performance (bit manipulation, vector, hypervisor and so on) are expected to show up.
One of them is Tenstorrent's Ascalon, and the lead of the team that designed that one is the same man who led M1 at Apple. They've done presentations in which they present performance as competitive with projected Zen5, yet at lower power and smaller area.
Yet there are a lot of definitions for "the best" outside of your narrow focus. For instance, ARM has a range of processors targeting a range of markets, including microcontroller, LITTLE cores, realtime, fault-tolerant and so on. Most of these are bested in Power Performance Area by RISC-V designs already in the market.
SiFive does, by itself, manage this much, but there are already tens of companies offering hundreds of competitive designs for licensing.
RISC-V is inevitable.
There are a plethora of benchmarks that fall apart for Apple processors, and they hardly compare to most x86 or Power processors when you change the TDP envelope.
As with any chip design, they're targeted for a specific use case and they shine in that realm. That hardly makes them "the best" and that claim does a disservice to a multitude of engineers at other firms with other design considerations.
No, that is not the use case the M cores are tuned for. "Power efficient Apple-based computing" would be a better descriptor. It's useful to keep the entire context of the response in mind, when replying.
> It's useful to keep the entire context of the response in mind, when replying.
Don't be glib.