Sender: |
|
Date: |
Fri, 1 Apr 2011 01:21:46 +0530 |
Reply-To: |
|
Subject: |
|
MIME-Version: |
1.0 |
Content-Transfer-Encoding: |
8bit |
In-Reply-To: |
|
Content-Type: |
text/plain; charset=utf-8 |
From: |
|
Parts/Attachments: |
|
|
i had to
import ec.util.ThreadPool;
to compile it.
Best,
Pawan
----- 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 Slave.java 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.
Sean
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 distributed
>EC makes sense) then most of your time will be spent in the multithreaded
>section.
>
> 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 will
>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
|
|
|