>One participant (Harri Salakoski) said to have already ported ECJ on Java
>1.5 which is wonderful.  We will surely use his experience when we come to that.
Just to clarify that I ported my branch of ecj wich is several years old branch. As much ecj is framework it benefits 1.5 template feature more than average java code. Other hand templates don't help much in low level optimizations like when using integers or raw bytes and I had difficulties with those. There is however "autocapsulation"(Integer->int) feature in 1.5 but I have no glue it performance, I however ported to one ListGenome<T> in vectors package for example. Some of genetic operations still stayed separate per/type.
 
Some examples of interfaces using templates:
 
public interface Mutator<T extends Genome>
    public void mutate(Simulation<T> sim, T inv);
}
public interface Crossover<T>
{
 public void crossover(T a, T b);
}
 
public interface GenomeSource<T extends Genome>
  extends Setup
{
  public T produce(final Subpopulation<T> sub);

  public void prepare(Subpopulation<T> sub);
}
..
 
 
t. Harri
----- Original Message -----
From: [log in to unmask] href="mailto:[log in to unmask]">Colbert Philippe
To: [log in to unmask] href="mailto:[log in to unmask]">[log in to unmask]
Sent: Saturday, October 22, 2005 7:04 PM
Subject: I agree...Java 1.5 has object recycling internally!

Hello!
 
Good comment!  I tend to agree with your statement.  Some peole still code like they want to save micro-seconds.  It's not an issue anymore.  It's better to have cleaner and simpler code than to have heavy complicated code that saves only micro-seconds.   I should know because I have extensive experience in program profiling.   Today's Intel or AMD's 64-bit processor is multi-core (two processor in the same box) and is 64-bit wide (rather than older 32-bit wide).   The cache is often 512 Meg or 1 Meg.  So it is extreemly fast.   It makes small code optimization totally unnecessary.
 
Furthermore, Java 1.5 already has internal object recycling (where possible).   Object recycling makes sense when a big and complexe object is created and deleted inside a fequent loop.   I use object recycling when creating an Individual object (along with its member object like Chromosome, Fitness, ..etc) in an evolution algorithm.  It's the only place I use it.  
 
For the ECJ project, I want it to be able to run on Grid computers so the issue of speed if much less important.   A multi-deme (multi-population) evolution algorithm on a grid computer will surpass any code optimization by a thousand factor.
 
Colbert Philippe
----- Original Message -----
From: [log in to unmask] href="mailto:[log in to unmask]">Arjan Seesing
To: [log in to unmask] href="mailto:[log in to unmask]">[log in to unmask]
Sent: Saturday, October 22, 2005 11:48 AM
Subject: Re: To Sean Luke - Updating ECJ - Good response already!

It is not a change I really made throughout the library, but all the code I've written doesn't use the object recycling which is prevalent throughout ECJ. I don't have any numbers, but it is generaly accepted that object creation is so cheap, that it is useless to recycle large amounts of small objects and that it will actually slow the program down. It also introduces extra unneeded complexity in the design of ECJ and I rather see it go than stay.
 
Just my 2 cents...
Arjan

 
On 10/22/05, Colbert Philippe <[log in to unmask]> wrote:
I am pleased to have already received the response of some people who want
to participate in making modifications to ECJ.  I want to point-out that
my wish is to have a modernized ECJ that can run on personal computers
(Windows or Linux) and more importantly run on Grid servers (like some IBM
related grid service).

I am interested to learn about other platforms that people use ECJ in.

One participant (Harri Salakoski) said to have already ported ECJ on Java
1.5 which is wonderful.  We will surely use his experience when we come to
that.

Always with the agreement of Sean Luke (the custodian of ECJ), I would
agree to open the circle of people participating in the ECJ changes.


One person suggested using CVG (source code control) to do it.  I agree
entirely.   This will secure the updates and will make fixing bugs much
easier.

I was asked by Harri Salakoski:  Why not use the ANT expression
<include name="**/*.java" />
instead of listing each sub-directories?

ANSWER:  I wanted to reuse Sean Luke's list of directory to show him the
ease with which ANT files are used.   There is another deeper reason.
When you make a big change to the code, it is sometimes nice to compile
the project one directory at time.   Using a list of directories in ANT,
you can comment out all but the first directory in the list.  Then run a
compile.   If it's OK you go on and uncomment the second line until the
entire project is compiled.   This incremental way of compile is often
useful.

I am interested to learn about other people who have their own private
changes to ECJ.

Colbert Philippe