I forgot to reply to the list.
On 07/03/2012 10:33 AM, Harry Spier wrote:
I'm starting to look at Racket concurrency functions (futures and
places) to increase the efficiency of my application and I have a few
questions. Its an OCR application so that once I've segmented the
text and created a data-structure to describe the text, the processing
can be done concurrently at either higher or lower levels. I.e. I can
process pages of a book concurrently, or I can process the pages
sequentially and process lines on a page concurrently or again I can
process lines sequentially but process letters concurrently.
So my questions are:
1) Since there is no communication between my concurrent processes
other than combining the results does it make more sense to use places
rather than futures.
I'd recommend places. You need to make sure you think about
about the ratio of communication to computation. i.e
time to communicate a page of graphical data vs time to OCR a page of
data in the destination place.
2) Is it better to do the concurrency at the highest level possible or
at the lowest level possible. I.e. should I be processing pages
concurrently or should I go to a much lower level and only be
processing letters concurrently. Does it matter?
Using places I would process pages or group of pages concurrently.
3) How does hyperthreading affect the number of places or futures I
can run concurrently? For example if I have an i7 with 4 cores and
hyperthreading, will that run 4 or 8 places concurrently?
(processor-count) will return 8 in this case.
You can choose to launch (processor-count) places or (/
(processor-count) 2) places.
4) Are there any "gotcha's" I need to look out for?
Data sent to places has to be serialized.
Thanks,
Kevin
Harry
____________________
Racket Users list:
http://lists.racket-lang.org/users
____________________
Racket Users list:
http://lists.racket-lang.org/users
