VB wrote:

To ChrisH:

“Thousands of active agents interacting with each other” so what, no problem, don’t create an OS thread per agent, Erlang isn’t !!”

How would you model the agent then? With a state machine?
This is going to be a hell.

By the way, Erlang is not about green threads but about share-nothing, side-effectlessness, concurrency and composability. It’s just better suitable for concurrency than Java, that’s it.

Your basically arguing green threads vs native threads not Java vs Erlang, both of which I believe come in various threading flavours.

The thread limits, memory etc is an OS thing , not Java vary your JVM you’ll get different results e.g. an early JVM will most likely green thread and with bad coding like yours possibly beat the new JVM on a single core .

Yes a badly written Java app, particularly on a very old JVM (not too old mind as the very old ones tend to be green threaded and that would give Java a chance) on a single core machine can be beaten by a green thread App even Visual Basic .

… but surprise if you use modern Java or allow threading pooling and/or combine with multicore and your Erlang looks like its in big trouble.

“Thousands of active agents interacting with each other” so what, no problem, don’t create an OS thread per agent, Erlang isn’t !! it just makes a representation of a thread, Java can do that.

PS Note in no way am I commenting on the elegance of the languages purely on the benchmarks.

Such tasks are solved in Java by using the non blocking IO and a single thread which does actual processing. With modern framework such progamming style is either completely transparent to program or very simple to use. See AsyncWeb & the Grizzly/Glassfish.

Also, I think that the thread pool is extremally helpful & provides simplicity identical to thread spawning in 90% of cases.

Actually Java used to had a number of lightweighted thread implementations like famous green threads or JRockit thinthreads. All of them was invented to cope slow Linux threading before kernel 2.6 & NPTL and dropped immediately after kernel 2.6 was adopted. Simply because there are no real business cases for Java there such kind of lightweight processes are useful.

Could you please give me the real world sample of task which is not a subject to solve via simple thread pool and is not IO bound?

Also, why Erlang has slow message passing in SMP configuration? The reason is the lack of good scheduler which can’t place dependant processes in the single OS thread?

I mean that in Java in order to achieve high performance developers do use pool of workers which actually does the same work as if there will be a lot of threads spawned.

I believe that there is no practical task which could not be solved with pool of workers, if the worker is blocked by network IO we can always use the non-blocking IO.

So, I mean that actually Java can do better then Erlang on concurrent programming if it’s used properly, keeping in mind it’s limitations and advantages.

import java.util.concurrent.*;

public class Test25 extends Thread {
public static Executor executor;

public static void main(String[] args) throws InterruptedException {
    int M = Integer.parseInt(args.length > 0 ? args[0] : "1");
    int N = Integer.parseInt(args.length > 1 ? args[1] : "1000000");
    executor = Executors.newFixedThreadPool(M);
    int NpM = N / M;
    BlockingQueue queue = new ArrayBlockingQueue(1000 * 1000);
    long startTime = System.currentTimeMillis();
    for (int i = 0; i < M; i++) executor.execute(new Body(queue, NpM));
    for (int i = 0; i < N; i++) queue.take();
    long stopTime = System.currentTimeMillis();
    System.out.println((NpM * M) / ((stopTime - startTime) / 1000.0));
}

public static class Body implements Runnable {
    BlockingQueue queue;
    int count;
    public Body(BlockingQueue queue, int count) {
        this.queue = queue; this.count = count;
    }
    public void run() {
        try {
            for (int i = 0; i < count; i++) queue.put(this);
        } catch (InterruptedException ex) {
            ex.printStackTrace();
        }
    }
}

}

Makes 1.5mln/sec on 3ghz P4 (windows xp)
It uses a thread pool and a loop instead of recursion.

1 million something?

Goodness…. And you’d figure that a Sun workstation would be where java would somehow be champ.

@julian: The most recent version of Erlang is SMP aware.