Announcement

Collapse
No announcement yet.

AMD Ryzen 5 2600X + Ryzen 7 2700X Linux Benchmarks

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

  • char
    replied
    About anandtech's test:

    -----------------------------------
    TechRadar & the wccftech preview has the same results. If you have been following Spectre as I have, you would've seen even users find this result. See the top comments here. https://np.reddit.com/r/pcmasterrace...atch_and_bios/

    AT, TR & WCCF's results are accurate. Many reasons for this.
    - Many reviewers used the old Ryzen balanced power setting which cripples the 2700X
    - Disallowed the motherboard settings that push the chip over TDP
    - Fully patched as possible for Spectre v1 & v2, which cripples Intel up to 50% in IO heavy tasks (streaming textures for games that do so).
    -----------------------------------

    Summary of various reviews: (anandtech' is not the only one with poor intel)
    Als kleinen Vorgeschmack auf die kommende Launch-Analyse zu AMDs Ryzen 2000 sollen hiermit schon einmal aufgelaufenen Testresultate zur Anwendungs-Performance ausgewertet werden. Gemäß der preislichen Ansetzung sind hierbei die Duelle "Ryzen 7

    Leave a comment:


  • austin754
    replied
    There are several reasons why I wonder if the Phoronix test configuration for redis is particularly appropriate to use in comparing these systems. After looking at the redis benchmark page and timing the application/workload, I'll note:

    1. Redis is a single-threaded server not designed to benefit from multiple CPU cores. It also appears Phoronix runs this instance without pinning on a NUMA topology, which adds uncertainty. The entire workload run is very short, completing in less than 1/2 second on all your test systems. A single test itself runs for slightly over 10 seconds but the vast majority is a 10 second sleep(1) to make sure the database is ready.

    2. The Redis benchmark page linked below, says "Redis is, mostly, a single-threaded server from the POV of commands execution (actually modern versions of Redis use threads for different things). It is not designed to benefit from multiple CPU cores. People are supposed to launch several Redis instances to scale out on several cores if needed. It is not really fair to compare one single Redis instance to a multi-threaded data store." Wouldn't it make more sense to run many instances of Redis when comparing servers with many cores?

    3. The Redis benchmark page also says, "on multi CPU sockets servers, Redis performance becomes dependent on the NUMA configuration and process location. The most visible effect is that redis-benchmark results seem non-deterministic because client and server processes are distributed randomly on the cores. To get deterministic results, it is required to use process placement tools (on Linux: taskset or numactl)." When the benchmark doesn't pin, in addition to being non-deterministic, it might be difficult to separate out the effects of bad process placement vs. performance of the network sockets that are pushing along 2-byte data sets.

    What exactly are you using redis to measure and compare?

    --mev

    Leave a comment:


  • char
    replied
    Originally posted by angrypie View Post
    Ian is now an AMD shill,
    I don't think so, we'll see...

    Ian Cutress wrote:
    "Update: A number of comments have noted that some of our gaming numbers are different to other publications. To clarify, we used the latest ASUS 0508 BIOS (on X470), full Windows RS3 + updates, Spectre/Meltdown patches, and updated gaming titles. We are reviewing the data."

    Leave a comment:


  • angrypie
    replied
    Originally posted by char View Post

    Yep, you're right. Anandtech's Ian Cutress tested with patches (negative impact on Intel's)
    Ian is now an AMD shill, at least until Cascade Lake/Coffee Lake-S is released. When 7nm Zen is released he will be an AMD shill again.
    Last edited by angrypie; 22 April 2018, 09:26 AM.

    Leave a comment:


  • char
    replied
    Originally posted by k1e0x View Post
    Were the Intel chips tested with the new microcode and spectre/meltdown patches? That seems to be the root of variance on testing out there..
    Yep, you're right. Anandtech's Ian Cutress tested with patches (negative impact on Intel's)

    Leave a comment:


  • MaxToTheMax
    replied
    These are some of the most consistent results I've ever seen.

    Leave a comment:


  • k1e0x
    replied
    Were the Intel chips tested with the new microcode and spectre/meltdown patches? That seems to be the root of variance on testing out there..

    Leave a comment:


  • leipero
    replied
    Originally posted by Brisse View Post
    Why is Handbrake interesting when we already have x264? It's just more of the same. Handbrake is relying on libraries such as x264 for encoding.
    It's interesting because that is one of the 2 tests only where 2600x actually performs faster than 8700k, by testing on 2 different platforms we can see if and where is the actual problem on GNU/Linux platform if it is big difference compared to Windows platform. From that perspective it is very important for GNU/Linux itself, not for one CPU or the other.

    For example, if difference is very big in all cross platform tests in favor of Windows (regardless of the CPU, but especially if one architecture is hit far more than the other) we should seek answers in GNU/Linux itself for potential problem, if however the difference is only in specific tests on x264 for example, including handbrake, than we should seek potential problem there (it could be in other software tho...). From that perspective it is very important to have as much cross platform tests as possible, because it is not just curious people who read those articles, but also people involved in contributions to GNU software and Linux kernel itself.

    Without (universal = meaning covering as much aspects as possible) cross platform tests we can't say for sure if some numbers are not on pair of what hardware should do or not, or if one platform or another gets benefits/disadvantages to how it could actually work. This methodology would partially help solving that problem IMO.
    Last edited by leipero; 20 April 2018, 08:29 AM.

    Leave a comment:


  • nomadewolf
    replied
    Originally posted by Brisse View Post

    Did it freeze mid sentence while you were writing ? ^_^
    No!
    I swear that never happ

    Leave a comment:


  • Brisse
    replied
    Why is Handbrake interesting when we already have x264? It's just more of the same. Handbrake is relying on libraries such as x264 for encoding.

    Leave a comment:

Working...
X