[HN Gopher] Sipeed unveils RISC-V tablet, portable Linux console...
       ___________________________________________________________________
        
       Sipeed unveils RISC-V tablet, portable Linux console, and cluster
        
       Author : shallow-mind
       Score  : 41 points
       Date   : 2023-08-28 17:44 UTC (5 hours ago)
        
 (HTM) web link (www.cnx-software.com)
 (TXT) w3m dump (www.cnx-software.com)
        
       | sylware wrote:
       | 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).
        
         | packetlost wrote:
         | Why is 64-bits a requirement?
        
       | retrocryptid wrote:
       | Sure... but I'm focusing on hardware I can actually order.
        
         | brucehoult wrote:
         | That is changing on a monthly basis.
        
         | RetroTechie wrote:
         | https://aliexpress.com/item/1005005532736080.html
        
       | mixmastamyk wrote:
       | 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.
        
         | Havoc wrote:
         | I doubt any of the risc-v gear has hw decoding running already
        
       | jauntywundrkind wrote:
       | 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.
        
       | packetlost wrote:
       | 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.
        
         | camel-cdr wrote:
         | > 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).
        
       | Havoc wrote:
       | That still seems a little underwhelming like for like, but the
       | progress is certainly swift
        
         | snvzz wrote:
         | It's getting interesting, dollar per dollar.
        
       | snvzz wrote:
       | 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
        
         | FullyFunctional wrote:
         | 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.
        
           | snvzz wrote:
           | >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.
        
         | jauntywundrkind wrote:
         | 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...
        
           | snvzz wrote:
           | >All within basically a year since announcements!
           | 
           | And within half of shipping date (March).
        
       | fweimer wrote:
       | 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.
        
         | snvzz wrote:
         | 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
        
           | brucehoult wrote:
           | 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.
        
       | KerrAvon wrote:
       | 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.
        
         | daveguy wrote:
         | 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/...
        
           | camel-cdr wrote:
           | 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.
        
             | brucehoult wrote:
             | > 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.
        
       ___________________________________________________________________
       (page generated 2023-08-28 23:02 UTC)