Very cool. Thanks Sean for the multi-threaded update !

In my experiments it runs smoothly without any problems in multi-threaded
fashion and without any additional imports. I didn't noticed any "single
threaded mode" by such multi-threaded operation so far.


On Fri, 1 Apr 2011 01:21:46 +0530, Pawan Kumar <[log in to unmask]> wrote:

>i had to
>import ec.util.ThreadPool;
>to compile it.
> Best,
>----- Original Message ----
>From: Sean Luke <[log in to unmask]>
>To: [log in to unmask]
>Sent: Wed, 30 March, 2011 8:54:29 PM
>Subject: Re: By Master / slave problems, how to set up on how many threads
to be
>started at the slave side ?
>Okay Nikola... I've added a thread pool to ECJ and have modified so
>that if you evaluate in non-"evolve" mode it'll do so multithreaded using the
>evalthreads parameter.  I haven't tested this much so I'm relying on you (or
>anyone else) to do so and let me know if you see anything amiss.  Feel free to
>send me mail directly so as not to bother everyone on the list.
>On Mar 24, 2011, at 4:09 PM, Sean Luke wrote:
>> On Mar 24, 2011, at 1:26 PM, Nikola N. wrote:
>>> At some point of time all the threads are running, at some point only single
>>> thread is running by the slave.
>> Well, keep in mind that the Slave has to read in Individuals from the stream
>>before it can start working on them (in the "evolve" mode I suggested to you).
>>This means that in a single thread it's sitting there waiting for all the
>>Individuals to be sent over the stream, and only then does it begin evaluating
>>them in a multithreaded fashion.  If your evaluation is expensive with respect
>>to network transfer (which is usually the case for situations where
>>EC makes sense) then most of your time will be spent in the multithreaded
>> At the very least if I can get to whipping up the multithreaded "standard"
>>slave evaluation (non-"evolve" mode) we can set it up so that as soon as an
>>Individual is read in it immediately begins evaluation.  But even so there
>>be a period of time when the fitnesses are sent back that things are gonna
be in
>>single threaded mode for a bit.  There's just no way around it short of
>>constructing an asynchronous response.
>> Sean