let me try to answer some of your questions inline below...
On 2/7/20 6:35 PM, Andrew wrote:
This is my first post to this mailing list. It is a
mainly some questions, not a bug report, so I hope it is
appropriate to post it here. Apologies if not. (And apologies
also for a rather long and rambling e-mail!)
No problem, youu found the right list.
I recently learned of Gnu APL and, having had some
experience of APL on IBM mainframes in the 1980s, I was curious
to know how it would work on a couple of my computers, and to
use it to compare performance of two virtualised and emulated
Firstly, I installed it on Ubuntu 18.04.3 running
under VMWare Fusion on a 2.3GHz 8-core Intel i9. This is the
latest SVN version, built using CORE_COUNT-WANTED=syl on
./configure (not make parallels, which gave me a problem with
autoconf). I then used ⎕syl[26;2] to set the number of cores.
Using ⎕ai to obtain the compute time, I tried using
1 and 4 cores for brute force prime number counting, using this
⎕AI is rather imprecise, even worse than ⎕TS. For performance
measurements on Intel
CPUs you should use ⎕FIO ¯1 (return CPU cycle counter) and maybe
⎕FIO ¯2 (return CPU frequency).
⎕FIO ¯1 is the most precise timing source that you can get in GNU
Although I could see, on the system monitor, that 4
cores were being used, the execution time with n=10000 actually
took longer for the 4 core case, typically 15-20% more time than
the 1 core case.
The _expression_ above that you benchmarked is a mix of parallelized
and not parallelized APL
primitives. Each of them is subject to varying execution times, so
it is difficult to tell if the increased
execution time is caused by the parallel execution or by the anyhow
varying execution times.
However, I then tried it in a very different
environment: Ubuntu 18.04.3 again, but running in an emulated
IBM S/390 mainframe (using the Hercules S/370 emulator running
in Ubuntu in VMWare on a 3.5 GHz 6-core Xeon). For n=5000, this
gave the opposite result: the 4 core case was approx. 45%
In my experience using all cores of a CPU is not optimal because
external events from the OS (interrupts
etc) slow down one of the cores used for APL so that the CPU(s) hit
by external events increase the
execution time of each primitive. If you leave one core unused (and
if you are luck), then the scheduler
of the OS will see which cores are busy (execution APL) and will
direct thos events to the unused core.
I also rather doubt that a virtual or emulated environment is able
to tell anything about parallelized APL.
By the way there is a nechmarking workspace Scalar3.apl
shipped with GNU APL that makes benchmarking of parallel GNU APL
easier. Intel I9 is a good platform for running that workspace, but
avoid any virtualizations and ./configure
Directly comparing these two environments (one
“simply” virtualized, the other emulated and virtualized) is not
meaningful. It is to be expected that the emulated one will be
very substantially slower. The more interesting point is,
perhaps, that on the i9, using more cores actually slows it down
whereas, in the emulated environment, which is effectively a
*much* slower processor, using multiple cores does yield a
The speedups that can be achieved are generally disappointing. I
have also compared Intel I7 with intel I9.
Seems like at the same CPU frequency and with the same core count,
the I9 uis substantially faster
than the I7 but at the same time the I7 benefits more from
parallelization than the I9. Most likely the
CPU optimizations in the I9 (compared to I7) aim at the same kind of
parallelism, so that improvements
of one aspect (CPU architecture) are made at the expense of the
other aspect (APL parallelization)
I am not sure which components of the _expression_ (if
any) would be parallelized by Gnu APL. So my questions are:
1. Is it plausible that, on a reasonably modern CPU
(the i9), using multiple cores would slow down execution of this
Could very well be. The _expression_ has a rather small amount of
parallelization since the majority of
its primitives is not parallelized.
2. Which of the operators in the _expression_ above
would Gnu APL actually parallelize?
Currently all scalar functions and inner and outer products of them.
One can proove These are the ones
that in theory and given the GNU APL implementation they must have a
linear speedup (linear in the
number of cores). That is, on an I9 a scalar function on 4 cores
must be 4 times faster than on one
core. In real life it is only 1.5 or so times faster. This points to
a hardware bottleneck between the cores
and the memory. The scalar functions are so lightweight that the
memory accesses (fetching the operands
and storing the results) dominate the entire execution time.
3. Are there any configuration changes that I could
make to adjust the way in which parallelization is done?
If you mean ./configure options by configurations then no. However
some ./configure options have
performance impacts both for parallel and non-parallel execution.
These should be switched off.
See README-2-configure for details.
One other comment:
Before I realised that the svn version is more
recent, I used the apl-1.8.tar.gz version of the code that is
available on the Gnu mirror. This seems to have a minor error
in Parallel.hh: two occurrences of & in the definition of
PRINT_LOCKED, which cause a compilation error. They appear to
have been removed in the svn version.
Yes. In the early days of GNU APL I updated the apl-1.X.tar.gz
files after every bug fix. I was then told
by the GNU project that this would mess up their mirrors so I
stopped doing that. Therefore problems in
1.8 will only be fixed in 1.9, typically 1-2 years later.
Any comments or answers would be appreciated. Thank
you for taking the time to read my e-mail.