Re: multithreading

Jakob,

 

I’ve used FXThread once before. In that instance the calculation took about 3 days and I saw a significant speed-up.

 

I guess we are seeing the same thing, for relatively quick calculations there is not speed up (and even a penalty).

 

Thanks,

 

js

 

From: Jakob Erdmann <[email protected]> 
Sent: Tuesday, November 22, 2022 1:56 AM
To: [email protected]
Subject: Re: [Foxgui-users] multithreading

 

Hi John,

We've observed a similar problem when trying to parallelize a complex traffic simulation which uses fox (and using FXThread as the technical basis). 

Speedup was only observable after using a big work load with at least 10 threads. To our best guess the drop in efficiency was due to inefficient cache use in the multi-threaded case and we didn't yet find a way to solve that. 

Our timing comparison numbers show a similar pattern to yours: https://github.com/eclipse/sumo/issues/9278#issuecomment-946459826

 

regards,

Jakob

 

 

Am Mo., 21. Nov. 2022 um 23:47 Uhr schrieb John Selverian <[email protected] <mailto:[email protected]> >:

Here are the timing results:

 

For 1 thread [0]:

 

 

  0: 116 s

sum: 116 s

 

121 s (2 m : 1 s)

 

 

The thread took 116 s and the entire routine took 121 s, some other stuff minor is also going out outside of the treaded part.

 

 

 

 

For 5 threads [0-4] (I have 6 cores)

 

  0: 182 s

  1: 181 s

  2: 178 s

  3: 176 s

  4: 165 s

sum: 882 s

 

184 s (3 m : 4 s)

 

So I divide the work load into 5 approximately even parts, each individual thread takes ~180 s, the sum of the individual 5 threads is 882 s and the entire routine took 184 s.

 

So while running 5 thread gives a speed up over the sum, each individual thread now takes longer than when I do the entire calculation in 1 thread.

 

I’m not sure what this all means except that more threads take longer. Does anyone have any more insight?

 

 

 

From: Andrei Errapart <[email protected] <mailto:[email protected]> > 
Sent: Monday, November 21, 2022 2:07 AM
To: [email protected] <mailto:[email protected]> 
Subject: Re: [Foxgui-users] multithreading

 

Hi John,

 

From the distance, your situation looks very much as if one thread were doing all the work and the others are either dead or doing nothing useful. You have definitely thought of that, starting up "htop" or "Task Manager" to check whether all the CPU cores are busy all the time as planned?

 

Let me mention that the debugger performs a bunch of other operations at each step (including resuming and stopping all the threads), thus, it can easily disturb your experiment in finding out where the time goes.

 

If I were you, I would measure where the CPU is spending his time, something along the following lines is sufficient for a start:

const FXTime start_ns = FXDate::universalDate().getTime();

... some code

const FXTime end_ns = FXDate::universalDate().getTime();

const double time_seconds = 1e-9 * (end_ns - start_ns);

 

In a multithreaded code one might be interested in:
a) recording the start and stop times of each thread.
b) having a separate log file for each thread - this helps to see whether the threads are performing similarly.

 

 

best regards,

Andrei

Am 20.11.2022 um 20:57 schrieb John Selverian:

It takes a very short time to fill the FXArray, pass the data and start the threads. When I step through the code with the debugger these steps combined take about 2 second per thread.

 

I guess I’ll stick with 1 thread.

 

 

 

From: JVZ  <mailto:[email protected]> <[email protected]> 
Sent: Sunday, November 20, 2022 2:07 PM
To: [email protected] <mailto:[email protected]> ; Enno Rehling  <mailto:[email protected]> <[email protected]>
Subject: Re: [Foxgui-users] multithreading

 


...amdahls law. Indeed. There is always a lot of serial stuff in any code.
Whats worse is that the serial part has its 'working set' mostly cache-resident.

Farming a chunk of work out to other threads first has to make up for the transfer of cached data to the other threads. This needs to happen before the other threads start to actually help, rather than impair, performance.

Again the longer the cpujob is the less this transient behaviour hurts. 

Its why i would suggest vectorization first. It almost always helps..




Sent from my Android device with K-9 Mail. Please excuse my brevity.





_______________________________________________
Foxgui-users mailing list
[email protected] <mailto:[email protected]> 
https://lists.sourceforge.net/lists/listinfo/foxgui-users

 

_______________________________________________
Foxgui-users mailing list
[email protected] <mailto:[email protected]> 
https://lists.sourceforge.net/lists/listinfo/foxgui-users

_______________________________________________
Foxgui-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/foxgui-users