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

  • Wielkie G
    replied
    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.)
    Can you then explain this?



    It doesn't scale linearly with the CPU power, but I would mostly attribute that to the single-thread parts (like final image linking) and not IO. Especially since the benchmarks were done on an SSD.

    Leave a comment:


  • andyprough
    replied
    Originally posted by Eero View Post
    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).
    I'll do that in the future - very interesting.

    Leave a comment:


  • Wielkie G
    replied
    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.

    Leave a comment:


  • Eero
    replied
    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).

    Leave a comment:


  • andyprough
    replied
    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?

    Leave a comment:


  • xpue
    replied
    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.

    Leave a comment:


  • Eero
    replied
    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.)

    Leave a comment:


  • andyprough
    replied
    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; 24 May 2019, 10:57 AM.

    Leave a comment:


  • Mel Spektor
    replied
    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.

    Leave a comment:


  • treba
    replied
    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

    Leave a comment:

Working...
X