Re: [Bug-apl] errors in latest SVN

[Juergen Sauermann]

Hi Peter,

I see. Looking on the web it appears as if OSX does not support the POSIX API for thread
affinities but use their own. GNU may work without setting the affinities explicitly (because all
threads will have 100% load, so the scheduler should be able to distribute the threads evenly).
However I have seen cases in the past where that was not the case (not OSX, though).

I believe I should first try to get parallel APL working on linux in a way that it still compiles under OSX
and then we could see how to port it to OSX. For you (or OSX) that would mean to not ./configure
the CORE_COUNT_WANTED and to please complain if some relict of the POSIX API slips in.

Regarding parallelism in APL, I have proven in my 1990 Ph. D. thesis that effectively all APL operators
can be implemented in parallel (with the exception of same obvious counter-examples in the architecture that
we had at that time).

My current plan is to take the algorithms of that thesis and to implement them in GNU APL (this was BTW
one of the reasons for creating GNU APL). I have got dyadic scalar functions sort of working in parallel yesterday.
On a 10000000 element vector I could see quite some speedup on my 4-core machine, but I also saw that some
other parts - in particular the release of big vectors - needs to be parallelized as well before this becomes usable.

/// Jürgen

On 09/17/2014 09:09 PM, Peter Teeson wrote:

Hi Jürgen:

I did a locate pthread* and there are only 3 .h files that show up for OS X 10.8 and 10.9 in the SDKs. 

I happen to be coding in APL something that would greatly benefit from parallel capability.

My machine only has 2 x 2.66 Quad-Core Intel Nehalem  processors and each core can run 2 threads.

But most of the time most of the cores are idle.

Except in my case with the APL solution to my problem because it uses fairly deep recursion.

My thinking is that the ¨ (each) primitive would be a candidate for trying out a parallel approach.

Of course given an APL capability for parallelism one could perhaps consider a different algorithm.

(Historical note: At IPSA when we had a dual processor IBM Model 158 we did experiment with co-routines.)

On 2014-09-17, at 12:39 PM, Juergen Sauermann <address@hidden> wrote:

Hi Peter,

fixed in SVN 478.

Looks like your box is lacking some functions like pthread_getaffinity_np() (or they have different argument types).
This could become a problem for parallel APL later, so maybe you want to grep -r  for them in /usr/include or find
out how core affinities are set on your box.

/// Jürgen

On 09/16/2014 07:25 PM, Peter Teeson wrote:

/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Parallel.cc:181:1: Unknown type name 'cpu_set_t'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Parallel.cc:197:55: Use of undeclared identifier 'cpu_set_t'
/Volumes/Data/Development/MyProjects/GNUAPL/apl-svn/src/Parallel.cc:323:1: Unknown type name 'cpu_set_t'