Announcement

Collapse
No announcement yet.

AMD Ryzen Threadripper 3990X Offers Incredible Linux Performance

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

  • willmore
    replied
    Originally posted by xinorom View Post

    Way to make your censorship obvious, tildearrow . If you're going to delete my original post and his quoting of it, you may just as well hide your tracks and delete his whole post too.

    Looks like we got a new Reddit-style power mod over here.
    Or, crazy idea, try to stay on topic and not drag unrelated political crap into every discussion?

    There's a # of posts counter, can we get a "# of posts that were OT and useless" counter? Maybe a ratio? As of this moment, you have 74 posts and I'm willing to bet a good chunk of them are useless crap like you posted earlier.

    Back on topic:

    I picked up a used dual Xeon 5660 server a while back (6 cores/12 threads each CPU) and I've been having a fun time seeing how well threaded (or not) different pieces of software are. It's been quite an education coming from a desktop/laptop CPU background where you have maybe 4 threads to work with. Most software fits into three categores: Not threaded at all, lightly threaded, and more-cores-please. It's the middle category that I've found to be the most interesting. If I had been asked, I would have guessed that programs like x265 would be heavily threaded, but that's not the case. Even with agressive settings, it uses around 6 threads.

    Other than knowing how different programs approach threading, would there be a way to indicate the 'threadieness' of a task in the benchmark results? I know that Michael often comments on the performance and uses that (or headings) to indicate the single threaded/multi-threaded nature of certain benchmarks, but we see people way too often say silly things like "I see this 64 core processor is slowe than a <insert high clocked low core CPU>, LOLz."

    Leave a comment:


  • numacross
    replied
    Originally posted by tildearrow View Post
    Hmmmm...

    My 6700K took 8 hours to compile Chromium...

    ...which means: 64/4=16

    (8/16)*4.0/2.9=approx. 0.69 hours on a 3990X (not considering architecture differences)
    Unfortunately it's not as simple as that. From the few compilation benchmarks I've seen the scaling between CPUs is not linear and very dependant on what you're actually compiling. For example GCC sees almost no improvement in high core counts while Firefox scales better. Hopefully Michael can supply us with some more compile tests.

    Leave a comment:


  • xinorom
    replied
    Originally posted by vb_linux View Post
    It may be this or their roadmap vision, but you seem to be jumping through hoops to somehow justify your bias.

    Last edited by tildearrow; 02-09-2020, 07:44 PM.
    Way to make your censorship obvious, tildearrow . If you're going to delete my original post and his quoting of it, you may just as well hide your tracks and delete his whole post too.

    Looks like we got a new Reddit-style power mod over here.
    Last edited by xinorom; 02-09-2020, 10:20 PM.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by numacross View Post

    "Fortunately" you can still take hours to compile Chromium
    Hmmmm...

    My 6700K took 8 hours to compile Chromium...

    ...which means: 64/4=16

    (8/16)*4.0/2.9=approx. 0.69 hours on a 3990X (not considering architecture differences)

    Leave a comment:


  • vb_linux
    replied
    It may be this or their roadmap vision, but you seem to be jumping through hoops to somehow justify your bias.
    Last edited by tildearrow; 02-09-2020, 08:44 PM.

    Leave a comment:


  • dispat0r
    replied
    Originally posted by Linuxxx View Post

    So what You are saying is that these Threadrippers NEVER enter their sleep-states?

    That alone would already put them at a huge advantage versus the Intel counter-parts! (With greatly increased power-draw, of course...)

    Again, bridgman, any explanation for that behavior?
    Not exactly I mean the idle power draw is the same with idle=poll as without and a can see with perf top hat the acpi_idle functions are not active.

    Leave a comment:


  • Linuxxx
    replied
    Originally posted by Michael View Post

    When measuring AC power draw with Ryzen/Threadripper/EPYC is clearly a big difference between idle and load on all my systems tested.
    OK then, dispat0r, care to chime in & try to find out what's wrong with Your setup?

    Also, I'd still be interested if AMD plans to ever finish & mainline their special CPU driver for the Zen architecture?
    (Build around schedutil, I assume, since that what Linux developers requested from AMD.)

    Leave a comment:


  • Michael
    replied
    Originally posted by Linuxxx View Post

    So what You are saying is that these Threadrippers NEVER enter their sleep-states?

    That alone would already put them at a huge advantage versus the Intel counter-parts! (With greatly increased power-draw, of course...)

    Again, bridgman, any explanation for that behavior?
    When measuring AC power draw with Ryzen/Threadripper/EPYC is clearly a big difference between idle and load on all my systems tested.

    Leave a comment:


  • Linuxxx
    replied
    Originally posted by dispat0r View Post

    On a 3970x you can have idle=poll with no difference in power usage so something is up with acpi_idle.
    So what You are saying is that these Threadrippers NEVER enter their sleep-states?

    That alone would already put them at a huge advantage versus the Intel counter-parts! (With greatly increased power-draw, of course...)

    Again, bridgman, any explanation for that behavior?

    Leave a comment:


  • mppix
    replied
    Related question, does anyone know how well intel optane performs as \swap?
    They did persistent RAM, but how is the nvme performance?

    Leave a comment:

Working...
X