Originally posted by tildearrow
View Post
Announcement
Collapse
No announcement yet.
AMD Ryzen Threadripper 3990X Offers Incredible Linux Performance
Collapse
X
-
-
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.
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."
- Likes 2
Comment
-
Originally posted by willmore View PostI 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.
Originally posted by willmore View PostOther 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."
Comment
-
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.
Comment
-
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.
Comment
-
Originally posted by pszilard View PostMichael, 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.Michael Larabel
https://www.michaellarabel.com/
- Likes 1
Comment
-
Originally posted by dud225 View PostHi Michael
You should try the kernel compilation test again in light of the recent optimization Linus has brought !
...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)
Comment
-
Originally posted by nuetzel View PostMaybe @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)
Comment
-
Originally posted by xinorom View Post
What part of this patch looks like the Make codebase to you?
Comment
Comment