Announcement

Collapse
No announcement yet.

AMD 4th Gen EPYC 9654 "Genoa" AVX-512 Performance Analysis

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

  • #11
    Originally posted by stormcrow View Post
    There's nothing stopping RISC oriented designs from doing the same thing - and have been for decades now. The RISC v. CISC debate is obsolete at this point.
    There is. Operator space in a RISC instruction is limited in size. Hence Reduced Instruction Set Computer.
    The RISC vs. CISC debate has been dead internally yes. The external interface still has the same legacy issues.

    In reality though, modern RISC machines have a pretty big opspace to begin with so not really an issue.
    And sure, you can do variable length instructions in RISC too (like RVV in RISC-V), but I dunno if I'd say it's still technically a RISC machine anymore?
    RVV is like some strange variable length vector instructions. They forgo all the good stuff about RISC stuff to implement shortcuts.
    Any problems in RVV instruction handling is going to be a nightmare.

    Comment


    • #12
      I am going to stay neutral towards Linus's avx-512 opinions. But I also believe avx-512 should die a horrible death (together with avx and avx2). When avx-512 is proven too narrow (this is going to happen sooner, rather than later) are they going to invent avx-1024 and a few years later avx-2048? Arm sve and riscv v extension (albeit neither is perfect) are way cleaner.

      Comment


      • #13
        Originally posted by milkylainen View Post

        There is. Operator space in a RISC instruction is limited in size. Hence Reduced Instruction Set Computer.
        The RISC vs. CISC debate has been dead internally yes. The external interface still has the same legacy issues.

        In reality though, modern RISC machines have a pretty big opspace to begin with so not really an issue.
        And sure, you can do variable length instructions in RISC too (like RVV in RISC-V), but I dunno if I'd say it's still technically a RISC machine anymore?
        RVV is like some strange variable length vector instructions. They forgo all the good stuff about RISC stuff to implement shortcuts.
        Any problems in RVV instruction handling is going to be a nightmare.
        Although riscv is kind of cisc (for example c extension), the v extension does not use variable length instructions (unless things changed with a newer version). It uses variable length vectors but the vector instructions are 32 bit long.

        Comment


        • #14
          I'm happy AMD is finally implementing it.

          AVX512 might not be useful in most cases, but it gives a considerable performance boost for complex video console emulators (PS3, X360, Switch and 3DS ones)

          Comment


          • #15
            Originally posted by xfcemint View Post
            I couldn't quite figure it out: would AVX512 be available only on EPYC?
            Or, on high-end R9?
            Or even, on lower-end R3, R5?
            But, i7.
            All AM5 CPUs have AVX512 and lower (AVX2, AVX).

            All good? Shop away! Get and R3 or R5 and start using x265 with AVX512 on Handbrake (you may need to force it though as an option); or start playing Nintendo Switch games and Ps3 games using emulators!

            Merry Christmas!

            Comment


            • #16
              Wasn't SIMD invented back before multiple cores was much of a thing yet? So couldn't you say it's a hack that was devised to address a lack of something that's ever more progressively not lacking at this point? Now that we're at the point of packing lots of cores onto CPUs while also making massively capable compute accelerator chips, wouldn't it make the most sense to eliminate SIMD entirely from CPUs and just pack on as many slimmed-down cores as possible?

              That said I make use of SIMD in my program because it's there and it's easy to write standard C++ code for. From a hardware design standpoint it just doesn't seem like SIMD on CPU makes sense any more, if ever it really did?

              Comment


              • #17
                I expect there exists a mix of AVX-512 and non-AVX code where you could actually see a performance regression from enabling it on Genoa. That's because clearly some clock-throttling is occurring. The key question is: how big is that "window"?

                The benchmarks in this article were mostly/all AVX-512 heavy. It'd be interesting to see some more mixed workloads, like what they used in this scenario:


                However, I don't think that same test will work, because I believe AMD accelerates crypto by a different means?

                Comment


                • #18
                  Originally posted by xfcemint View Post
                  Heat can be largely controlled by shutting down power to large parts of the die. Therefore, the CPU design is the last limit.
                  To nit-pick, I'll argue that shutting off power is for power saving, not heat control. Heat is controlled primarily through external cooling and clock gating ... but also via down-clocking when the cooling has been poorly built. With boost-clocking being a good example of normalised down-clocking in reverse.

                  Comment


                  • #19
                    That's not for controlling heat though.

                    Comment


                    • #20
                      Stopping the clock is far more effective and far more responsive too. That's called clock gating. Going further than that is done for power saving reasons.

                      Comment

                      Working...
                      X