5 ms·

> Several professional tools were also updated, with Zbrush offering a 204,772% performance improvement in specific workloads, showcasing how much can be gaine

> Several professional tools were also updated, with Zbrush offering a 204,772% performance improvement in specific workloads, showcasing how much can be gained when software is optimised with Ryzen in mind. Comments indicate that's not a misprint. I'd love to hear the details of a 204 thousand percent improvement.

mcraiha 8y ago
https://community.amd.com/community/gaming/blog/2017/06/23/even-more-performance-updates-for-ryzen-customers https://community.amd.com/community/gaming/blog/2017/06/23/e... I don't know actual details of that, but words on the internet said that it is just a bug fixed.
- dragontamer 8y ago
  > it is just a bug fixed. As such, we programmers find GREAT interest in these sorts of bug fixes. Every bug is an opportunity for a programmer to learn more about computers!
  - jacquesm 8y ago
    > Every bug is an opportunity for a programmer to learn more about computers! Most bugs I've fixed have taught me relatively little about computers but lots about myself.
lightedman 8y ago
Some bug fix which now allows a workload that once took 22 seconds to complete now only takes 11 milliseconds to complete.
dragontamer 8y ago
https://developer.blender.org/T53068 https://developer.blender.org/T53068 So I dunno about ZBrush. But Blender is a similar 3d program. There was a multithreading issue which would cause Blender to work for HOURS before actually completing some trivial tests. Clearly, AMD Zen / Infinity Fabric has an edge case that older systems can handle just fine. Note that Blender uses Windows pthreads, which has an incredibly BAD implementation of spinlocks and mutexes. Blender fixed this issue by making a customized implementation of spinlocks. I dunno what ZBrush did, but these kinds of architectural regressions happen every now and then.
- Dig1t 8y ago
  I'd love to learn more about Windows pthreads poor implementation of spinlocks mutexes. Do you have any cool links?
  - dragontamer 8y ago
    Citation: myself. I'm not an expert but I think I know enough to see a bad implementation when I see one. As such, please take this analysis with a grain of salt. Second: I'm not entirely sure if this applies to "modern" pthreads-win32, but the Blender project uses a relatively old build of pthreads-win32. Third: my analysis is derived from the Blender diff here: https://dev-files.blender.org/file/data/rjmzozouj44bs6qicd3y/PHID-FILE-cre57pid5mvoizjirptg/file https://dev-files.blender.org/file/data/rjmzozouj44bs6qicd3y... I'm assuming that the Blender devs are smarter than me and have already tested this. :-) ------------ So going through the Blender source code we come across pthread_spin_lock as part of the diff. Considering the comment thread (as well as the diff) as adding Win32 #ifdefs and such, we can assume this was the cause of the performance issue. --------- I assume... okay, so my logic isn't 100% tight, sorry :-(... that the implementation uses this pthreads-win32: http://sourceware.org/pthreads-win32/ http://sourceware.org/pthreads-win32/ Which brings us to here: ftp://sourceware.org/pub/pthreads-win32/sources/pthreads-w32-2-9-1-release/pthread_spin_lock.c --------- Lets break it down why this is a bad implementation: 1. No "pause" instruction, causing latency issues when leaving the spinlock. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms687419(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... or https://software.intel.com/en-us/node/524249 https://software.intel.com/en-us/node/524249 for more information on why "pause" should be used in every spinlock. Strangely enough, the "pause" instruction is found in Linux implementations of pthreads (so the author for pthreads-w32 just... didn't look at the Linux implementation or something?) 2. PTW32_INTERLOCKED_COMPARE_EXCHANGE_LONG seems inefficient to me. I'd imagine that the usage should be using a swap instead (aka: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-interlockedexchange https://docs.microsoft.com/en-us/windows-hardware/drivers/dd... ). Although I don't have any microbenchmark that "proves" this, I'd imagine that a swap is more efficient than a compare-and-swap. 3. A potential "slowpath" which includes a mutex-lock. Note that Windows Mutexes are incredibly heavy: including security features and even a "filesystem like" naming scheme. (See Windows Object Handles if you don't believe me). Windows Mutexes are very fully featured: recursive, multiple levels of security, and more. This is a common problem in Linux system-coders -> Windows system coders. The Windows "Critical Section" is a more appropriate replacement for Linux pthread_mutexes. I'd say Windows Mutexes might be more similar to a Linux filesystem-level semaphore. Linux semaphores provide those security features integrated with the filesystem. The to Linux mutexes and spinlocks is something called a "Critical Section" in Windows land. https://docs.microsoft.com/en-us/windows/desktop/Sync/critical-section-objects https://docs.microsoft.com/en-us/windows/desktop/Sync/critic... Critical sections are Windows's lightweight yielding / task sleeping mechanism. --------- Finally, Windows provides a spinlock: https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-initializecriticalsectionandspincount https://docs.microsoft.com/en-us/windows/desktop/api/synchap... Which is probably is what pthreads-w32 should really be using. I mean, Linux devs basically just don't know what Windows offers, and the pthread-win32 library is a poor fit at the moment. ----------------- Sorry if you were expecting more complete analysis and testing. Lol. Its mostly me looking at the thing and making a guess and reverse-engineering the patch-notes from the Blender discussion.
KaiserPro 8y ago
AMD send out hardware all the time. When I worked at a visual effect software house, AMD would send us all sorts of things. The main problem was thier linux drivers were terrible. A lot of the time thier hardware was faster at certain things. At one point (this is about the time of the quadro 2/3/4/5/6/000) the AMD firepro was 8 times as fast. However their driver support was terrible, and the time to fix was 6months+ There was a reason why the mac pro had two AMD GPUs in them, they were at the time light years faster.(and cheaper.)
jcl 8y ago
Since ZBrush is a widely used 3D program, it may come as a surprise to many that it barely uses the GPU, relying almost exclusively on the CPU to render millions-of-polygon models at interactive speeds. ( https://pixologic.com/zbrush/system/ https://pixologic.com/zbrush/system/ ) So there are big performance benefits to tuning ZBrush to take advantage of a particular processor's features and avoid its weaknesses. I'm also curious what the exact issue was, but given the scale of improvement, I wouldn't be surprised if it is some sort of cache contention between threads/processors. A cache miss in the inner loop of an algorithm can be catastrophic, and apparently Ryzen has pretty different cache behavior versus other CPUs: https://www.reddit.com/r/Amd/comments/5x7oaq/ryzens_memory_latency_problem_a_discussion_of/ https://www.reddit.com/r/Amd/comments/5x7oaq/ryzens_memory_l...
morganvachon 8y ago
According to the comments it was a 22 second workload reduced to 11 milliseconds. If that's true, it's mind-numbingly insane. That's an order of magnitude improvement over going from a 80386 to a modern Core i7 (~14,000%)[1]. [1] http://3dfmaps.com/CPU/cpu.htm http://3dfmaps.com/CPU/cpu.htm

mcraiha 8y ago

https://community.amd.com/community/gaming/blog/2017/06/23/even-more-performance-updates-for-ryzen-customers https://community.amd.com/community/gaming/blog/2017/06/23/e... I don't know actual details of that, but words on the internet said that it is just a bug fixed.

dragontamer 8y ago
> it is just a bug fixed. As such, we programmers find GREAT interest in these sorts of bug fixes. Every bug is an opportunity for a programmer to learn more about computers!
- jacquesm 8y ago
  > Every bug is an opportunity for a programmer to learn more about computers! Most bugs I've fixed have taught me relatively little about computers but lots about myself.

lightedman 8y ago

Some bug fix which now allows a workload that once took 22 seconds to complete now only takes 11 milliseconds to complete.

dragontamer 8y ago

https://developer.blender.org/T53068 https://developer.blender.org/T53068 So I dunno about ZBrush. But Blender is a similar 3d program. There was a multithreading issue which would cause Blender to work for HOURS before actually completing some trivial tests. Clearly, AMD Zen / Infinity Fabric has an edge case that older systems can handle just fine. Note that Blender uses Windows pthreads, which has an incredibly BAD implementation of spinlocks and mutexes. Blender fixed this issue by making a customized implementation of spinlocks. I dunno what ZBrush did, but these kinds of architectural regressions happen every now and then.

Dig1t 8y ago
I'd love to learn more about Windows pthreads poor implementation of spinlocks mutexes. Do you have any cool links?
- dragontamer 8y ago
  Citation: myself. I'm not an expert but I think I know enough to see a bad implementation when I see one. As such, please take this analysis with a grain of salt. Second: I'm not entirely sure if this applies to "modern" pthreads-win32, but the Blender project uses a relatively old build of pthreads-win32. Third: my analysis is derived from the Blender diff here: https://dev-files.blender.org/file/data/rjmzozouj44bs6qicd3y/PHID-FILE-cre57pid5mvoizjirptg/file https://dev-files.blender.org/file/data/rjmzozouj44bs6qicd3y... I'm assuming that the Blender devs are smarter than me and have already tested this. :-) ------------ So going through the Blender source code we come across pthread_spin_lock as part of the diff. Considering the comment thread (as well as the diff) as adding Win32 #ifdefs and such, we can assume this was the cause of the performance issue. --------- I assume... okay, so my logic isn't 100% tight, sorry :-(... that the implementation uses this pthreads-win32: http://sourceware.org/pthreads-win32/ http://sourceware.org/pthreads-win32/ Which brings us to here: ftp://sourceware.org/pub/pthreads-win32/sources/pthreads-w32-2-9-1-release/pthread_spin_lock.c --------- Lets break it down why this is a bad implementation: 1. No "pause" instruction, causing latency issues when leaving the spinlock. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms687419(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... or https://software.intel.com/en-us/node/524249 https://software.intel.com/en-us/node/524249 for more information on why "pause" should be used in every spinlock. Strangely enough, the "pause" instruction is found in Linux implementations of pthreads (so the author for pthreads-w32 just... didn't look at the Linux implementation or something?) 2. PTW32_INTERLOCKED_COMPARE_EXCHANGE_LONG seems inefficient to me. I'd imagine that the usage should be using a swap instead (aka: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/nf-wdm-interlockedexchange https://docs.microsoft.com/en-us/windows-hardware/drivers/dd... ). Although I don't have any microbenchmark that "proves" this, I'd imagine that a swap is more efficient than a compare-and-swap. 3. A potential "slowpath" which includes a mutex-lock. Note that Windows Mutexes are incredibly heavy: including security features and even a "filesystem like" naming scheme. (See Windows Object Handles if you don't believe me). Windows Mutexes are very fully featured: recursive, multiple levels of security, and more. This is a common problem in Linux system-coders -> Windows system coders. The Windows "Critical Section" is a more appropriate replacement for Linux pthread_mutexes. I'd say Windows Mutexes might be more similar to a Linux filesystem-level semaphore. Linux semaphores provide those security features integrated with the filesystem. The to Linux mutexes and spinlocks is something called a "Critical Section" in Windows land. https://docs.microsoft.com/en-us/windows/desktop/Sync/critical-section-objects https://docs.microsoft.com/en-us/windows/desktop/Sync/critic... Critical sections are Windows's lightweight yielding / task sleeping mechanism. --------- Finally, Windows provides a spinlock: https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-initializecriticalsectionandspincount https://docs.microsoft.com/en-us/windows/desktop/api/synchap... Which is probably is what pthreads-w32 should really be using. I mean, Linux devs basically just don't know what Windows offers, and the pthread-win32 library is a poor fit at the moment. ----------------- Sorry if you were expecting more complete analysis and testing. Lol. Its mostly me looking at the thing and making a guess and reverse-engineering the patch-notes from the Blender discussion.

KaiserPro 8y ago

AMD send out hardware all the time. When I worked at a visual effect software house, AMD would send us all sorts of things. The main problem was thier linux drivers were terrible. A lot of the time thier hardware was faster at certain things. At one point (this is about the time of the quadro 2/3/4/5/6/000) the AMD firepro was 8 times as fast. However their driver support was terrible, and the time to fix was 6months+ There was a reason why the mac pro had two AMD GPUs in them, they were at the time light years faster.(and cheaper.)

jcl 8y ago

Since ZBrush is a widely used 3D program, it may come as a surprise to many that it barely uses the GPU, relying almost exclusively on the CPU to render millions-of-polygon models at interactive speeds. ( https://pixologic.com/zbrush/system/ https://pixologic.com/zbrush/system/ ) So there are big performance benefits to tuning ZBrush to take advantage of a particular processor's features and avoid its weaknesses. I'm also curious what the exact issue was, but given the scale of improvement, I wouldn't be surprised if it is some sort of cache contention between threads/processors. A cache miss in the inner loop of an algorithm can be catastrophic, and apparently Ryzen has pretty different cache behavior versus other CPUs: https://www.reddit.com/r/Amd/comments/5x7oaq/ryzens_memory_latency_problem_a_discussion_of/ https://www.reddit.com/r/Amd/comments/5x7oaq/ryzens_memory_l...

morganvachon 8y ago

According to the comments it was a 22 second workload reduced to 11 milliseconds. If that's true, it's mind-numbingly insane. That's an order of magnitude improvement over going from a 80386 to a modern Core i7 (~14,000%)[1]. [1] http://3dfmaps.com/CPU/cpu.htm http://3dfmaps.com/CPU/cpu.htm