Re: java layer performance comparisions

[Marcus G. Daniels]

B> Any idea why there is such a huge difference in the performancs of
B> JDK on Windows98 vs.  Debian Linux (or is it just the difference in
B> the AMD chip vs. the Pentium II or the OS? Do you have any
B> comparable machine to the Pentium II with Linux on it?)

I think there are (at least) two things.  One difference is that,
with Windows, Sun JDK 1.2.2 comes with the Symantec JIT compiler. 
The JDK (on the same machine) running Debian does not. 

Another difference is that on Windows, the dynamic linking model
(DLLs) requires objects that are fully linked.  With ELF systems (and
most Unix systems), the code in shared libraries are compiled to be
position independent code (PIC), and dynamic symbols in the various
libraries tell the dynamic linker how to pull things together at
runtime.  As a developer, Unix is a lot nicer to work with, because
you can update small groups of symbols at a time without ever running
giant, time-consuming links on the whole set.

But on Intel machines, PIC means that a (precious) register is reserved,
and performance probably suffers because of that.  (I'd build a
javaswarm.dll with PIC on Windows to test this hypothesis, but
unfortunately Cygwin's GCC disables that flag.)

Here's some data that at least confirms the first distinction:

[javaswarm StartHeatbugs -b, with HeatbugBatchSwarm.java changed to 1000
 iterations (previously 250)]

Debian 2.2:
  Kaffe 1.0.5:  67 seconds
  JDK 1.2.2:    79 seconds [without Symantec JIT]

Windows 98:
  JDK 1.2.2:    53 seconds [with Symantec JIT]
  JDK 1.2.2:    63 seconds [without, -Djava.compiler=NONE]


B> I haven't tried dealing with two VM on Linux, let alone
B> Windows. Wouldn't this indicate that it is good to keep Kaffe for
B> Swarm work and use JDK only when it is required (e.g. for
B> JBuilder)?

It may be possible to convince JBuilder to use Kaffe.  I think
JBuilder just invokes the runtime as a subprocess.  The main problem with
Kaffe is that it is weak in the AWT/Swing area.  Much easier just
to have the two runtimes around, I think.

B> The gcj stuff would only work on x86 Unix right?

gcj is a front end to GCC, and so all the existing targets that
work with C, Fortran, etc. should work.

For example:

address@hidden $ uname -a
SunOS nest 5.7 Generic_106541-04 sun4u sparc SUNW,Ultra-5_10
address@hidden $ cat Sum.java
public class Sum {
  public static void main (String[] args) {
    int sum = 0;
    
    for (int i = 0; i < 100000000; i++)
      sum += i / 10000000;
    System.out.println (sum);
  }
}
address@hidden $ cat sum.c
#include <stdio.h>

int
main ()
{
  int i;
  int sum = 0;

  for (i = 0; i < 100000000; i++)
    sum += i / 10000000;

  printf ("%ld\n", sum);
  return 0;
}

address@hidden $ gcc -O2 sum.c
address@hidden $ time ./a.out
450000000

real    0m18.881s
user    0m18.840s
sys     0m0.010s
address@hidden $ gcj --main=Sum -O2 Sum.java
address@hidden $ time ./a.out
450000000

real    0m18.144s
user    0m18.090s
sys     0m0.040s

So Java is slow, eh?

B> On the Java/ObjC point, how hard is it to mix ObjC and Java code
B> from the user perspective? It is probably just my ignorance, but at
B> the moment I'm under the impression that an Objective-C programmer
B> can not easily call Java code from his Swarm program, and in order
B> to call (user generated) Objective-C code from Java one would need
B> to go through the same process you guys went through to generate
B> stubs etc?

The FCall interface of defobj allow Java methods to be called.
FCall is like a MessageProbe, but with argument typing (FArguments). 
In the next release, these interfaces will be exposed to Java.
The main hassle with FArguments/FCall is that it is wordy to get a call
set up.  Before the next release I intend to add some convenience
constructors that will be driven from reflection info.

In order to make Objective C code visible to Java (just by loading a
jar file), it is necessary to stub its interfaces (and therefore to
declare protocols in a protocol file).  The program that does that
isn't really set up to be used outside of the build environment in
2.0.1.  That's mostly a matter of setting some elisp variables,
though, and creating a Makefile rule in your app to call the program.

I thought I would have gotten to that earlier, but to be perfectly
honest I don't have any Objective C libraries that I really care about
moving to the Java world.  Maybe some SDG members do, but I haven't
yet heard about any.  And for Fortran, C, and C++ libraries, the Swarm
Objective C protocol stubber isn't helpful, so straight Java Native
Interface (JNI) coding would be necessary, anyway.


                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.