Announcement

Collapse
No announcement yet.

Benchmarking AMD FX vs. Intel Sandy/Ivy Bridge CPUs Following Spectre, Meltdown, L1TF, Zombieload

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

  • Benchmarking AMD FX vs. Intel Sandy/Ivy Bridge CPUs Following Spectre, Meltdown, L1TF, Zombieload

    Phoronix: Benchmarking AMD FX vs. Intel Sandy/Ivy Bridge CPUs Following Spectre, Meltdown, L1TF, Zombieload

    Now with MDS / Zombieload being public and seeing a 8~10% performance hit in the affected workloads as a result of the new mitigations to these Microarchitectural Data Sampling vulnerabilities, what's the overall performance look like now if going back to the days of AMD FX Vishera and Intel Sandybridge/Ivybridge processors? If Spectre, Meltdown, L1TF/Foreshadow, and now Zombieload had come to light years ago would it have shaken that pivotal point in the industry? Here are benchmarks looking at the the performance today with and without the mitigations to the known CPU vulnerabilities to date.

    http://www.phoronix.com/vr.php?view=27898

  • #2
    Interesting how after the mitigations, the 8370 ended up being overall faster than the 2400S. Though, had we known about these vulnerabilities around 2012, I still don't think AMD would've endured much less scrutiny.

    Comment


    • #3
      Well, assuming there won't be any similar issues with the AMD processors, this is quite a different picture than a couple of years ago
      I really hope AMD gets rewarded for their safer (more conservative?) architecture this time

      Comment


      • #4
        Originally posted by treba View Post
        Well, assuming there won't be any similar issues with the AMD processors, this is quite a different picture than a couple of years ago
        I really hope AMD gets rewarded for their safer (more conservative?) architecture this time
        the AMD shares have skyrocketed since Ryzen, I don't know if they are gaining market share over Intel but at least Wall Street has rewarded AMD.

        Comment


        • #5
          My completely random, uncritical, non-measured experience this week from turning off hyperthreading on an i3 running Debian Buster:
          a) compiling linux-libre kernel took just about the normal period of time (actually felt just a bit quicker than normal)
          b) building Firefox nightly using rust (from scratch) was extremely slow. Normally it takes maybe 2 hours on this machine, this time it took nearly twice as long.

          Any ideas as to why that would be? I see that the biggest bottlenecks for the i3 in today's testing with no-smt is 'context switching' and 'passing system v messages'. But I do not know how either of those variables would effect kernel compilation vs building firefox with rust.

          edit - I personally think the kernel compilation has been enhanced by the change to gcc8 with the Debian Buster RC1. With Debian Stretch, we were stuck with something much older - gcc6 if I recall.
          Last edited by andyprough; 05-24-2019, 10:57 AM.

          Comment


          • #6
            Kernel code is C, which is fast to compile so its mostly disk bound. Firefox is C++/Rust which is much slower to compile so its CPU bound.

            (I'm assuming you've asked both builds to parallelize to same number of cores.)

            Comment


            • #7
              Originally posted by schmidtbag View Post
              Interesting how after the mitigations, the 8370 ended up being overall faster than the 2400S. Though, had we known about these vulnerabilities around 2012, I still don't think AMD would've endured much less scrutiny.
              2400S is a gimped low-power cpu. And probably still is more energy-efficient.

              Comment


              • #8
                Originally posted by Eero View Post
                Kernel code is C, which is fast to compile so its mostly disk bound. Firefox is C++/Rust which is much slower to compile so its CPU bound.

                (I'm assuming you've asked both builds to parallelize to same number of cores.)
                I'd be interested in what you mean by "bound". Both kernel and firefox building processes ping all available CPU cores to 100% throughout most of the process. Are you saying the CPU has to handle most of the C++/Rust building process in cache, while the C compilation process is able to pull data at a more leisurely pace from disk?

                Comment


                • #9
                  When you say they're at 100% utilization, did you check how much of that was IO-wait? In "top", press "1" to see all cores separately, "wa" column then shows IO-wait percentage for each core. In compilation case, IO-wait would be waiting on disk (in other cases it could be waiting for network, GPU, anything else than CPU).

                  Comment


                  • #10
                    Perl can actually perform better if HT is disabled to avoid the chances it's stuck running on a virtual core.
                    There is no such thing as "virtual core". Each hardware thread in a single core is equal to the other one.

                    Comment

                    Working...
                    X