Re: multithreading

John Selverian <[email protected]>
Newsgroups gmane.comp.lib.fox-toolkit.user
Message-ID <[email protected]>
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.

North Reading, MA 01864-1740

https://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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.