<story><title>Think Before You Parallelize: A tour of parallel abstractions</title><url>https://jackmott.github.io/programming/2016/08/30/think-before-you-parallelize.html</url></story><parent_chain></parent_chain><comment><author>vvanders</author><text>Just a small nit:&lt;p&gt;&amp;gt; Another scenario, say you are working on 3D game, you have some trick physics math where you need to crunch numbers, maybe adding realistic building physics to Minecraft. But separate threads are already handling procedural generation of new chunks, rendering, networking, and player input. If these are keeping most of the system’s cores busy, then parallelizing your physics code isn’t going to help overall.&lt;p&gt;Generally game engines have been migrating towards work-stealing based tasks architectures. Having monolithic thread based systems(one per physics, rendering, gameplay, etc) were great for migrating from the single-threaded games of old, however it leads quite often to idle threads.&lt;p&gt;This was even more critical in the PS3 era where you had SPUs with just ~256kb of RAM. Overall it leads to an architecture that scales well to whatever platform you end up targeting since the CPU&amp;#x2F;compute capabilities of various platforms can be pretty disparate.</text></comment>
<story><title>Think Before You Parallelize: A tour of parallel abstractions</title><url>https://jackmott.github.io/programming/2016/08/30/think-before-you-parallelize.html</url></story><parent_chain></parent_chain><comment><author>wyldfire</author><text>&amp;gt; Don’t Parallelize when it is already Parallelized&lt;p&gt;For the uninitiated -- there&amp;#x27;s probably a large list of &amp;quot;don&amp;#x27;ts&amp;quot; that would be good here, too.  But maybe a prerequisite is ideal: why are you trying to write [this code] to execute in parallel?  &amp;quot;It&amp;#x27;s slow&amp;quot; isn&amp;#x27;t good enough.  You can save yourself a lot of time and headache if you use profilers to understand what the system is doing that makes it slow.&lt;p&gt;Using that profiler will at least help partition the problem into one of two big domains: compute resource bound (cpu&amp;#x2F;bus&amp;#x2F;mem&amp;#x2F;cache etc) or maybe it&amp;#x27;s just pending results from some other async task in the system.  The latter happens much more often than you might expect.  Filesystems, critical locks&amp;#x2F;exclusion, networks, databases, IPC -- there&amp;#x27;s lots of stuff that having multiple tasks in parallel for might not help much.</text></comment>