4 ms·

I have one of these as well - the distro I installed has a broken Chrome that crashes shortly after startup, hopefully that's fixed now. The case is prototype-

I have one of these as well - the distro I installed has a broken Chrome that crashes shortly after startup, hopefully that's fixed now. The case is prototype-quality but fine (the fact that it's metal helps a lot), the screen is nice, the keyboard is even more awkward than it needs to be for the size. I've been a bit disappointed by the performance in my tests (compiling various projects of mine with GCC), it seems closer to a Raspberry Pi 3 than a 4 or 5.

m00x 3y ago
I think it's mostly a case of software not being optimized for RISC-V. The sipeed website indicates that it's much faster if the benchmarks are built with optimized toolchains. I imagine it has x64 or arm7 emulator for most builds.
- FullyFunctional 3y ago
  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.
DeathArrow 3y ago
>it seems closer to a Raspberry Pi 3 than a 4 or 5. SOC is fabbed on a 12nm process and the CPU is under clocked from 2Ghz to 1.5 GHz. Probably the CPU is not intended for laptops and the manufacturer just got a generic board, slapped another 2 boards on top for I/O and built a laptop.
BarsMonster 3y ago
My tests show it's slightly slower than Pi 4 and significantly faster than Pi 3 on CPU performance. 1T Coremark: Pi 3: 3504 Lichee: 6900 Pi 4: 7938
- kragen 3y ago
  have you tested its rv64v vector performance
  - BarsMonster 3y ago
    Not (yet)
    - kragen 3y ago
      that might be the hotspot of most everyday user interactions: decoding video, compositing windows, scrolling panes, redrawing windows, drawing text glyphs
  - camel-cdr 3y ago
    Kinda hard to compare it against anything, but here are some benchmarks: https://camel-cdr.github.io/rvv-bench-results/milkv_pioneer/index.html https://camel-cdr.github.io/rvv-bench-results/milkv_pioneer/...
    - kragen 3y ago
      this is fantastic! they're the first sophon benchmark results i've seen, and they're far more comprehensive than most benchmark results of any kind have you run into any toolchain difficulties due to the 0.7.1 nature of the rvv?
      - camel-cdr 3y ago
        Yes. I'm using the old gnu toolchain branch from brucehoult and write the benchmarks such that they work in rvv 1.0 and rvv 0.7.1. To help with that I've got a gnu assembler macro file that does 1 to 1 instruction translation when possible and for the other cases I need to #if/#else/#endif. I'm working on rvv unicode conversions, and plan to release a blog post/article with benchmarks and explanation soon. The problem is that I've uses c intrinsics to write it, so I need to manually translate the assembly code to rvv 0.7.1 compatible code. That entails vsetivli -> vsetvli vle64 -> vle32 vmvNr -> vmv.v.v & 2 vsetvli vzext.vN -> N/2 vwaddu & N/2+1 vsetvli in my case. Also, the board I've got access to (it might be an eval board, idk) has a bug in vredmax, so I also needed to adjust the code to not use that. (I've yet to investigate that further)
badgersnake 3y ago
Is JIT for JavaScript supported on RISC-V? This was an issue in PPC for a long time.
- jsheard 3y ago
  Per the V8 site, the JIT is only fully supported on x86 and ARM. There is a RISC-V port available on a YMMV basis but I don't know what state it's currently in. https://v8.dev/docs/ports https://v8.dev/docs/ports

m00x 3y ago

I think it's mostly a case of software not being optimized for RISC-V. The sipeed website indicates that it's much faster if the benchmarks are built with optimized toolchains. I imagine it has x64 or arm7 emulator for most builds.

FullyFunctional 3y ago
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.

DeathArrow 3y ago

>it seems closer to a Raspberry Pi 3 than a 4 or 5. SOC is fabbed on a 12nm process and the CPU is under clocked from 2Ghz to 1.5 GHz. Probably the CPU is not intended for laptops and the manufacturer just got a generic board, slapped another 2 boards on top for I/O and built a laptop.

BarsMonster 3y ago

My tests show it's slightly slower than Pi 4 and significantly faster than Pi 3 on CPU performance. 1T Coremark: Pi 3: 3504 Lichee: 6900 Pi 4: 7938

kragen 3y ago
have you tested its rv64v vector performance
- BarsMonster 3y ago
  Not (yet)
  - kragen 3y ago
    that might be the hotspot of most everyday user interactions: decoding video, compositing windows, scrolling panes, redrawing windows, drawing text glyphs
- camel-cdr 3y ago
  Kinda hard to compare it against anything, but here are some benchmarks: https://camel-cdr.github.io/rvv-bench-results/milkv_pioneer/index.html https://camel-cdr.github.io/rvv-bench-results/milkv_pioneer/...
  - kragen 3y ago
    this is fantastic! they're the first sophon benchmark results i've seen, and they're far more comprehensive than most benchmark results of any kind have you run into any toolchain difficulties due to the 0.7.1 nature of the rvv?
    - camel-cdr 3y ago
      Yes. I'm using the old gnu toolchain branch from brucehoult and write the benchmarks such that they work in rvv 1.0 and rvv 0.7.1. To help with that I've got a gnu assembler macro file that does 1 to 1 instruction translation when possible and for the other cases I need to #if/#else/#endif. I'm working on rvv unicode conversions, and plan to release a blog post/article with benchmarks and explanation soon. The problem is that I've uses c intrinsics to write it, so I need to manually translate the assembly code to rvv 0.7.1 compatible code. That entails vsetivli -> vsetvli vle64 -> vle32 vmvNr -> vmv.v.v & 2 vsetvli vzext.vN -> N/2 vwaddu & N/2+1 vsetvli in my case. Also, the board I've got access to (it might be an eval board, idk) has a bug in vredmax, so I also needed to adjust the code to not use that. (I've yet to investigate that further)

badgersnake 3y ago

Is JIT for JavaScript supported on RISC-V? This was an issue in PPC for a long time.

jsheard 3y ago
Per the V8 site, the JIT is only fully supported on x86 and ARM. There is a RISC-V port available on a YMMV basis but I don't know what state it's currently in. https://v8.dev/docs/ports https://v8.dev/docs/ports