$666 is an improvement over $1k.
It's still a core without V or B extensions, and still prohibitively expensive for anyone that doesn't need them.
Useful for those working on risc-v ports, and that's about it.
It's still a core without V or B extensions, and still prohibitively expensive for anyone that doesn't need them.
Useful for those working on risc-v ports, and that's about it.
That's a 4.5x price reduction (or 77.8% off if you prefer) in three years.
The price/performance increase should be bigger than that because of the ~50% increase in IPC and also hopefully a ~33% increase in clock speed (they don't seem to have announced that but it should be around 2 GHz)
Also it's a just a little unrealistic to expect something that will have taped out 6 to 9 months ago to have extensions that aren't even at draft 1.0 status yet, let alone ratified. Any chip with those is going to be 18 to 24 months away.
This was based on SiFive's recent announcements.
https://www.businesswire.com/news/home/20200914005108/en/SiF...
Together with claims earlier this year that there'd be some ratified V (a 1.0 draft?) by September and they'd have chips ready pretty much immediately.
What I understand at this point is that this simply hasn't happened, but I do not know the specifics.
What I believe they've said in the past is they'll have cores available for licencing immediately, and indeed the "VIU75" with "Vector Intelligence" was announced last week. Customers will be able to sign contracts now, and get preliminary near-1.0 RTL to use in FPGAs for testing and software development. By the time the customers are ready to tape-out in six or twelve months the final spec-compliant RTL would be available.
Isn't this one supposed to be 4 (main) cores @ 1GHz?
V is close, B is not. There are exactly 0 chips or even IP on the market with standard B (which is really a family of sub-standards), but there are chips with pre-standard V (alas, a few of them aren't compatible with the current draft - the perils of running ahead).
Overall, yes you are right, this is most useful for people interested in seriously evaluating RV64GC and/or porting code. It's a one of the necessary steps on the path to more adoption, but not the last one.
Do you have a rationale for this? I understand that:
* The unix platform standard is a relatively fat selection of extensions already.
* The nature of V's flexible width allows it to be implemented in very small scale to very large scale, so it would have little impact on the complexity of the minimum platform, while allowing great benefits as it scales up to larger platforms.
2. RV64GC is already quite big. Piling more requirements onto it will make it harder to introduce small cores.
3. V is pretty complex and I don't agree with your assertion. In contrast I'm aware of cores with vector where the vector part takes up 50% of the die and does exactly nothing for the scalar apps that don't use it. I'd much rather spend that silicon on more IPC or a 2nd core.
It comes with the CPU, motherboard, and RAM, all in one package.
When you sum up the costs of those in your typical desktop PC workstation build, it's not really that far off.
Unfortunately, the RAM not being socketed means you're limited to 8GB, which disqualifies this machine as workstation.
Low CPU performance is tolerable, system chocking on low RAM isn't. I'm suffering on a laptop that "only" has 16GB RAM, and this is despite minimizing the load by alternating between Sway and i3 depending on mood on boot. Editor, Browser (unavoidably heavy, with a ton of tabs open as part of the workflow), PDF viewer, Music player and little else. Everything is bloated these days.
I don't see how 8GB can be tolerable as a workstation. It really is a deal breaker.
We really need to get POPCOUNT into the base (at least) 64-bit core set.
Of course popcount will have an opcode allocated and binutils and gcc will (already do) know how to use it if it is present, so anyone who wants/needs it can implement it.
Ignorance, or corruption?
it's honestly pretty baffling that RISC-V doesnt have it (perils of design-by-academia)
I get that there are a lot of narrow-use instructions but popcount is a pretty well-known and common operation.
(edit: also it seems that ARM has just cnt.v8 for counting 8-bit lanes in NEON and no 64-bit scalar instruction version, interesting. Being part of NEON also means it's an optional part on ARM)
Because it provides order-of magnitude speed improvements for numerous algorithms. Because it is the basis for integer log-base-2.
If you don't know what popcount is good for, or badly miss it where it is lacking, your education has suffered. That is remediable.