Announcement

Collapse
No announcement yet.

Benchmarking OpenMandriva 4.0 Alpha - The First Linux OS With An AMD Zen Optimized Build

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

  • #11
    All these tests do is show that for the time being, Clear Linux® folks know what they're doing. I've never seen a Phoronix benchmark disappoint when distros were tested against Clear Linux.

    Comment


    • #12
      Originally posted by jojo7887 View Post
      Recently I got into building the kernel myself, I know how to remove/add drivers and features but never tried these build parameters. Let's say I downloaded the source, got the .config file setup correctly and I'm ready to hit make, how do I add the "Znver1" optimization? Would appreciate any input :-)
      i have used this patch https://github.com/graysky2/kernel_gcc_patch ...runing on debian 9.6 / gcc6.3 / Kernel 4.20 no issues at all

      git apply this patch then use make oldconfig or make menuconfig - it should ask you what arch you want to build against.
      Last edited by CochainComplex; 28 December 2018, 12:07 PM.

      Comment


      • #13
        Originally posted by stormcrow View Post

        That's a very good example, thank you for sharing. Have you tried the code on differing compilers to see if they all behave with slower results with the second, or perhaps different architectures? (ARMv6/7 v. x86 for example) for merely curiosity sake. Conventional wisdom would suggest that removing the conditionals should speed up the execution, at least that's what one prof used to harp on back in the day, seems that's not strictly the case these days with some modern processors and compilers.
        Don't have access to ARM-hardware so have not tested on anything else than amd64. I agree with your prof since that is a conclusion that I've drawn myself from 37 years of programming and it _should_ still apply today considering that lessening the impact of conditionals is why Intel et al went with the branch speculations that lead us to the Spectre vulnerabilities.

        In the end (this was some years ago but the strangeness of it made me remember it to this day) I shrugged it off as either a strange anomaly or a flawed benchmark and decided to keep the optimized version since it made no sense that it would be slower. And the slowdown was very tiny, we are talking some microseconds after processing some millions of messages, and the thing that mattered most was that in all my code was 1600% faster than our precious solution (which was itself 145% faster than the fastest Java implementation available on the open market).

        I read that the SQLite devs no longer runs any benchmarks regularly since the complexity of todays systems taint the picture (which is why I also cringe when I see these benchmarks on Phoronix where the chart shows "number of nanoseconds" since the difference shown there between the systems are probable below the standard deviation anyway) and instead rely on the cycle count done by Valgrind.

        Comment

        Working...
        X