Re: objective c?

[Marcus G. Daniels]

>>>>> "PJ" == Paul E Johnson <address@hidden> writes:

PJ> I'd like it if you posted a note about the cause of the speed
PJ> difference and whether it is likely to diminish.

Broadly, there are two costs associated with the Java layer:

  1) Directory lookup costs in converting back and forth between
     Java and Objective C objects.  (Currently, it is the Objective C
     activity library that implements of the Swarm/Schedule/Action API
     for the Java layer.)  There are two improvements I've worked on so far:

       a) Make the lookups faster  (more work to be done)
       b) Extend the API so that homogeneous ForEach Actions can
          be tagged for evaluation at createEnd time, and special-cased
          for the relevant target language.  This results in speed bonuses
          for Objective C users too.
          (This is like `caching the IMP', but transparently across languages.)

     Another possibility, of course, is to write another activity library
     specifically for Java that implements the activity library API.  
     One reason we didn't do that is because we want to keep Java and
     Objective C in sync.

  2) Java bytecode interpreters (and even JIT compilers) don't result
     in code that is as fast as code compiled with native-code
     optimizing compilers (e.g. the Objective C front end to gcc).
     However, now there are native code optimizing compilers for Java
     (e.g. gcj, the Java front end to GCC). 

     I don't think stable support for gcj will be in the next release
     of Swarm, but it is appealing.  (Also appealing is the support in
     Kaffe for dynamically loading shared libraries built with gcj.)

PJ> I mean, post in the list about where you think we
PJ> might be in 6 months or 1 year in the future and how the java
PJ> thing will be.

Performance-wise, I think the Java layer (or any other languages layered on
the single-threaded Objective C activity library), might get to be 80%
as fast as Objective C models on the Objective C activity library.  To get
past that it would be necessary to unify Objective C object representations
with gcj Java/C++ object representations (major compiler hacking).  Such
a project would be way more time consuming than just re-implementing the
activity library in Java or C++.

My opinion is that, provided everything Java-wise *works* (and there is
certainly room for improvement), I don't really think it is a big deal
if it is, say, half as fast.  A longstanding goal for Swarm, is to
realize a scalable implementation of the logical concurrency model so
that events having the same time run on different CPUs in parallel.

Unless SDG members really want a singleminded focus on the problem
of making the existing virtual machine (i.e. activity library) faster with
the Java layer, my hope is that my time will be directed toward general
usability issues and on new parallelism implementation work.

PJ> When you criticize weak typing in obj-c, you are referring to the
PJ> problem that users can type things as id and programs will
PJ> compile, but runtime crashes happen when objects are sent messages
PJ> they can't respond to?

That's a big one.  The norm in Objective C is little or no method
validiation checking.  In Java the norm is that you go out of your way
to convince the compiler you know what you are doing.  And unlike C's
convention of error handling by return value, Java makes sure that
exceptions are handled in a systematic and complete way.  


                  ==================================
   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.