4 ms·

Completely false. This is compared to native versions on all platforms. Supposedly TH1520 gets a small uplift when compiled for its proprietary extensions, bu

Completely false. This is compared to native versions on all platforms. Supposedly TH1520 gets a small uplift when compiled for its proprietary extensions, but I haven't seen a compiler using this and it would have no bearing on application from a standard distribution. I have both 7110 and TH1520, but I'm looking forward to SiFive P670 powered SG2380 which promises to be an exciting chip.

adgjlsfhk1 3y ago
it is a problem that the compilers for riscv are still pretty bad. it will take a few years (and more cheap risc-v dev boards) before gcc and clang actually know how to generate good code for risc-v (this is especially a problem for things like video payback and encryption that tend to be written with significant amounts of hand tuned assembly)
- brucehoult 3y ago
  There is no problem with the compilers for RISC-V, what are you talking about?
  - adgjlsfhk1 3y ago
    the compilers work (produce valid code), but things like chip specific instruction cost models, full support for vector operations, and stuff like that are nowhere near where they are for x86 or M1 (because there are way less users and developers to make sure the codegen is optimal)
    - brucehoult 3y ago
      Core-specific cost models are a bad idea when you have a large variety of cores in use. Auto-vectorisation doesn't work well on anything, except in the most trivial cases, and none of the popular boards [1] yet have the official RISC-V vector ISA anyway -- that will change this year, hopefully. [1] there is now in the last month or two one (1) board with RVV 1.0 but it's only single core vs the quad core in popular boards, and also has only 512 MB of RAM vs 4 / 8 / 16 GB on the popular boards (and 128 GB on the Pioneer).
    - FullyFunctional 3y ago
      [citation needed] Do you have anything concrete to support "nowhere near where they are for x86 or M1"? I literally eyeball RISC-V code all day long for a living and it's not like there a massive performance lost to the compiler.

adgjlsfhk1 3y ago

it is a problem that the compilers for riscv are still pretty bad. it will take a few years (and more cheap risc-v dev boards) before gcc and clang actually know how to generate good code for risc-v (this is especially a problem for things like video payback and encryption that tend to be written with significant amounts of hand tuned assembly)

brucehoult 3y ago
There is no problem with the compilers for RISC-V, what are you talking about?
- adgjlsfhk1 3y ago
  the compilers work (produce valid code), but things like chip specific instruction cost models, full support for vector operations, and stuff like that are nowhere near where they are for x86 or M1 (because there are way less users and developers to make sure the codegen is optimal)
  - brucehoult 3y ago
    Core-specific cost models are a bad idea when you have a large variety of cores in use. Auto-vectorisation doesn't work well on anything, except in the most trivial cases, and none of the popular boards [1] yet have the official RISC-V vector ISA anyway -- that will change this year, hopefully. [1] there is now in the last month or two one (1) board with RVV 1.0 but it's only single core vs the quad core in popular boards, and also has only 512 MB of RAM vs 4 / 8 / 16 GB on the popular boards (and 128 GB on the Pioneer).
  - FullyFunctional 3y ago
    [citation needed] Do you have anything concrete to support "nowhere near where they are for x86 or M1"? I literally eyeball RISC-V code all day long for a living and it's not like there a massive performance lost to the compiler.