Sipeed unveils RISC-V tablet, portable Linux console, and cluster | Hacker News Reader

Sipeed unveils RISC-V tablet, portable Linux console, and cluster

cnx-software.com

54 pointsshallow-mind37 comments

Note this is the same TH1520 in the same module as Lichee Pi4A.

I prefer StarFive's JH7110 and the devices based on it (VisionFive 2, Pinetab-V, Star64...), due to their documentation and upstreaming effort[0], alongside its higher power efficiency.

0. https://rvspace.org/en/project/JH7110_Upstream_Plan

The JH7110 is also standards compliant unlike the TH1520 which includes a significant amount of proprietary extensions as well as an incompatible RVV extension.

However the TH1520 is roughly twice as fast as the JH7110. What we really need to for a faster and standards compliant core to come out to make this a moot issue.

>The JH7110 is also standards compliant unlike the TH1520 which includes a significant amount of proprietary extensions as well as an incompatible RVV extension.

I do not think this is true. Having custom extensions is allowed in RISC-V: There is instruction encoding space reserved for them. It does not prevent execution of standard code, RVA20 (roughly what most call RV64GC) code will run with no issue in these processors.

>as well as an incompatible RVV extension.

AIUI, this pre-ratification 0.7.1 version of RVV is just a custom extension in practice. These chips won't run V 1.0 code, nor will V 1.0 processors run code for 0.7.1, but that's about it incompatibility-wise.

RISC-V is designed to accommodate this sort of thing well.

>However the TH1520 is roughly twice as fast as the JH7110.

In some cases. In others (e.g. compiling code) it turns out to be actually slower. The reasons are not currently understood.

Note TH1520 draws more than twice the power on load. TH1520 will definitely need active cooling, whereas JH7110 can in many applications get by w/o even a heatsink, thus being adequate for different scenarios.

Built to tolerate 125C, JH7110 will barely reach 70C on VisionFive 2 while compiling w/o heatsink, thus it will be other components in the board that'll make a heatsink desirable. I added it because I specifically don't want the M.2 SSD under the same board to get hot.

Really great progress upstreaming. Tons of stuff upstream. Couple of the harder pieces like PCIe recently submitted. All within basically a year since announcements! This is how you do it!! https://www.google.com/amp/s/www.cnx-software.com/2022/08/29...

>All within basically a year since announcements!

And within half of shipping date (March).

Part of me really wants to be the chip design startup that makes multi-host chips. Let everyone else make cores, & focus on making NIC + switches designed for a dozen small systems, designed for low power clusters like this.

The slots have separate load averages in https://sipeed.com/assets/cluster-la.45176f2b.jpg, so it really is a cluster with multiple kernels running.

The cluster seems most non-sensical to me. I'd instead look at SOPHON SG2042[0], such as in the Milk-V Pioneer[1] board.

0. https://www.sophgo.com/product/introduce/sg2042.html

1. https://milkv.io/pioneer

We don't know the price yet. The cluster might work out to similar price/performance to the Pioneer, just with half of each and a worse programming model.

Have you noticed the Pioneer price has increased from $1999 to $2499?

You can buy 16 of the 8 GB RAM + 8 GB eMMC Lichee Pi 4As for $1904 and you'll have the same 64 cores, the same 128 GB RAM, and now $600 left over to buy power supply, case, some nice ethernet or USB3 switch. You won't have that 64 MB of L3 cache, and you'll have a cluster programming model instead of a single OS instance.

I assume the 7 module cluster will give at least some cost savings over buying individual LPi4As, and certainly more convenience, though less so than a Pioneer.

>and a worse programming model.

Having several computers in a cluster is not comparable to having the same amount of cores in a single chip.

A worse programming model indeed, by no less than an order of magnitude.

The one use I see for it would be research into scaling in clusters.

Such a cluster might be useful for a distribution build farm, where you can fan out builds across the cluster (instead of trying to distribute a single build). It depends on whether the hardware is actually shipping now (obviously), how stable it is, and if the system has decent remote management. Of course, most people in the RISC-V camp probably hope to move beyond such hacks sooner than later.

Even for a single build, distcc has been around and doing a pretty good job of papering over this problem since the mid 2000s.

Else, we can have a Beowulf cluster of LM4A.

Moving forward.

That said I still dunno which 64bits risc-v MCU board I'll use for my future keyboard (if I ever get the brain time and energy). For the moment I am targetting a mango pi with a D1 (yeah, completely overkill, but I really don't want to code the firmware in 32bits, as I would code it in 100% assembly, without abusing any preprocessor of course).

Hopefully RISC-V will be successul. For that, it must have extremely performant implementations in major use cases (server/desktop/mobile).

Why is 64-bits a requirement?

Because I will code once 64bits risc-v assembly.

Sounds like a one-off custom project. So RV32 or RV64 shouldn't matter. Apart from the register size, assembly for these is very similar if not the same.

Disadvantage of complex SoCs is that even if you use just a few peripherals, several other peripherals might get in the way or need initialization even if you're not using them (like onboard flash, DRAM controller timings, or power management). To some degree bootloaders take care of this. Which leaves you with an overly complicated (+ time consuming) boot process before your code can do useful stuff.

Not to mention power consumption. Or the cost of keeping spares around.

If you want to go RISC-V route for this, I'd recommend to just pick a lowly uC (or more likely, a board it sits on), like:

  GigaDevices GD32VF103
  WCH CH32V series

A step up:

  Bouffalo Lab BL808
  Allwinner F133
  Milk-V Duo

I'm not aware of an extensive / complete list of such parts or boards. But there are more out there (and new ones popping up).

I would personally reach for a BL602 or BL616. They're RV32IMAFC MCU cores that would be good for a keyboard project.

I know risc-v 32bits and 64bits instructions are very similar... but it is not the same in the end: I prefer to write 64bits risc-v code paths once and for all.

I have already a few GD32VFG10[12] boards, but the MCU is 32bits, I avoid them.

BTW, the bouffalo has a 32bits risc-v MCU, the 64bits risc-v is only a "guest" processor.

And of course, initing a complex SOC can be a nightmare if really badly done, it all depends on the SOC, but the code is usally around.

But do you know of a mini-board with plenty of available GPIOs (~30), a USB-C port and a USB device block, RV64 ofc. The only one seems to be the mango pi with the D1.

I haven’t compiled a Linux kernel in decades — how do those cluster compile times compare to something like an Intel i7-11k? They sound slow.

A Ryzen 9 7950X compiles 5.18 in less than 40 seconds[0], so yes. 60 minutes per module or 15 minutes with 7 modules is very slow. I think these risc blade architectures are interesting from a home-lab perspective -- low-cost complex-architecture playgrounds.

[0] https://www.phoronix.com/review/amd-ryzen-7900x-7950x-linux/...

Or 400 seconds with a allmodconf build, idk what they build in the OP.

If they build allmodconf and I understood the benchmarks correctly, then one C910 core is about 4 times slower in building the Linux kernel than a single Ryzen 5 5600x core (60/(1491/6*4/60)). That would be pretty good wouldn't it?

Probably to good to be true, but I don't think we can just compare these two numbers directly anyways.

> if ... then one C910 core is about 4 times slower ... than a single Ryzen 5 5600x core

4x is the number I work with to approximate C910 vs current x86.

Which makes 64 core Milk-V Pioneer possibly comparable to a 16 core 7950x, but at $2k ready to use it's a lot cheaper than 7950x boxes I see on Amazon.

If your workload can keep 64 cores busy, of course. Many can't.

I don't really see a point in investing in these devices unless you're particularly interested in porting applications to non-standard RISC-V and being married to the T-Head fork of GCC. Yeah, it's a pretty fast CPU for a new-ish ISA, but there are better options for RISC-V SBCs out there for porting and testing.

> unless you're particularly interested in porting applications to non-standard RISC-V

You can totally use these devices to work on porting applications to standard RISC-V and they are currently the best available for that, if you what to port to rvv. Yes rvv 0.7.1 and rvv 1.0 are a bit different, but having a device with rvv 0.7.1 allows you to actually make performance estimates/tests.

It pretty doable to implement a smaller algorithm with rvv 1.0 intrinsics, use clang to get the assembly, then convert the few instructions that differ between version and use the older gcc toolchain that supports rvv 0.7.1. (no custom thead stuff required)

I would buy one of these devices for my self if I didn't already have ssh access to a milk-v pioneer board (thanks perxlab btw).

Does anyone know if either of the tablets mentioned can play an HD movie acceptably? Say 1-2GB H264 .mkv or .mp4 files?

Looking to retire a decade old android.

I doubt any of the risc-v gear has hw decoding running already

The recent Explaining Computers youtube review of the Lichee Pi 4A showed it playing 720p from youtube very well, but struggling a little on 1080p. The SoC should be easily up to 1080p but perhaps more work is required on the software side -- the non-beta boards have only been shipping for two months.

In general, on the JH7110 and TH1520 boards, right now you get ImgTech's driver and thus hardware decoding if you run the official manufacturer's OS image, but not if you run some generic RISC-V Linux image.

>The recent Explaining Computers youtube review of the Lichee Pi 4A showed it playing 720p from youtube very well, but struggling a little on 1080p.

The same video does, earlier on, demonstrate vlc or mpv playing 1080p w/o issue.

Chromium, specifically, is what has trouble keeping up.

Or the CODEC youtube wanted. I recall comments on the video suggest using a plugin to force youtube to serve H.264/5 make it work better.

Both JH7110 and TH1520 have hardware video codec blocks.

Find the details of what they can handle in the official specs, but note they are much better than the Raspberry Pi 4, which many find sufficient for the task.

Sure... but I'm focusing on hardware I can actually order.

https://aliexpress.com/item/1005005532736080.html

Whoops. I confused thus with the pinetab. Happy to see you can actually order this hardware. I don't have a lot of time for projects at the moment, but the price is pretty reasonable as well. Thx for the link.

That is changing on a monthly basis.

That still seems a little underwhelming like for like, but the progress is certainly swift

It's getting interesting, dollar per dollar.

e.g. the JH7110 and TH1520 devices at around Raspberry Pi 4 price are IMHO a better deal.

Relative to the Pi 4, the CPU can be lower power (JH7110) or faster (TH1520), whereas GPU, video codecs, crypto acceleration, RAM and periphals are better in both.

Reply on news.ycombinator.com