Thanks Ali. I have tried putting GC.disable() in both main and
runJob, but the timing behaviour did not change. The python
version works in a similar fashion and also has automatic GC. I
tend to think that is not the (biggest) problem.
The program is long and newbie-ugly ... but I could put it
somewhere if that would help.
Gerald
On Tuesday, 12 May 2015 at 15:24:45 UTC, Ali Çehreli wrote:
On 05/12/2015 07:59 AM, Gerald Jansen wrote:
> the performance of my D version deteriorates
> rapidly beyond a handful of jobs whereas the time for the
Python version
> increases linearly with the number of jobs per cpu core.
It may be related to GC collections. If it hasn't been changed
recently, every allocation from GC triggers a collection cycle.
D's current GC being a stop-the-world kind, you lose all
benefit of parallel processing when that happens.
Without seeing runJob, even arr2.dup may be having such an
effect on the performance.
Ali
