Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC-V Is Sloooow

marcin.juszkiewicz.com.pl

Post reply on HN
Print view View original

101–110 of 397 posts

Re: RISC-V Is Sloooow

#101

Post by jacquesm »

kevin_thibedeau wrote: post #92
jacquesm wrote: post #73

Earlier 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…

32-bit barrel shifters consume significant area and RISC-V was developed to support resource constrained low cost embedded hardware in a minimal ISA implementation.

You can save a lot of silicon by doing 8 or 16 bit shifters and then doing the rest at the code generation level. Not having any seems really anemic to me.

Re: RISC-V Is Sloooow

#103

Post by weebull »

wmf wrote: post #87
McP wrote: post #29

Earlier quoted context omitted.

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.

Clock rate isn't the only factor. A design can be power hungry at a low clock rate if designed badly, and if it it is... you're never getting that think running fast.

Re: RISC-V Is Sloooow

#104

Post by LeFantome »

menaerus wrote: post #8
rbanffy wrote: post #4

Earlier quoted context omitted.

I did read it. A Banana Pi is not the fastest developer platform. The title is misleading. BTW, it's quite impressive how the s390x is so fast per core compared to the others. I mean, of course it's fast - we all knew that. And don't let IBM legal see this can be considered a published benchmark, because they are very shy about s390x performance numbers.

Which risc-v implementation is considered fast?

> Which risc-v implementation is considered fast?

SpacemiT K3 is 2010 Macbook performance single-core, 2019 Macbook Air multi-core, and better than M4 Apple Silicon for AI.

So I guess it depends on what you are going to do with it.

Re: RISC-V Is Sloooow

#105

Post by NekkoDroid »

jacquesm wrote: post #86
rwmj wrote: post #75

Earlier quoted context omitted.

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.

The earlierst I know of coming is the SpaceMit K3, which Sipeed will have dev boards for.

Re: RISC-V Is Sloooow

#106

Post by LeFantome »

kllrnohj wrote: post #52
IshKebab wrote: post #15

Yeah it's a few years behind ARM, but not that many. Imagine trying to compile this on ARM 10 years ago. It would be similarly painful.

> Imagine trying to compile this on ARM 10 years ago Cortex A57 is 14 years old and is significantly faster than the 9 year old Cortex A55 these RISC-V cores are being compared against. So yes it's many years behind. Many, many years.

SpacemiT K3 is on par with Rockchip RK3588. So, about 4 years behind ARM.

Tenstorrent Atlantis (first Ascalon silicon) should ship in Q2/Q3 and be twice as fast. About as fast as Ryzen5. So, about 5 years behind AMD.

But even the K3 has faster AI than Apple Silicon or Qualcomm X Elite.

Current trend-lines suggest ARM64 and RISC-V performance parity before 2030.

Re: RISC-V Is Sloooow

#107

Post by jmalicki »

sltkr wrote: post #61

Are 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…

It isn't crazy uncommon to see i686 be faster - usually it means you're memory bandwidth bound.

But yeah, it may mean the benchmark is not representative.

Re: RISC-V Is Sloooow

#108

Post by crest »

rbanffy wrote: post #2

Don'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…

RISC-V lacks a bunch of really useful relatively easy to implement instructions and most extensions are truly optional so you can't rely on them. That's the problem if you let a bunch of academics turn your ISA into a paper mill.

In theory you can spend a lot of effort to make a flawed ISA perform, but it will be neither easy nor pretty e.g. real world Linux distros can't distribute optimised packages for every uarch from dual-issue in-order RV64GC to 8-wide OoO RV64 with all the bells and whistles. Only in (deeply) embedded systems can you retarget the toolchain and optimise for each damn architecture subset you encounter.

Re: RISC-V Is Sloooow

#109

Post by 15155 »

Levitating wrote: post #23

This is why felix has been building the risc-v archlinux repositories[1] using the Milk-V Pioneer. I think the ban of SOPHGO is part to blame for the slow development.[2] They had the most performant and interesting SOCs. I had a bunch of pre-orders for the Milk-V Oasis before it was cancelled. It was supposed to come out a while ago, using the SG2380, supposedly much more performant than the Milk-V Titan mentioned i…

Can you articulate why you think this ban impacted anything and what you think the ban applies to?

Re: RISC-V Is Sloooow

#110

Post by adrian_b »

cogman10 wrote: post #99
adrian_b wrote: post #83

Earlier quoted context omitted.

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.

Granted, these applications do exist. They are simply becoming more and more rare. I'd also say that there's been a pretty steady dedicated effort to abstracting the assembly. It's still pretty low level, as in you are caring about the specific instructions being used, but it's also not quite assembly in both C++/rust. Java, interestingly enough, is somewhat leading the way here with their Vector API. I think they ac…

I would not say that such applications are becoming more and more rare.

Most of the applications whose performance matters for me, because I must wait a non-negligible time for them to do their job, are dependent on assembly implementation for certain functions invoked inside critical loops. I do not see any sign of replacements for them. On the contrary, Intel, AMD and Arm continue to introduce special instructions that are useful in certain niche applications and taking advantage of them will require additional assembly language functions, not less.

For me, there is only one application that I use and which consumes non-negligible computer time and which does not depend on SIMD optimizations, which is the compilation of software projects.

Post reply on HN