[aappleby]

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.

[BarsMonster]

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]

have you tested its rv64v vector performance

[camel-cdr]

Kinda hard to compare it against anything, but here are some benchmarks: https://camel-cdr.github.io/rvv-bench-results/milkv_pioneer/...

[kragen]

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]

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]

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

[adgjlsfhk1]

this is a great resource! any chance you can add a matmul benchmark to this?

[BarsMonster]

Not (yet)

[kragen]

that might be the hotspot of most everyday user interactions: decoding video, compositing windows, scrolling panes, redrawing windows, drawing text glyphs

[badgersnake]

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

[jsheard]

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

[DeathArrow]

>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.

[m00x]

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]

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]

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]

There is no problem with the compilers for RISC-V, what are you talking about?

[adgjlsfhk1]

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)

[FullyFunctional]

[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.

[brucehoult]

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).