from Hacker News

The Parallelism Blues: when faster code is slower

by bibyte on 2/26/20, 10:00 AM with 23 comments

• by longemen3000 on 2/27/20, 6:51 PM

  In Julia, where the paralleization options are explicit (SIMD, AVX, threads or multiprocessing), it always depends on the load, for small operation (around 10000 elements) a single thread is faster only for the thread spawning time (around 1 microsecond). And there is the issue of the independent Blas threaded model, where the Blas threads sometimes interfere with Julia threads... In a nutshell, parallelization is not a magical bullet, but is a good bullet to have at your disposal anyway

• by AzN1337c0d3r on 2/28/20, 2:40 AM

  There's also the problem of Turbo Boost.

  My laptop's 9980HK will boost to ~4.5 GHz when only loaded to a single core.

  However, when I load up all 8 cores, it might only sustain ~3.5 GHz.

  Therefore the 8 cores might not actually result in the work being completed 8 times as fast, only 6.2x (8*[3.5/4.5]) real-time due to the lowered clock rate of each individual core.

  This will show up as additional user time, since each individual core is able to do less work for each unit of time (seconds) compared to the single-core case.

• by maweki on 2/27/20, 7:12 PM

  "It would be extremely surprising, then, if running with N threads actually gave ×N performance."

  Basically impossible by Ahmdal's law.

• by _bxg1 on 2/27/20, 7:49 PM

  None of this is surprising, right? Unless your system has fewer threads than cores (which it probably doesn't even without your program) there will always be some context-switching overhead. It's worth keeping in mind I guess - especially the fact that numpy parallelizes transparently - but generally these results are to be expected.

  The title is also misleading; it suggests that the wall clock time might be longer for parallel code in certain cases. While not impossible, that isn't what the article covers.

• by ncmncm on 2/28/20, 10:42 PM

  The article uses the term "parallelism" when it is talking, instead, about concurrency.

  Parallelism is specifically the stuff that actually does happen completely independently on all processing units, that actually goes Nx as fast on N units (clock depression aside). Concurrency refers to the overhead of coordinating activity of those units, that keeps you from getting your Nx. It is overhead on top of any actually serial parts of the computation, which Amdahl's law addresses.

  In other words: Parallelism giveth, and concurrency taketh away.

  The distinction gets more useful the more you think about the subject.

• by yaroslavvb on 2/27/20, 8:29 PM

  On 64 core Xeon E5 this example gives 1.8x increase in user time, but 8x decrease in wall-clock time

• by wtracy on 2/27/20, 7:13 PM

  This is perfectly normal behavior when Intel Hyperthreading is involved.

  I'm on my phone, so rather than trying to type out an explanation, I'm going to link to Wikipedia: https://en.wikipedia.org/wiki/Hyper-threading