Announcement

Collapse
No announcement yet.

LLVM Compiler Finally Gets A Tuned Scheduler Model For Intel Alder Lake P

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

  • LLVM Compiler Finally Gets A Tuned Scheduler Model For Intel Alder Lake P

    Phoronix: LLVM Compiler Finally Gets A Tuned Scheduler Model For Intel Alder Lake P

    While Intel is normally fast at contributing improvements for new hardware to the open-source GCC and LLVM/Clang compilers, just today and ahead of the approaching Raptor Lake launch has a proper scheduler model finally been added for existing Alder Lake P processors...

    https://www.phoronix.com/news/LLVM-I...-P-Sched-Model

  • #2
    It's too bad that Alder Lake P doesn't support AVX-512 officially. The compiler tuning does not take that into account, at least for that target. Maybe the Sapphire Rapids target will be compatible. Another method would be to add all of the available AVX-512 subfeatures to the command line, but that is very inconvenient.

    Comment


    • #3
      Originally posted by ms178 View Post
      It's too bad that Alder Lake P doesn't support AVX-512 officially. The compiler tuning does not take that into account, at least for that target. Maybe the Sapphire Rapids target will be compatible. Another method would be to add all of the available AVX-512 subfeatures to the command line, but that is very inconvenient.
      AFAIK, newer Alder Lake revisions have the AVX-512 part of the chip actually fused off, meaning there is no way to activate these instructions afterwards.

      Personally, missing AVX-512 on Alder Lake played a role on why I went with a Rocket Lake.
      And since AMD plans to introduce official support for it on Zen 4 (albeit only as 2 × 256-bits), that would mean they will actually have a x86 instruction advantage for the first time since the release of AMD64.

      If Intel continues to ignore AVX-512 in the consumer market, then AMD CPUs are the only sensible way forward...

      Comment


      • #4
        Originally posted by ms178 View Post
        IThe compiler tuning does not take that into account, at least for that target. Maybe the Sapphire Rapids target will be compatible. Another method would be to add all of the available AVX-512 subfeatures to the command line, but that is very inconvenient.
        Huh? Just enabling the instructions won't get you the proper cost model for them. However, if Intel is doing this now, it's hard to imagine they're not working towards a full cost model for Sapphire Rapids.

        This news raises some key questions for me:
        1. What about Ice Lake & Tiger Lake (not to mention Rocket Lake, for our friends like Linuxxx )? Will Intel update it for them, or are they left out in the cold?
        2. What about the efficiency cores, up to & including Gracemont?

        Comment


        • #5
          Originally posted by Linuxxx View Post

          If Intel continues to ignore AVX-512 in the consumer market, then AMD CPUs are the only sensible way forward...
          That makes a potential CPU pick the upcoming generation so hard, at least without hard numbers. Intel shot themselves in the foot with limiting that feature to their workstation and server parts as they could have had a clear winner in their camp. The 6P+8E Core i5s appear to be tempting price/performance wise if you need good single- and multi-thread performance but no AVX512 limits their long term value for me due to missing out the x86-64 v4 feature level and are also on a dead platform and probably less efficient. AMD has not really an incentive to be aggressive on pricing in the low- and mid-tier consumer space as long as their chips are highly sought-after in the server segment, so uncompetetive pricing in that segment doesn't hurt their bottomn line.
          Last edited by ms178; 19 August 2022, 04:27 PM.

          Comment


          • #6
            Originally posted by coder View Post
            Huh? Just enabling the instructions won't get you the proper cost model for them. However, if Intel is doing this now, it's hard to imagine they're not working towards a full cost model for Sapphire Rapids.
            Right, but you also won't get the instructions enabled by chosing march=native or alderlakep either in addition to no proper cost model for that configuration. From a potential AVX-512 modder-perspective, that is both rather unfortunate. I thought of this entry while reading this.

            Originally posted by coder View Post
            This news raises some key questions for me:
            1. What about Ice Lake & Tiger Lake (not to mention Rocket Lake, for our friends like Linuxxx )? Will Intel update it for them, or are they left out in the cold?
            2. What about the efficiency cores, up to & including Gracemont?
            I saw some Gracemont tuning in LLVM some weeks ago, at least they are aware that it needed a little more attention due to their E-core use.
            Last edited by ms178; 18 August 2022, 04:43 PM.

            Comment


            • #7
              Originally posted by ms178 View Post
              AMD has not really an incentive to be aggressive on pricing in the low- and mid-tier consumer space as long as their chips are highly sought-after in the server segment, so uncompetetive pricing in that segment doesn't hurt their bottomn line.
              It's a supply/demand thing. If AMD can get enough supply for all the markets they're playing in, then you'll see competitive pricing in all markets. Otherwise, they will indeed prioritize some over others, largely based on margin (but also mindshare).

              Comment


              • #8
                Originally posted by ms178 View Post
                at least they are aware that it needed a little more attention due to their E-core use.
                The main place it should be used is on E-core -only CPUs.

                This raises an interesting question for hybrid CPUs: which image to use? It'd be interesting if there were some way to compile multiple versions of the same code, tuned for multiple different CPU architectures. It's a lot more complex than simply using glibc's HWCAPS, because you'd need to have a very deep level of binary compatibility between the two images, if you want to be able to dynamically switch between them mid-runtime.

                I think the way I'd approach it is to have specific transition points, where a program could switch to a different image that's tuned for the core currently executing it. You'd still need binary compatibility between them (i.e. can't use any instructions not present on both cores), because you couldn't constrain preemption to happen only at those transition points.

                Comment


                • #9
                  coder IMO for program that needs to squeeze out every last bit from the CPU, they can pin each thread to specific CPU core.

                  Then each thread can execute code optimized for that core.

                  Comment


                  • #10
                    Originally posted by NobodyXu View Post
                    coder IMO for program that needs to squeeze out every last bit from the CPU, they can pin each thread to specific CPU core.

                    Then each thread can execute code optimized for that core.
                    That's far from ideal. Especially when we're talking about libraries.

                    However, I also have a problem with applications deciding where they should run. I want the kernel to decide what runs where, based on the state or configuration of the machine. And it should be able to migrate things, as circumstances change.

                    This is what we have today (by default), and I think it'd be nice to retain this behavior while also running code that's optimized for the particular class of core.

                    Comment

                    Working...
                    X