Announcement

Collapse
No announcement yet.

AMD Ryzen Threadripper 3990X Offers Incredible Linux Performance

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

  • xorbe
    replied
    Originally posted by nuetzel View Post
    Maybe @Michael's 'make' has the mentioned fix already...
    ...mine (openSUSE TW) has.
    I pushed that bug through opensuse for TW. I was hitting the issue, took me 2 weeks to pin it down. Maintainer of gnu make is a really cool person.

    Leave a comment:


  • xinorom
    replied
    Originally posted by nuetzel View Post

    You have to read Linus' whole explanation:

    https://www.realworldtech.com/forum/...rpostid=189958
    No, you have to read his whole explanation.

    I already did...and actually understood it, unlike you...

    Leave a comment:


  • nuetzel
    replied
    Originally posted by xinorom View Post

    What part of this patch looks like the Make codebase to you?
    You have to read Linus' whole explanation:

    https://www.realworldtech.com/forum/...rpostid=189958

    Leave a comment:


  • xinorom
    replied
    Originally posted by nuetzel View Post
    Maybe @Michael's 'make' has the mentioned fix already...
    ...mine (openSUSE TW) has.

    * Mo Jul 16 2018 [email protected]
    - pselect-non-blocking.patch: Use a non-blocking read with pselect to avoid
    hangs (bsc#1100504)
    What part of this patch looks like the Make codebase to you?

    Leave a comment:


  • nuetzel
    replied
    Originally posted by dud225 View Post
    Hi Michael
    You should try the kernel compilation test again in light of the recent optimization Linus has brought !
    Maybe @Michael's 'make' has the mentioned fix already...
    ...mine (openSUSE TW) has.

    * Mo Jul 16 2018 [email protected]
    - pselect-non-blocking.patch: Use a non-blocking read with pselect to avoid
    hangs (bsc#1100504)

    Leave a comment:


  • dud225
    replied
    Hi Michael
    You should try the kernel compilation test again in light of the recent optimization Linus has brought !

    Leave a comment:


  • Michael
    replied
    Originally posted by pszilard View Post
    Michael, any reason why there are no GROMACS benchmarks in here -- in particular as the 39x0X benchmarks did include it? Of the molecular dynamics codes it has the best SIMD support (well, AFAIK NAMD and LAMMMPS do not have AVX2/AVX512 kernels written in SIMD intrisics), and in general it is quite well-tuned tuned for CPU instruction sets compared to most other codes. Hence, it can give a good idea of how a well-tuned code that does take advantage of vector instructions, including Intel's 512-bit AVX.
    Only had so much time between Wednesday and Friday for the embargo lift. (I re-test all processors each time.) But I think GROMACS is in some new 3990X benchmarks out later today IIRC.

    Leave a comment:


  • pszilard
    replied
    Michael, any reason why there are no GROMACS benchmarks in here -- in particular as the 39x0X benchmarks did include it? Of the molecular dynamics codes it has the best SIMD support (well, AFAIK NAMD and LAMMMPS do not have AVX2/AVX512 kernels written in SIMD intrisics), and in general it is quite well-tuned tuned for CPU instruction sets compared to most other codes. Hence, it can give a good idea of how a well-tuned code that does take advantage of vector instructions, including Intel's 512-bit AVX.

    Leave a comment:


  • willmore
    replied
    Originally posted by numacross View Post

    Interesting, I launched ffmpeg with -c:v libx265 and it's saturating my 8c16t Ryzen most of the time, but it's not constant 100% utilization. Maybe yours is limited by the NUMA of your system? It might be a performance optimization to reduce the cost of going across CPU packages for RAM.
    Interesting. I'm using it as part of handbrake, so there's a bunch of other options on the command line. I've tried it on the dual xeon system and on a Ryzen 3700X and seen similar thread use. When I looked into it, I found a lot of people having the same problem and no solutions. It's probably worth looking into again.

    Leave a comment:


  • numacross
    replied
    Originally posted by willmore View Post
    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.
    Interesting, I launched ffmpeg with -c:v libx265 and it's saturating my 8c16t Ryzen most of the time, but it's not constant 100% utilization. Maybe yours is limited by the NUMA of your system? It might be a performance optimization to reduce the cost of going across CPU packages for RAM.

    Originally posted by willmore View Post
    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."
    Other than measuring it directly while benchmarking not really since there's just too much variation.

    Leave a comment:

Working...
X