Announcement

Collapse
No announcement yet.

StarFive VisionFive 2 Quad-Core RISC-V Performance Benchmarks

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    I have this board too and also observed a couple of things.
    1. These cores are indeed quite slow.
    2. Non optimized instructions makes them extremely slow.

    E.g. I ran stage0-posix-riscv64 (which bootstraps a subset of C compiler from a super tiny binary) and on VisionFive2 board it ran for over 30 minutes. AArch64 version running on rockpro64 takes about 2 minutes and running x86_64 version on 8 year old laptop takes 40 seconds. So it is really fairly slow.
    And running bootstrap process a bit further which uses GNU Mes Scheme interpreter to build Tiny C Compiler (tcc) takes 4 days on a single core as opposed to 30 minutes on an old x86_64 laptop.

    On the other hand, if you use the latest GCC and all 4 cores, then it's slow but not extremely slow, e.g. I can build binutils in about 30 minutes on Gentoo running on VisionFive2.

    Comment


    • #32
      Originally posted by Paradigm Shifter View Post
      I bought one of these a while ago basically to tinker around with as it's not x86 or ARM. At the time was a bit of a wossname to get working
      I don't know why.

      When mine arrived in early February I downloaded the "Image 55" os snapshot from the manufacturer's site, copied it to a µSD card, inserted it in the board, attached a full HD monitor and kb and mouse and ethernet and a Pi 4 power supply and it booted right up into the login screen. I didn't touch any switches, I didn't update the on-board boot flash. It simply worked.

      Sure, if you want to stay on the bleeding edge of driver and kernel development then -- like any SBC -- there is more fiddling. But not to simply make it work out of the box.

      Comment


      • #33
        Originally posted by bloominstrong View Post

        I have a couple of these boards I did use one as a firewall for testing, from memory I was getting ~600Mb/s max throughput and down to ~350Mb/s once I added in all the NAT firewall rules. I have been waiting for OpenWRT support to be a little more stable before giving that a try.
        Thanks for giving the numbers, originally I bought two with the hope to play around with before using them as a firewall or for other networking, but I never got around to setting them up and it looks like with the current state of optimization they won't make the cut for my network. I was hoping to not use a repurposed gaming machine as my firewall, but doing so did work out as I was recently able to add in a 2.5GbE NIC and I still have lanes left over for a 10GbE NIC and/or HBA card with plenty of horsepower for 10Gbps NAS activities.

        I'll find some use out of these, and if not at least backing the Kickstarter proved to be worthwhile and helpful for RISC-V as StarFive has been making lots of contributions to the Linux RISC-V ecosystem. Things have to start somewhere, and the future is looking bright.

        Comment


        • #34
          Originally posted by stikonas View Post
          I have this board too and also observed a couple of things.
          1. These cores are indeed quite slow.
          2. Non optimized instructions makes them extremely slow.

          E.g. I ran stage0-posix-riscv64 (which bootstraps a subset of C compiler from a super tiny binary) and on VisionFive2 board it ran for over 30 minutes. AArch64 version running on rockpro64 takes about 2 minutes and running x86_64 version on 8 year old laptop takes 40 seconds. So it is really fairly slow.
          Well of course, you expect that from the specification.

          The far more interesting question is how does it compare to a Rock64 or Pi 3?

          Comment


          • #35
            I own one of these VF2 boards.

            I limited it to the reference Debian-based image
            That ships a very old gcc (produces very slow code vs that in Arch Linux RISC-V port, which is what I use), and very old everything else. It's an over a year old snapshot of Debian port.

            It likely seems like nothing to most, but remember this is RISC-V: Progress is concentrated into recent months.

            In fact, VisionFive 2 accelerated this progress significantly, it being the very first mass-produced low-cost RISC-V SBC. The image reflects none of this.

            For several (!) managed programming languages, that image uses an interpreter, whereas current versions use a JIT.

            For those that already had a JIT, the JIT got dramatically better.

            Kernel-side, it's a patched Linux 5.10, and the patches aren't updated with the ones that have been upstreamed in Linux.

            In short, all of that is why the results are way lower than they should be. It's a night and day difference.

            edit:

            As an added note, the gcc parameters used do not target VisionFive2's CPU (SiFive U74 21G1), but a generic RV64GC (RISC-V as of first ratified unprivileged spec, from 2019).

            The SiFive U74 21G1 implements extensions that are considerably newer than that. Notably, the Zba/Zbb groups of bit manipulation extension, which were ratified in December 2021. These affect performance significantly.

            Also, having a heatsink would have significantly affected results, as while the SoC is quite efficient, it will throttle when handling a load for an extended amount of time.

            Other boards (such as the rpi4) might have been benchmarked with a heatsink.

            A 100% passive solution such as the Odroid XU4Q heatsink can keep VisionFive2's temperatures below 60C even during hours compiling software.
            Last edited by ayumu; 16 August 2023, 10:41 PM.

            Comment


            • #36
              Originally posted by RejectModernity View Post

              What? VF2 has nvme 2240 slot.
              It is 2280. I have a 2280 card on mine, and this size is what fits the location of the holding screw.

              Comment


              • #37
                Originally posted by bloominstrong View Post

                I have a couple of these boards I did use one as a firewall for testing, from memory I was getting ~600Mb/s max throughput and down to ~350Mb/s once I added in all the NAT firewall rules. I have been waiting for OpenWRT support to be a little more stable before giving that a try.
                Benchmarking the official VF2 image is useless.

                RISC-V eBPF support is critical to routing and firewall performance, and was added very recently to the Linux kernel.

                The software ecosystem around RISC-V is advancing at such a rate.
                Last edited by ayumu; 16 August 2023, 10:42 PM. Reason: eBPF

                Comment


                • #38
                  Originally posted by brucehoult View Post
                  Agreed. I've been using Linux for 30 years. Anyone who thinks six months or two years difference between kernel versions is significant is showing how n00b they are.
                  Your understanding is incorrect and probably inherited from x86 where all optimised instructions are baked in from the get go.

                  We're not talking about the portable parts of the kernel here, that would be a n00b thing to think.

                  Comment


                  • #39
                    So any really existing RISC-V hardware is still laughably non-competitive.

                    Comment


                    • #40
                      Originally posted by ayumu View Post

                      Benchmarking the official VF2 image is useless.

                      RISC-V eBPF support is critical to routing and firewall performance, and was added very recently to the Linux kernel.

                      The software ecosystem around RISC-V is advancing at such a rate.
                      Ohhhh yes sorry should have mentioned this was with the Arch Linux build, which still has the same kernel as the "official" Debian image.

                      This was maxing out a single core but I'm not across eBPF to know if there is anything to upstream to make it multi threaded.

                      I am waiting for a new release with mainline kernel as I'm struggling to get u-boot to boot my kernel build.

                      Comment

                      Working...
                      X