7 ms·

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)
      - kragen 3y ago
        thanks, this information is fantastic i really hope to have a chance to read your blog post! i haven't tried rvv programming at all
        camel-cdr 3y ago
        It's up now: https://camel-cdr.github.io/rvv-bench-results/articles/vector-utf.html https://camel-cdr.github.io/rvv-bench-results/articles/vecto...
      - adgjlsfhk1 3y ago
        this is a great resource! any chance you can add a matmul benchmark to this?
        camel-cdr 3y ago
        I was thinking about that, but matmul is so too hardware specific (cache sizes, and the like), and I'm not confident I can get an implementation that can get close to max performance.
        adgjlsfhk1 3y ago
        getting big matmul good is hard, but up to about 100x100 you don't need to worry about cache sizes, it's all about the microkernel

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)
    - kragen 3y ago
      thanks, this information is fantastic i really hope to have a chance to read your blog post! i haven't tried rvv programming at all
      - camel-cdr 3y ago
        It's up now: https://camel-cdr.github.io/rvv-bench-results/articles/vector-utf.html https://camel-cdr.github.io/rvv-bench-results/articles/vecto...
    - adgjlsfhk1 3y ago
      this is a great resource! any chance you can add a matmul benchmark to this?
      - camel-cdr 3y ago
        I was thinking about that, but matmul is so too hardware specific (cache sizes, and the like), and I'm not confident I can get an implementation that can get close to max performance.
        adgjlsfhk1 3y ago
        getting big matmul good is hard, but up to about 100x100 you don't need to worry about cache sizes, it's all about the microkernel