Announcement

Collapse
No announcement yet.

Google Posts Patches So The Linux Kernel Can Be LTO-Optimized By Clang

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

  • #31
    Originally posted by JustinTurdeau View Post
    I have no idea what you're talking about.
    Processing of radar data. So basically : connect all the radar sensors, do the processing. As it would be done in production. If sensors would be missing, there might be important code paths 'untouched' (as in not executed) (that is what I was talking about).

    Obviously you need to profile what you want to optimize for. That's a no brainer
    Last edited by oleid; 26 June 2020, 03:09 AM.

    Comment


    • #32
      Originally posted by oleid View Post
      Processing of radar data. So basically : connect all the radar sensors, do the processing. As it would be done in production.
      This is the first time you've mentioned "radar" in this thread.

      Comment


      • #33
        Originally posted by JustinTurdeau View Post

        This is the first time you've mentioned "radar" in this thread.
        The actual application is not really important. Just another processing pipeline with streaming input. Not too far off from a video encoder.

        Comment


        • #34
          Originally posted by oleid View Post
          The actual application is not really important. Just another processing pipeline with streaming input. Not too far off from a video encoder.
          Well you should know better than anyone else if PGO is applicable or not. I said PGO was a toy for "most applications", not "all applications". The reason I said this is because I see a lot of people droning on about it when they clearly have no intention of doing the work required for it to be a worthwhile improvement.

          I've seen loads of people on these forums saying "do some PGO benchmarks", but doing that properly is way more work than Michael typically puts into his benchmarks.
          Last edited by JustinTurdeau; 26 June 2020, 05:52 AM.

          Comment


          • #35
            Originally posted by JustinTurdeau View Post
            I've seen loads of people on these forums saying "do some PGO benchmarks", but doing that properly is way more work than Michael typically puts into his benchmarks.
            Indeed. While those benchmarks are highly repeatable and I'd expect the profile gathered would probably optimize that particular benchmark nicely, I don't think we could draw any conclusions except that PGO would yield an improvement for exactly that benchmark with the given parameters.

            Comment


            • #36
              Originally posted by Hans Bull View Post

              Reducing kernel obesity would be more than welcome.
              Difficult with homeoffice ...the fridge too close to the workplace. No walks outside. soon it will have 5.9 just rising ...

              Comment


              • #37
                Originally posted by JustinTurdeau View Post

                Well you should know better than anyone else if PGO is applicable or not. I said PGO was a toy for "most applications", not "all applications". The reason I said this is because I see a lot of people droning on about it when they clearly have no intention of doing the work required for it to be a worthwhile improvement.

                I've seen loads of people on these forums saying "do some PGO benchmarks", but doing that properly is way more work than Michael typically puts into his benchmarks.
                absolutely true. I think the most people demanding it - have never done it. Applied it multiple times but it is way more than just compiling it twice.

                Comment


                • #38
                  Originally posted by Grinch View Post
                  This statement makes no sense, having a code path being executed is how you get profile data. Representative profile data is something you get when running the application per your typical workload.

                  The alternative to this is guesswork from the compiler, which is what you get without PGO, unless you use a lot of compiler extensions which allow you to give 'hints' to said compiler. Linux does this to a large extent, but the vast majority of software, including very performance critical, does not.

                  A real world example, for Blender CPU rendering I've gotten up to 22% performance increase by recompiling with PGO, that is a massive performance boost.
                  true but he exactly meant this. Typical workload - it means that you will not just have to start and quit it immediatly. And sometimes this profiling mode is really slowing down everything. Real productive work at this moment is not always possible.

                  Comment


                  • #39
                    LTO PGO stuff is just for lazy developers. The most effective improvement for perf is: don't load the code that I will not use.
                    Today's software are bloated so much, I have no idea why so big chunk of code is needed to let me read the text on my screen.
                    Browser is the most bloated software ever. Linux kernel is much less bloated (or not bloated at all).
                    If a browser still has a text-only mode I'd be very happy to use it.
                    Go hxxx java and javascript.

                    Comment


                    • #40
                      Originally posted by goTouch View Post
                      Today's software are bloated so much, I have no idea why so big chunk of code is needed to let me read the text on my screen.
                      Yeah, a lot of "modern" software is bloated. What a highly insightful and non-obvious comment.

                      Originally posted by goTouch View Post
                      LTO PGO stuff is just for lazy developers
                      You clearly have no idea what you're talking about. Opinion disregarded.

                      Comment

                      Working...
                      X