stéphane ducasse writes:
 > In Java
 > 
 >   long x = 0;
 >     long timeStart = 0;
 >  
 >     timeStart = System.currentTimeMillis();
 >  
 >     for (int i = 0; i < 1000; i++) {
 >         for (int j = 0; j < 100000000; j++) {
 >             x = x + 1;
 >         }
 >     }
 >  
 >     timeStart = System.currentTimeMillis() - timeStart;
 >     System.out.println(new Long(timeStart).toString());
 >     System.out.println(new Long(x).toString());
 >  
 > ==> 487 secondes.

How long is a Java long? What does it do when it overflows?

I calculated that the answer is 100,000,000,000 which is much
bigger than a SmallInteger so Squeak will be using arbitrary
precision math (BigIntegers).

Try a loop like:
    | x |
    x := 0.
    1
	to: 100000000
	do: [:each| x := x + 1].

Another problem is timesRepeat: is a real method that uses a real
block.  That's currently expensive. Think a full message send rather
than just bytecode execution.

Put the code in a method and view the bytecodes to see what's
going on.

Yes, it is possible to optimise away the block overhead but
currently we don't.

It takes my computer about 8 seconds for my (using the
interpreter). After compiling with Exupery my loop 1.5 seconds to
execute. (I've removed the 1000 timesRepeat: to speed things up and
avoid LargeIntegers).

So why is interpreted Squeak 16 times slower than Java?
   1) It's interpreted
   2) It tag checks the arguments then detags them
   3) It checks if the result overflows then it tags the result
   as an integer.

For the interpreter only 1) really matters, the CPU seems to branch
mispredict about once per bytecode. That takes around 10-30
cycles. The rest of the interpretation time is hidden by that.

2) and 3) matter if you're compiling Squeak. They could be
removed with global type analysis. 

Given enough programming time Squeak could compete.

Bryce