Off topic discussion • Re: A bit of Raspberry with 144C/288T

Super linear speedup is stuff of dreams.

I know, a (new) sequential algorithm could simulate the parallel, and result in only linear speedup.

According to Shy, super linear speedup means the serial algorithm did not consider cache blocking and other optimisations which happened as a side effect in the parallel code.

Good potential explanation — I did a parallel run with openmp and numactl forcing on a single core as sequential run, so openmp obviously does not do such optimizations from alone for single omp thread execution.


I started with omp code for parallel best insert.
First sequential version here:
https://github.com/Hermann-SW/RR/blob/m ... rt_seq.cpp

It contains huge arrays at bottom outside of view when editing, for mona-lisa100K coordinates and optimal tour.
And min/max values for all tested scenarioes, which were determined with sequential code and are asserted now.
Only that way I can be sure that parallel code does the right thing (it does for max on initial commit, but not for min).

I implemented double linked random access list with pred[] and succ[] arrays.
For all 100,000 cities s

• that city is ruined
• best (or worst) insert (value only) is determined
• value is asserted against stored 100,000 min/max values
• s is reinserted into doubly linked list for next iteration

Then I created new best_insert.cpp openmp code from it:
https://github.com/Hermann-SW/RR/blob/m ... insert.cpp

For minimum reduction openmp 4.0 is needed — this posting is worth a read;
https://stackoverflow.com/questions/282 ... y#28276420

With OpenMP 4.0 it's possible to use user-defined reductions. A user-defined minimum reduction can be defined like this ...

Luckily my Pi5's gcc 12.2 does fully implement even openmp 4.5:https://gcc.gnu.org/onlinedocs/gcc-12.2 ... MP-4_002e5

The OpenMP 4.5 specification is fully supported.

The example code determines minimal value and position where minimum occurs.
I only need the value, because I will sequentially run though the tour and take first position with that value.
That is fast and guarantees equivalent execution to sequential code.
I changed the Compare struct for that.

Specifying -DDOMAX does maximum determination (worst insert) instead of minimum best insert.
In intial commit that does work, but not without that define, debugging needed.

I used cpplint for that code, but my 3GHz Pi5 does take a loooong time:Reason are the three lines with the huge arrays at the end
Since this is code running from L3 cache, I developed it on my Pi5 — nice.
CPU percent is 99 when run sequentially on a single of its 4 cores, but 393(!) when run on 4:Since no assert happened we know that ruin and worst insert value determination for each of the 100,000 cities worked.


Same code on my 16C/32T AMD 7950X CPU, here 99% versus 1598% CPU:
In addition to minimum not working currently, I had to comment out an assert for DOMAX that works fine sequentially:So debugging is needed.
But it is nice to see that (linear) speedup is seen even in pure cache scenario.

Statistics: Posted by HermannSW — Sun Sep 21, 2025 10:19 pm

---