Announcement

Collapse
No announcement yet.

x86-64-v5? Questions Arise Over The Future Of x86-64 Micro-Architecture Feature Levels

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

  • #21
    Originally posted by TemplarGR View Post
    This is such a non-issue.... Just make AVX10 mandatory for v5, anything that lacks it, remains v4. Even if it is released in the future. Feature levels for a compiler are not just release-date based....
    Quality comment from you as always.

    Next time try to understand the article first, assuming you even read it in the first place.

    Comment


    • #22
      Originally posted by ehansin View Post
      I am a bit of a novice when it comes to CPU instruction set extensions. I am not clueless, but not exactly super knowledgeable. If anyone can clue me in on these parts, did some brief Wikipedia reading on AVX-512 and AVX10:

      Sounds like AVX-512 requires 512 bit wide vector registers (if that is the correct term) and AVX10 can use 256 or 512 bit wide registers. Given, at least as I am understanding it, that AVX10 encompasses/supports (all?) AVX-512 instructions, does that mean a 256 bit wide AVX10 implementation supports some AVX-512 instructions by just using two registers? Just don't know enough here.

      And if that is the case, curious where the main problems lies with compilers? I'm not arguing there are no problems, just don't know where the technical block is and am curious. Thanks as always.
      No, some cores (Intel E-cores) don't support 512-bit ops at all. AVX512 can also use 256-bit or 128-bit ops. Same with AVX10.

      For feature levels, what are you going to settle for? 256-bit? If you settle for 512-bit, it won't be useable on every core. I believe the kernel should then reschedule that thread to a different core that does support it, albeit at a performance penalty (instead of crashing), but when your entire system has this, that makes your E-cores pretty useless doesn't it.

      Comment


      • #23
        Originally posted by ehansin View Post
        geerge Okay, thanks for the synopsis! I do get that creating different targets creates a mess. I'll be watching this some, know there will be more to come
        While he is correct, he didn't make it very clear what the problem is in regards the discussion of the compiler. When compilers compile code, they try to optimize for speed. The AVX10 will now have a few different sets of features that each affect timing instructions.

        You might think going faster is always good, but that isn't the the compilers optimize. They try to optimize by utilyzing the hardware maximally to achieve that speed. If your CPU advertises AVX10, however, the compiler doesn't know which would be faster, the 256bit path or the 512bit path, because it can't know which CPU it will execute on.

        On top of that, when we are talking feature levels, we are talking a set of features the compiler targets. What this means practically is, AVX10 will most likely be optimized for 256bit instructions, and the 512bit hardware will just be sitting idle.

        It also mean the programmer will need to do more work if they want to use that 512bit path, by testing both the 256bit and the 512bit path.

        Comment


        • #24
          moores law is mostly dead, only the ever increasing x86 isa complexities try to adhere to it.

          Comment


          • #25
            Originally posted by garloff View Post
            For sanity, v2 is a superset of the baseline (cx16, popcnt, lahf, sss3, sse4.1, sse4.2 added), v3 a superset of v2 (with avx, avx2, bmi1, bmi2, f16c, fma, abm, movbe, xsave added) , v4 a superset of v3 ( with avx512f, avx512bw/, avx512cd, avx512dq, avx512vl added)

            With AVX512 not being guaranteed with AVX10, I can't see AVX10 getting a v5 or v6. It may be a v3.1, v3.2 or so.

            Or intel becomes sane and always includes the avx512 insns needed for -v4, though not necessarily with the full performance (like zen4 does very successfully).
            It is better to call AVX10 256-bit as AVX3.
            Good plan for AVX10 256-bit: ditch and forget.
            Intel creates headaches with AVX10 256-bit because it cannot cope with realizing AVX-512 in its little Atom-based "E-cores".
            And what if in the next years Intel will start mass production at 18A (1.8 nm) technology node and claim "OK, guys, we don't need AVX10 256-bit anymore, because now we can include AVX-512 in E-cores"?
            ​​
            Probably lawben​ from discussion is not qualified enough, because he wrote
            However, -v4 is a bit “behind” now, as it was introduced to cover the AVX512 set of Skylake CPUs
            But Skylake​ don't support AVX-512, it is Skylake-X architecture (Skylake-X, Skylake-SP, Skylake-W) which support AVX-512.

            It is discussible whether to call x86-64-v4 + some AVX-512 instructions based on Ice Lake (2019) or Zen 4 (2022) architectures as x86-64-v5 or x86-64-v4.1 or x86-64-v4E.​
            I encourage devs to use Ice Lake or Zen 4 AVX-512 instruction set instead of x86-64-v4.
            Last edited by Svyatko; 07 April 2024, 03:45 PM.

            Comment


            • #26
              Originally posted by TemplarGR View Post
              This is such a non-issue.... Just make AVX10 mandatory for v5, anything that lacks it, remains v4. Even if it is released in the future. Feature levels for a compiler are not just release-date based....
              I think you missed the part where v4 requires AVX512, but future intel processors may contain AVX10 but not AVX512. What version would you call that?

              Comment


              • #27
                Originally posted by garloff View Post
                .

                Or intel becomes sane and always includes the avx512 insns needed for -v4, though not necessarily with the full performance (like zen4 does very successfully).
                Or intel can die, so better companies (AMD, ARM) and architectures (ARM, RISC-V, POWER) can flourish.

                A man can dream.

                Comment


                • #28
                  Originally posted by SofS View Post
                  Well, they were thinking about x86S as well,
                  Really? I thought x86S didn't affect much outside BIOS & the kernel. Are you sure they weren't talking about APX?

                  Originally posted by dragorth View Post
                  If we are only talking about Intel, x86s should be the start of a new Arch.
                  I'm pretty sure you're thinking of APX, here.

                  Comment


                  • #29
                    Originally posted by skeevy420 View Post

                    Michael
                    It's moot point.
                    I think the whole thing is moot point.

                    I've just checked (on youtube) gaming performance of 11 year old i7-4770K vs brand new i9-14900K. New is around 2-4x faster, despite being 11 years newer, having 20 cores more, much faster memory and WAY higher TDP. And people are scratching their heads how to name new flashy extensions that usually give performance benefits within of a margin of error.

                    This is how progress looks like nowadays. Any decent AVX2 cpu will be probably perfectly usable in 2030.
                    (unless they kill them off due to lack of extensions, that is)

                    11 years is the difference between 486DX2 and Athlon64. 486 with 8MB RAM would not be able to even boot operating system that A64 used lol.




                    Last edited by sobrus; 07 April 2024, 04:02 PM.

                    Comment


                    • #30
                      AVX10 CPUs with no AVX-512 should just be treated as x86-64-v3 IMHO.
                      maybe long term x86-64 should implement instructions to support variable vector length like RISC-V does.

                      Comment

                      Working...
                      X