Announcement

Collapse
No announcement yet.

SiFive HiFive Unmatched Hands-On, Initial RISC-V Performance Benchmarks

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

  • #51
    Originally posted by PerformanceExpert View Post

    The U74 performs worse than the PI 3B, which uses a 1.2GHz Cortex-A53. SiFive likes to claim that U74 is equivalent to a Cortex-A55, but it clearly falls far short of that, despite having a lot more cache and modern DRAM. Also note many (perhaps most) of the boards you listed use a 32-bit OS and software. Using 64-bit AArch64 gives a significant speedup.

    So all in all, it's not a good showing, and the absence of any OoO RISC-V cores (in actual silicon rather than announced) is telling.
    It doesn't say much about RISC-V itself, just about the amount of investment in high-end implementations so far. RISC-V as an architecture is exceedingly boring and any microarchitect will tell you it can be made to go as fast as cutting-edge Armv8-A designs with enough engineering investment. But that's a huge undertaking that requires time, effort and money, and many of the parties who have the resources to do that aren't using RISC-V because they're already using a different ISA (Intel and AMD with x86, IBM with POWER and z/Architecture, pretty much everyone else on Arm) with no good reason to upend everything and move to a different ISA, with all the disruption caused by software migrations, and the financial hit of having to reimplement a new processor from the ground up rather than evolving their existing designs (some things from an Armv8-A implementation could be carried over, but a lot wouldn't). So all this tells you is that this is a low-end implementation of the architecture that's perhaps been a bit over-promised by the marketing around it.

    Comment


    • #52
      Originally posted by PerformanceExpert View Post
      The U74 performs worse than the PI 3B, which uses a 1.2GHz Cortex-A53.
      They appear to perform quite comparably. If your conclusion is based on the graphs I assembled: Those results are for Ubuntu 21.04, but Michael's article shows that Ubuntu 21.10 brings about 10-20% more performance.

      Where the U74 naturally will fall short is performance where the ARM contenders run NEON code.

      Comment


      • #53
        Originally posted by SavageX View Post

        They appear to perform quite comparably. If your conclusion is based on the graphs I assembled: Those results are for Ubuntu 21.04, but Michael's article shows that Ubuntu 21.10 brings about 10-20% more performance.
        It's poor performance given the amount of L2 cache and higher DRAM bandwidth. Remember the claim was that U74 performs like Cortex-A55 and so should beat ancient Cortex-A53 SoCs, but it doesn't even with 8 times the L2 cache. Yes, the Ubuntu 21.10 results are 10-20% better, but AArch64 is also 10-20% faster than 32-bit Arm. The Pine64, Firefly and Le Potato are AArch64 and beat PI by a good margin. All the Arm boards are using ancient compilers and distros. It would be great to see a more apples-to-apples comparison of native 64-bit performance using the same compiler and distro.

        Where the U74 naturally will fall short is performance where the ARM contenders run NEON code.
        Indeed. I don't think it matters for most Phoronix tests, but it's another reason why you couldn't call it equivalent to Cortex-A55...

        Comment


        • #54
          Originally posted by stalkerg View Post

          it's not working like this, Open Source in 90% time working differently. After finishing your work and after merging all patches I believe you can expect to talk about work in AMD and a good chance.

          PS I also saw a few good positions in Tokyo that are bound with OpenSource drivers but for business customers. Probably I should try...
          Ah, an earning a living with OpenSource expert. First of all 90% of the time people, users and companies do not like to pay for OpenSource at all. Second of all: have you ever tried to get paid after the fact? Especially if it was not contacted / agreed upon before? Third? Who to even talk after work is done? Their regular open source developer employees? It is not like companies have a OpenSource work bounty program like some do for security issues. All in all the state of compensating and earning a living with OpenSource is abysmal.

          Comment


          • #55
            Originally posted by rene View Post

            Ah, an earning a living with OpenSource expert. First of all 90% of the time people, users and companies do not like to pay for OpenSource at all. Second of all: have you ever tried to get paid after the fact? Especially if it was not contacted / agreed upon before? Third? Who to even talk after work is done? Their regular open source developer employees? It is not like companies have a OpenSource work bounty program like some do for security issues. All in all the state of compensating and earning a living with OpenSource is abysmal.
            Originally, the open source is altruism. You can't expect any money until you will working in the company or you have no contract. I like working in open source because I can share work and not because I am getting money. I have already worked in the company and 100% time spent to open source project as my first time job and it's was not really fun.

            Comment


            • #56
              Originally posted by stalkerg View Post

              Originally, the open source is altruism. You can't expect any money until you will working in the company or you have no contract. I like working in open source because I can share work and not because I am getting money. I have already worked in the company and 100% time spent to open source project as my first time job and it's was not really fun.
              There are more options in life than just working for one company job. This is not what OpenSource was about.

              Comment


              • #57
                Originally posted by SavageX View Post
                They appear to perform quite comparably. If your conclusion is based on the graphs I assembled: Those results are for Ubuntu 21.04, but Michael's article shows that Ubuntu 21.10 brings about 10-20% more performance.
                The difference is almost entirely due to Ubuntu 21.04 coming with uboot set to clock the cores at 1.0 GHz. 21.10 changes this to 1.2 GHz.

                Most of us who are actually using these boards are running them at 1.4 or 1.5 GHz and SiFive have recently said that every board they have tested runs fine at 1.4 GHz so that will now be the default and supported speed.

                Even 1.4 GHz vs 1.0 GHz significantly changes the comparison to the Pi 3.

                Where the U74 naturally will fall short is performance where the ARM contenders run NEON code.
                Indeed. In a year or so we'll start to see RISC-V machines with the Vector extension, which will remedy that.

                There's already the Allwinner D1 which implements an out of date version (draft 0.7.1) of the RISC-V Vector extension with short 128 bit vector registers, and that shows very nice speed-ups over scalar code.

                Comment


                • #58
                  Originally posted by brucehoult View Post

                  The difference is almost entirely due to Ubuntu 21.04 coming with uboot set to clock the cores at 1.0 GHz. 21.10 changes this to 1.2 GHz.

                  Most of us who are actually using these boards are running them at 1.4 or 1.5 GHz and SiFive have recently said that every board they have tested runs fine at 1.4 GHz so that will now be the default and supported speed.
                  I wonder if https://forums.sifive.com/t/intermit...eavy-load/5009 is an example of someone having bad luck in the silicon lottery. With a platform that early this could be glitchy hard- or software or a combination of both ;-)

                  SiFive apparently not doing per-chip speed-binning also demonstrates that the SoC is not a "product" yet in the traditional sense.


                  Originally posted by brucehoult View Post
                  Even 1.4 GHz vs 1.0 GHz significantly changes the comparison to the Pi 3.
                  Well, winning with a clock speed advantage is not as impressive, of course - and as has been pointed out, because I indeed forgot the Raspberry Pi OS is still 32 bit, I guess the Raspberry Pi 3 might gain some speed in 64 bit mode. Then again, I don't know what the current state of compilers for RISC-V is regarding performance optimizations - last time I checked (which has been a while), GCC for instance did not generate code with the C-extension in mind, meaning that code compression would only be done by the assembler if instructions by chance happen to be compressible. I'm also seeing posts in the SiFive forum indicating that compiler flags can have considerable impact on benchmarks.

                  I also don't know what version of the U74 core is on the HiFive Unmatched. As far as I can tell SiFive releases regular updates on the core IP. If this also touches things like branch-prediction, TLBs and/or stuff in the memory subsystem, the very same base design might show performance differences depending on IP version.

                  Comment


                  • #59
                    Originally posted by SavageX View Post
                    SiFive apparently not doing per-chip speed-binning also demonstrates that the SoC is not a "product" yet in the traditional sense.
                    There is NO ONE who claims the FU740 or HiFive Unmatched is a "product". It's a low volume test / demo / prototyping SoC and board.

                    SiFIve's customers make products. SiFive (like ARM) does not.

                    Comment


                    • #60
                      Originally posted by SavageX View Post
                      Well, winning with a clock speed advantage is not as impressive, of course.
                      There are legitimately different ways to design CPU cores, often colloquially known as "speed demon" vs "brainiac". You can have very little processing (gate delays) in each pipe stage and more pipe stages and a high clock rate, or you can have more processing in each pipe stage, fewer stages, and a lower clock rate.

                      Remember Alpha 20164 vs Pentium Pro? Remember Pentium 4 vs Athlon and PPC G4?

                      Clock speed in itself means nothing. Look instead at the silicon process used and the area used and the energy consumption.

                      Comment

                      Working...
                      X