Highly unlikely. Your program actively uses very little memory, so it
isn't going to be a problem with cache capacity.

It is rarely a good idea to override Thread. There is no need for
inheritance.

Using a complex object like Thread as a lock can be a bad idea. Perhaps
the class itself uses it as a lock. In the case of Thread, Sun JRE does.

When they say always put wait in a while loop, don't do it like this.
You are not guaranteed that the wait wont wake up early. Check a
condition in an enclosing while loop.

Although you would expect the square root to dominate, this loop is
simpler if number_of_threads is one. Exactly how it will get optimised,
I have no idea.

Some multicore chips share FPUs. Niagra does, but I don't think Athlons
do. Such code is obviously not going to work so well on shared FPU
processors.

Making the threads daemon only masks your bug above, where threads do
not exit.

Looks odd. I guess you don't want to include the thread start up time.
The other issue is that you have a potential deadlock.

System.currentTimeMillis() is more conventional. Or System.nanoTime()
from 1.5.

Tom Hawtin

Saw your post and thought it was interesting.  I too duplicated your
results but I don't have a clue as to what the problem is.  I wrote a
couple of tests of my own to try and got more predictable results.
Although not quite.

The first program below times the calculations as yours did but I think
it is still not optimum for this test.

The second program calculates the number of calculation cycles per ms
which I think is more to the point.  I got very similar results to the
first test though and that is that one thread is definitely slower than
two threads but more than that don't really improve performance.  On my
single processor machine, every increase in threads reduced the number
of calculations that could be performed although again not as
dramatically as I expected with the increase in number of threads.

I tested these on my 1.6Ghz P4 and on a dual Xeon 2.8Ghz.  The Xeons are
dual core and as I added threads I could see the additional cores being
used.  Another interesting thing, if I used one thread the processor
usage showed 25%, two threads 50% and so on.  The P4 is running Windows
XP Home and the Xeon is running 32bit Windows XP Pro.

I do think that the comment about the floating point processor could be
significant too.

Anyway a very interesting post.

public class test2 implements Runnable {
    int numberOfThreads;
    int calculations = 100000000;
    Thread[] thread;

    public test2(String[] args) {
        numberOfThreads = Integer.parseInt(args[0]);
        thread = new Thread[numberOfThreads];

        long then = System.currentTimeMillis();

        for (int i=0; i<numberOfThreads; i++) {
            thread[i] = new Thread(this);
            thread[i].start();
        }

        try {
            for (int i=0; i<numberOfThreads; i++)
                thread[i].join();
        } catch (InterruptedException ie) {
            ie.printStackTrace();
        }

        System.out.println(System.currentTimeMillis() - then);
    }

    public void run() {
        double d;
        int n = calculations / numberOfThreads;
        for (int i=1; i<=n; i++) {
            d = Math.sqrt(i*1.234);
            double t = d / i;
        }
    }

    public static void main(String[] args) {
        new test2(args);
    }
}

import java.util.concurrent.*;

public class test3 implements Runnable {
    volatile long calculations;
    volatile boolean runFlag = true;
    Object o = new Object();
    Semaphore sem;

    public test3(String[] args) {
        int numberOfThreads = Integer.parseInt(args[0]);
        Thread[] thread = new Thread[numberOfThreads];
        sem = new Semaphore(numberOfThreads);
        try {
            sem.acquire(numberOfThreads);

            for (int i=0; i<numberOfThreads; i++) {
                thread[i] = new Thread(this);
                thread[i].start();
            }
            Thread.sleep(2000);  // wait till all threads are created

            long then = System.currentTimeMillis();
            sem.release(numberOfThreads);
            Thread.sleep(20000);
            runFlag = false;
            long now = System.currentTimeMillis();

            System.out.println(calculations/(now-then));
        } catch (InterruptedException ie) {
            ie.printStackTrace();
        }
    }

    public void run() {
        try {
            sem.acquire();
            while (runFlag) {
                double d = Math.sqrt(1234.56789);
                double t = Math.tan(d);
                ++calculations;
            }
        } catch (InterruptedException ie) {
            ie.printStackTrace();
        }
    }

    public static void main(String[] args) {
        new test3(args);
    }
}

I would say it's almost certainly a dirty cache problem due to SMP access to
shared memory.

Just look at what's happening in the tightest part of the loop. When one thread
writes a value in the array the entire cache line containing that particular
element of the array is marked dirty (don't forget that in a SMP system this
affects the cache line in other processors). This means that before any other
thread can either read or write the same cache line that the cache line must be
re-read from main memory. Since each thread is writing to consecutive elements
of the array, they are almost guaranteed to all be writing to the same cache
line.

This is a standard problem in multi-threaded SMP applications. Get each thread
to keep the updating value in thread local storage, and only fill in the array
when the computation is complete. Compare run times.

I think you've got the wrong idea of the benefits of threads.

Most markedly, threads will reduce your memory usage.  To put it very
simply, a thread is like a lightweight process, so you have reduced
memory overhead when compared to processes.  In other words, it's a lot
less memory intensive to have one application supporting 20 threads
reading input over sockets than configuring 20 applications to read
that data.

As a result of these memory benefits, you get performance benefits as a
byproduct, because the OS has to page swap a lot less often.

I'm coming from a C++ background where I simply created my own threads,
established a mutex for my critical data and/or resources (queue), and
let fly.  So I'm not real fond of Java's screwy implementation of
threads, where every object on the face of the planet has its own
mutex, and Java gives you a lot of rope to hang  yourself waiting for
the mutex availability.  But one thing I can see looking at your code
is that you're using a lot of thread setup to calculate a very simple
result.  The correct analogue is to perform the same task with
processes (does Java even support fork?).

A thread is a very useful tool.  A hammer is a very useful tool, too,
but you wouldn't want to cut a tree down with it.  In the same manner,
you want to use threads for what they're designed: server-type
processes that read data from multiple inputs or perform other
asynchronous tasks with less overhead than processes.