Announcement

Collapse
No announcement yet.

Ubuntu 18.10 Performance Is Looking Up, But Clear Linux Still Leads In Many Tests

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

  • #11
    Originally posted by vegabook View Post

    Aggressive use of AVX?
    Yeah, it definitely looks like AVX (or lack of it). For Intel, speedup on Clear Linux is close to 6x, on AMD - slightly above 3x. AFAIK, Intel CPU's have more AVX processing power. It all makes sense then.

    Comment


    • #12
      Yeah I think the x265 tests need to be retested again and by different people documenting how they tested, to see that the tests in this article weren't buggered.

      Comment


      • #13
        Originally posted by darkbasic View Post
        How is the x265/lame thing even possible? Especially x265 which is supposed to use mostly hand-tuned assembly.
        If it is testing the native x265 libraries, they can be completely different versions, or they could have different encoding defaults.

        Comment


        • #14
          Originally posted by vegabook View Post
          Oh brother, 18.10 looks terrible for data science. What's the deal on the R and scikit-learn benches??

          These two order-of-magnitude regressions smack any small percentage improvements elsewhere into oblivion.

          There has to be some BLAS library shenanigans going on.
          yes, there must be something really strange happening with blas. Maybe openblas is used for ubuntu 18.04 and default fallback blas without avx/sse is used for 18.10.

          However, these data science benchmarks are not really that meaningfull since you are just measuring blas, which can be changed easily by installing openblas or atlas and changing the dynamically linked blas.so with update-alternatives. Moreover, you can install the intel mkl really easy see Dirk Eddelbuettels tutorial https://github.com/eddelbuettel/mkl4deb

          For example my [email protected] Ghz at work with ubuntu 18.04 and intel mkl gets 0.2388 in the R Benchmark and is thereby 27% faster than the i7 8086K using default ubuntu 18.04.

          Comment


          • #15
            Originally posted by darkbasic View Post
            How is the x265/lame thing even possible? Especially x265 which is supposed to use mostly hand-tuned assembly.
            I call shenanigans on both the x265 and LAME tests, Michael clearly must have botched the C/CXX flags for the Ubuntu tests. This is the reason why I find the Go tests to be the ones I can trust, since they use the same compiler with the same optimizations enabled across all systems, thus the result is actually that of 'system performance', not the (seemingly haphazard) C/CXXFLAGS Michael is passing to GCC / Clang when building the binaries to benchmark.

            Like someone else stated, the x265 results for Ubuntu looked like assembly optimizations had been turned off, we're talking ~80% performance difference here, something is REALLY wrong with the way the Ubuntu builds were configured.
            Last edited by Grinch; 27 September 2018, 04:35 AM.

            Comment


            • #16
              Originally posted by Spooktra View Post
              First of all, thanks for the x265 benchmarks, those are the most interesting encoding benchmarks to me at this point in time and second of all, what the hell is up with the x265 benchmarks? It's almost as if the x265 version tested on Ubuntu was built with a no-asm switch. A 6x faster encoding speed on one OS vs another should immediately tell you something is very wrong, I don't care what kind of "optimization" Clear Linux developers are doing, you're not going to speed up the execution of a program 6 fold just by switching to a different distro.
              As is standard with PTS, all the same compiler flags are used each time, etc. And for each time the CPU/system changes, PTS automatically rebuilds the test so it's not like just one build happened to be super fast but was reproduced on each box.
              Michael Larabel
              https://www.michaellarabel.com/

              Comment


              • #17
                Why do you need to rebuild stuff on each system?
                What should be done, in my opinion, is using the exact same binary on each in order to measure the OS itself.

                As clearly all those tests mainly measure compiler configuration and not the OS itself.

                Regarding x264, it might be the Math Library of Clear Linux which might be much faster?
                Does x264 use FFTW for DCT? If not and it is done utilizing the system math library that could be it.
                Last edited by Royi; 25 September 2018, 09:16 PM.

                Comment


                • #18
                  There's definitely something wrong with the x265 results, I have a Ryzen 1600 with 8GB of DDR4 and 32 GB of swap on a spinning rust WD; I installed the latest PTS and ran the x265 test, with Firefox open and numerous tabs running, using nearly 6GB of ram. This system, in this test state, achieved encoding frame rates of 6.11, 5.88 and 6.02; this is on Ubuntu 18.04.1 LTS. Compare that against 6.73 for a 5960X, 10.94 for a 7980XE, 13.19 for a 2950X and 11.87 for a 2990WX.

                  Michael, are you really going to stand behind the results your software produces when the results show practically no scaling with frequency, IPC or core count? A 6C/12T system being used to the point where most of the available ram is used up manages to achieve results identical to an 8C/16T processor, close to an 18C/36T processor, and 50-60% of processors with 16C/32T to 32C/64T monster cpu's,

                  BTW, what is up with PTS, why does it download Bosphorous to /proc/some-randonly-numbered-folder and why can it not be copied or moved out of that folder? I wanted to try and encode it using a different program like Handbrake or ffmpeg to see what encoding speed that would result in.

                  Anyway, PTS needs fixing.

                  Comment


                  • #19
                    Could ClearLinux be using QSV (Quick Sync) for the tanscodes? If so, is QSV asic enough to give a 6x increase?

                    Comment


                    • #20
                      Originally posted by DanglingPointer View Post
                      Could ClearLinux be using QSV (Quick Sync) for the tanscodes? If so, is QSV asic enough to give a 6x increase?
                      No, x265 does not make use of QSV, it also does not make use of external libraries which some have assumed could be the culprit. There is clearly something wrong with the way these binaries were configured and built on the Ubuntu systems.

                      Comment

                      Working...
                      X