Re: multithreading

Hi John,


Without any further speculation as to what the cause might be, the 
time-proven technique in this case is to start the program under the 
control of the debugger and hit the "Pause" button in the debugger and 
take a notice of the 2 or 3 functions in the call stack in one of the 
worker threads. Then hit "Continue". Repeat the pause-continue cycle and 
observe which functions pop up most frequently. There are no good rules 
for how many times is enough. Given that the problem is pretty bad (no 
speedup at all), chances are good that you'll find your culprit this way.

Would be interesting to know whether it helps.


best regards,

Andrei Errapart


Am 21.11.2022 um 13:47 schrieb John Selverian:
> When I look at the processors in Taskmanager they are all running at 100%
>
> Kind regards,
>
> js
>
> ==========================
>
> John Selverian, Ph.D.
>
> JAHM Software, Inc.
>
> 29 Valley Rd. <x-apple-data-detectors://0/1>
>
> North Reading, MA 01864-1740 <x-apple-data-detectors://0/1>
>
> https://www.jahm.com <http://www.jahm.com/>
>
>
>> On Nov 21, 2022, at 2:21 AM, Andrei Errapart 
>> <[email protected]> wrote:
>>
>> 
>>
>> 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 <[email protected]>
>>> *Sent:* Sunday, November 20, 2022 2:07 PM
>>> *To:* [email protected]; Enno Rehling 
>>> <[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]
>>> https://lists.sourceforge.net/lists/listinfo/foxgui-users
>> _______________________________________________
>> Foxgui-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/foxgui-users

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