Sujet : Re: Parallel Forth on a 44 core machine
De : mhx (at) *nospam* iae.nl (mhx)
Groupes : comp.lang.forthDate : 18. Aug 2024, 14:33:27
Autres entêtes
Organisation : novaBBS
Message-ID : <932f13f537e8c918ecd2089466e4c405@www.novabbs.com>
References : 1 2 3 4
User-Agent : Rocksolid Light
On Sun, 18 Aug 2024 12:47:39 +0000,
albert@spenarnc.xs4all.nl wrote:
In article <2df471d1ec39c22949169f8a612b780d@www.novabbs.com>,
mhx <mhx@iae.nl> wrote:
[..]
A new (to me) thing was that processes slow down enormously from
accessing shared global variables (depending on their physical
location), even when no locks are needed/used. For iSPICE such
variables are in OS managed shared memory (aka the swap file)
and are used very infrequently.
>
That agrees with my experience. Parallel processes work with the
same image. The protocol is that one process write to a shared variable,
the other reads. The last process signals the chain that it is
ready. All processes are busy waiting on the signal to stop and to
pass it down the chain.
>
That was on linux with AMD.
Was your experience MS with Intel?
What you seem to describe is that processes interfere when wanting
access to the same (multi-byte) variable. It is obviously tricky to
read a value byte-by-byte when somebody else is updating it
byte-by-byte.
What I meant is severe slowdown when reading variables that are
physically *close* to variables that belong to another process.
It happens for both AMD and Intel on both Windows and Linux.
Spacing such variables farther apart has dramatic impact but
is quite inconvenient in most cases.
I don't recall that transputers had these problems. It may have
to do with the physical memory read/write hardware.
-marcel