Must apologize for not looking back at Case 2 when I previously wrote. I was
remembering the issue of making tab delimited files, not the image problem.
On the converting to a tab delimited format, I assumed that even though it
is very compute intensive that it was still faster than the disk. That may
not be true. If untrue then multiple cores would speed things up. But the
system optimization of writes could still mess up any timings. A while back
I was using some standard software to move files around. It started ran
pretty quickly. It ended, but the disk busy light stayed on for ten or
fifteen seconds after the program ended. How long did it really take? Was it
the five seconds the program ran or the maybe twenty seconds before all the
disk operations completed?
So about Case 2. Haven't looked at it too closely yet as I wanted to correct
my earlier remarks. Transposing and rotating arrays, though simple to
understand, are very memory intensive. Cache memory doesn't help much as any
problem of decent size exceeds the size of cache memory. The CDC 205 had a
special instruction to help. IBM vector processors had a stride option to
help too.
De-speckling is easy to implement in J. Given the tough part, a verb to look
at each subarray around each point, compute the new value for the point,
then use it with outfix (\.).
One major difficulty in writing J code to utilize multiple cores is that J
must become idle for the application code to see interrupts. The J task can
start several other cores (J sessions) on various pieces of the problem, but
in order to accept the completion of a core task and start the core on
another part, J must become idle. So restructuring a problem to utilize
multiple cores means a total re-write.
I would like to do multi-core applications something like I saw in Pascal
years ago. A proposed extension called COBEGIN/COEND.
COBEGIN;
TASK1;
TASK2;
TASK3;
COEND;
The statements within the block must be mutually independent. The statements
in the block could be run in any order including overlapping. Can't do that
in J. But doesn't this resemble J's each, rank and outfix? Somehow we need
to be able to do something similar in J.
I would like to write something like:
rotatepicture=:3 : 0
'(rotate fread y)fwrite y' startcore y
)
events=:rotatepicture each {."1 fdir '*.jpg'
wait events
where startcore schedules the statement to be run and returns a semaphore
that is set when the statement completes. Then wait hangs until all the
semaphores are set. Can't do that in J. Or can we?
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
