This is a most excellent place for technology news and articles.
Any benchmarks? Seems like it bundles NN acceleration that competes with GPUs, but benchmarks/price matters.
best i got
RIVAI claims that the Lingyu processor’s computational performance rivals that of major international server chips from Intel and AMD.
This could be great news. RISC5 could be great for diversity in the processor space. I at will take investment on the scale that only a national investment like China can invest to get it to compete.
Does China have the Fab capability to build these, or do they need foreign production?
They have been making their own x86 knock-offs for a while now, but not at the same scale as the "regular" - i.e. they'd been doing it at 14nm or so, so less efficient.
I don't know if they have better fab process since then, and for how big a scale.
Their x86 fabs are producing a 5 yr old Intel node, and with unknown defect rate. This is about getting down to the modern node size to (eventually) to get competitive with the two major ARM nodes.
About that last sentence about software support determining the future of risc-v. It will overtake x86 (eventually) just due to the nature of OSS. At first OS platforms arent as good... Until suddenly they are. Ask Apple. When the iPhone first launched, it was a million times better than Android. And yet now they are totally on par with each other. And Android has the edge in a lot of cases.
Android gets a leg up from being built on a FLOSS base but I don't think it was the community that pushed Android to where it is today. That's taken a lot of money and resources from Google and it's phone partners investing in the slightly more open platform than Apple.
Another example would be Home Assistant. Why exactly should my device have to connect to the internet and communicate with a cloud server somewhere that can be shut down only to communicate with my phone back at my house? With Home Assistant, my device communicates locally with my Home Assistant device and my Home Assistant device communicates locally with my phone. No internet required.
No, almost all of the UI features we think normal of a smartphone today, were first on a custom ROM.
Same for desktop btw.
Lol
They've been spending tens of billions a year in their chip industry.
and, honestly, RISC-V is the right place to spend it. RISC has super powers.
What do you mean by that. RISC-V is open source but it doesn't have "superpowers" that I know of?
"reduced" is the super power. I would much rather put the smarts into the assembler/compiler/interpreter than the silicon. have been followed RISC since the 80's and discovered that I am really a RISC guy living in CISC world. open arch is the world dominating cherry-on-top.
That's not really true. Yes avoiding complex instructions makes the front end easier to pipeline but there are lots of smarts in the backend to do prediction and scheduling to keep the execution units fed. The ISA might be free to use but no one is sharing their highly optimised server silicon architecture designs.
RISC-V's challenge is can they standardise the software ecosystem enough that things just work across a multitude of chip providers or does everything devolve into specialist distributions taking advantage of each manufacturers "special sauce" custom instructions.
Gaining design wins over Arm's microcontrollers for bespoke hardware was the easy bit. Replacing stuff in the server space is much harder and something that took Arm decades to make inroads into.
great reply. I am not saying RISC is the panecea, what I am saying is that there are more options for workload optimization further up the stack and rebalancing of the intelligence from the silicon to the software is an advantage.
some time ago most CISC core design become more RISC-y and, to indulge in some ISA snobbery, I just want to slash and burn the CISC presentation to the software layer. memory is cheap, bus bandwidth is insane - simplification on the ISA just seems like a hardware complexity win all around and I am willing to pay for that in compiler complexity that incorporates changes more easily than hardware or CISC microcode.
RISC-V's challenge is can they standardise the software ecosystem enough[...]
agreed. this is why I say my wait may be coming to an end.
personally, I think RISC is the more flexible design in almost every usecase. cycle for cycle, RISC hits the right buttons for me across the widest number of situations once we get above the "magic hardware" layer. willing to flog the CISC vs RiSC horse convo if you have recent information, and thanks for the response.
This is a purely theoretical arguement.
Ecosystem momentum makes this argument mute.
meh (not dismissive - just cute), ecosystem mootness is overrated. at the heart of every CISC beats a RISC. strip away the mask and lets poke the nuclear core.
Do you have any resources by any chance that explain the difference well?
I work in high level software, so understand the benefit of doing things at ide time vs compile time vs runtime, and I've coded in assembly back in the day and understand instruction sets at a very rough level, but I'm not really familiar with specifically what differentiates RISC / ARM / x64, or why RISC's reductions would be good / bad / what trade-offs come with them.
between the 30k' overview of Reduced instruction set computer (RISC) architecture and the lower level RISC-V Architecture: A Comprehensive Guide to the Open-Source ISA, you should get a pretty decent feel for it.
the level of optimization you get via hardware and software tooling is honestly pretty spectacular. I have been waiting for RISC to come out of hiding for years and it seems to be happening.
Which is faster?
CPI per CPI... RISC, but thats a trap of a question and you know it ;-)
tons of variables in that question, but there should be more headroom in RISC designs and thats why, internally, most things are RISC-y.
It's not a trap.
ok. my apologizes.
there really are tons of things to consider with that question. RISC has historically allowed for faster clocking and fewer cycles per instruction, so thats a win. RISC also requires more instructions per useful operation and also blows up the binary size, so... :-(
all things being equal (hahaha) RISC has more headroom and legroom for future improvements that dont complecate the silicon to extreme degrees. the vast majority of CISC designs are now pretty RISC-like at their cores, but the software interface remains CISC and, I think, complicates and limits variety and advancement.
imho, a properly spec'd RISC processor and a carefully designed compiler, cycle for cycle, macro for macro and watt for watt outperforms a CISC design (even with a RISC-like core). major computing holy wars are been waged over this for decades.
all I currently have access to are older studies that show mixed general purpose results on RISC vs CISC (performance, not power efficiency), but if I had to make a choice about what my future ideal processor would be, it would be RISC core and RISC instruction set architecture simply due to less complexity, more efficient use of wafer space and lower power requirements. then we start talking about massively parallel RISC in tiny spaces and, for many (but not all) workloads, thats a big win.
It'll get there quick.
I worked on HPC cpus, scaling up isn't that hard, the hard part is dealing with your Isa baggage.
Yeah, RISC is good.
Wow, all the down votes. Youngin's don't know what they're missing. Classic film.
Triple the speed of a Pentium..
Edit: it was triple I said double originally. I'm sorry for my indiscretion.
Seems like it's specs are still unknown?
Fine, they've made a processor, but until I have an idea of how well tested and secure it is, I'm not running anything on it. I don't mean in a "Oh China, scary!" way but just because it's an unknown brand with no track record.
Making something that works most of the time is one thing. Making something bulletproof is another.
...and they're positioning this for servers.
Sorry to inform you, but all of our infrastructure runs on layers of hacks already.
this is so deliciously and disappointingly true. :-/
