←back to thread

150 points sohkamyung | 2 comments | | HN request time: 0.4s | source
Show context
v1ne ◴[] No.42131132[source]
This JH7110 is from 2021. Some specs: https://www.cnx-software.com/2022/08/29/starfive-jh7110-risc...

1.5 GHz CPU core frequency, some old RISC-V cores while we're still waiting for cores with decent single-core performance to compete with modern desktop processors.

Sorry, but for me this board is dead in the water, unless you can't use ARM/x86 for political reasons.

replies(2): >>42131171 #>>42131448 #
0x457 ◴[] No.42131171[source]
It's a dev board. Reason to buy it: you need a desktop that has RISC-V cpu inside.
replies(2): >>42131225 #>>42131356 #
adgjlsfhk1 ◴[] No.42131225[source]
The problem is that it's a dev board that will likely be slower than QEMU, and is missing half of the Risc-V extensions that you want to test with. (and it supports a maximum of 8gb of ram, so good luck compiling LLVM on it)
replies(2): >>42131651 #>>42131656 #
brucehoult ◴[] No.42131656[source]
An N100 running QEMU will be slower. A machine that is faster running QEMU will cost a lot more.

For example my 6 core Zen2 laptop runs my primes benchmark (small code, long-running, the best possible case for qemu-user) 10% slower than my VisionFive 2. If you want to run a whole emulated OS then qemu-system is a lot slower than qemu-user.

My i9-13900 laptop runs the same benchmark in qemu-user 2.6x faster than the VisionFive 2, but it also costs 30x more -- or about 2x more than the Frame laptop with the JH7110 mainboard. Or 5x more than the original DC Roma laptop with the JH7110 now costs ($299).

If you want a RISC-V laptop then Frame is a very expensive way to get one. It might be higher quality, and it will be upgradable to better specs later.

replies(1): >>42134454 #
1. ywvcbk ◴[] No.42134454[source]
> will cost a lot more.

Presumably everyone buying this thing would already have (or need) a proper PC/Mac to use alongside it.

replies(1): >>42135222 #
2. brucehoult ◴[] No.42135222[source]
Maybe. Or they might only have a phone/tablet. Or an older but still totally useful machine such as that Zen 2 laptop I mentioned, which runs qemu slower than the VisionFive 2.

Also, a number of people have come unstuck by writing and testing things ONLY on qemu, and then had them fail on real hardware. For example, qemu was historically much more lenient with PMP settings than real hardware (if you didn't touch the PMU then qemu acted as if you didn't have one at all). Also anything that needs fences on real RISC-V (or Arm) hardware is likely to work even when it's incorrect on a PC that is jitting multiple instructions per RISC-V instruction and is TSO anyway. Qemu being lenient about setting up the UART (e.g. it doesn't care about baurd rate, start/stop bits etc) compared to real hardware is another example.