Earlier quoted context omitted.
It's usually an enormous pain to set up. QEMU is probably the best option.
Depends on the language, it's pretty trivial with Go.
Yes, but they're compiling binutils.
RISC-V Is Sloooow
81–90 of 397 posts
Re: RISC-V Is Sloooow
#82there are projects for making high performance RISC-V chips like this one https://github.com/OpenXiangShan/XiangShan
Re: RISC-V Is Sloooow
#83Earlier quoted context omitted.
[flagged]
While true, it's typically not going to be impactful on system performance. There's a reason, for example, why the linux distros all target a generic x86 architecture rather than a specific architecture.
Some applications may target a generic x86 architecture without any impact on performance.
However, other applications which must do cryptographic operations, audio/video processing, scientific/technical/engineering computing, etc. may have wildly different performances when compiled for different x86-64 ISA versions, for which dedicated assembly-language functions exist.
Re: RISC-V Is Sloooow
#84Are you sure you are comparing apples with apples here? The fact that i686 is 14% faster than x86_64 is a little suspicious, because usually the same software runs _faster_ on x86_64 (despite the increased memory use) thanks to a larger register set, an optimized ABI, and more vector instructions. Of course, if you are compiling an i686 binary on i686, and an x86_64 binary on x86_64, then the compilers aren't really…
The x86-64 build runs about 50% more linker tests than the i686 build.
Re: RISC-V Is Sloooow
#85Earlier quoted context omitted.
> Also the bit manipulation extension wasn't part of the core. This is primarily because core is primarily a teaching ISA. One of the best parts about RiscV is that you can teach a freshman level architecture class or a senior level chip building project with an ISA that is actually used. Anything powerful to run (a non built from source manually) linux will support a profile that bundles all the commonly needed inst…
> One of the best parts about RiscV is that you can teach a freshman level architecture class or a senior level chip building project with an ISA that is actually used. Same could be said of MIPS. My understanding is the RISC-V raison d'etre is rather avoidance of patented/copywritten designs.
the avoidance of patent/copyright is critical for (legally) having students design their own chips. MIPS was pretty good (and widely used) for teaching assembly, but pretty bad for teaching a class where students design chips
Re: RISC-V Is Sloooow
#86Earlier quoted context omitted.
Bit manipulation instructions are part and parcel of any curriculum that teaches CPU architecture. They are the basic building blocks for many more complex instructions. https://five-embeddev.com/riscv-bitmanip/1.0.0/bitmanip.html I can see quite a few items on that list that imnsho should have been included in the core and for the life of me I can't see the rationale behind leaving them out. Even the most basic 8 bi…
This is the reason behind the profiles like RVA23 which include bitmanip, vector and a large number of other extensions. Real chips coming very soon will all be RVA23.
Neat. I can't wait to get my hands on a devboard.
Re: RISC-V Is Sloooow
#87Earlier quoted context omitted.
I don’t have a micro architecture background so I apologize if this is obvious — What do power and speed mean in this context?
Power - how many Watts does it need? Speed - how quickly can it perform operations?
You can get low power with a simple design at a low clock. This definitely will not help achieve high performance later.
Re: RISC-V Is Sloooow
#88there are projects for making high performance RISC-V chips like this one https://github.com/OpenXiangShan/XiangShan
OK, I'll bite. If this is a truly competitive core - I don't claim enough personal expertise to judge - does anyone fab and sell it? There should be a business case if it is.
Re: RISC-V Is Sloooow
#89Earlier quoted context omitted.
RISC-V doesn't have the pitfalls of Sparc (register windows, branch delay slots), largely because we learned from that. It's in fact a very "boring" architecture. There's no one that expects it'll be hard to optimize for. There are at least 2 designs that have taped out in small runs and have high end performance.
RISC-V does not have the pitfalls of experimental ISAs from 45 years ago, but it has other pitfalls that have not existed in almost any ISA since the first vacuum-tube computers, like the lack of means for integer overflow detection and the lack of indexed addressing. Especially the lack of integer overflow detection is a choice of great stupidity, for which there exists no excuse. Detecting integer overflow in hardw…
> On the other hand, detecting integer overflow in software is extremely expensive
this just isn't true. both addition and multiplication can check for overflow in <2 instructions.
Re: RISC-V Is Sloooow
#90Don't blame the ISA - blame the silicon implementations AND the software with no architecture-specific optimisations. RISC-V will get there, eventually. I remember that ARM started as a speed demon with conscious power consumption, then was surpassed by x86s and PPCs on desktops and moved to embedded, where it shone by being very frugal with power, only to now be leaving the embedded space with implementations optimi…
> Don't blame the ISA - blame the silicon implementations
That's true, but tautological.
The issue is that the RISC-V core is the easy part of the problem, and nobody seems to even be able to generate a chip that gets that right without weirdness and quirks.
The more fundamental technical problem is that things like the cache organization and DDR interface and PCI interface and ... cannot just be synthesized. They require analog/RF VLSI designers doing things like clock forwarding and signal integrity analysis. If you get them wrong, your performance tanks, and, so far, everybody has gotten them wrong in various ways.
The business problem is the fact that everybody wants to be the "performance" RISC-V vendor, but nobody wants to be the "embedded" RISC-V vendor. This is a problem because practically anybody who is willing to cough up for a "performance" processor is almost completely insensitive to any cost premium that ARM demands. The embedded space is hugely sensitive to cost, but nobody is willing to step into it because that requires that you do icky ecosystem things like marketing, software, debugging tools, inventory distribution, etc.
This leads to the US business problem which is the fact that everybody wants to be an IP vendor and nobody wants to ship a damn chip. Consequently, if I want actual RISC-V hardware, I'm stuck dealing with Chinese vendors of various levels of dodginess.