Re: New subject: Not writing silly slow programs.

[Marcus G. Daniels]

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

MD> One possible expense is lots of back-and-forth between Objective C
MD> and Java...

PJ> I want to know more about what you mean by this, because I'm
PJ> afraid of writing slow programs.

First and foremost, the way to write fast programs is to write
programs you can understand.  Then, you measure the programs (using
profiling, e.g. "jdkswarm -prof"), to see where time is going, and to see
if that matches with the performance characteristics it ought to have.

If it doesn't, i.e. if some function is taking a lot of time and it
doesn't make sense why, then you dig deeper and rationalize the
discrepancy between your intent and what the CPU ends up doing.  One
way to do that is to watch the code execute line by line in a debugger.
Another way is to instrument the code so that it tells you something
useful at certain points, and such that unexpected patterns will be evident.

PJ> What do you mean by "back-and-forth"? 

The activity library is written in Objective C.  An Objective C
message is like a function call that makes another C function call.
Java messages are like that too, except the arguments are different.
When the Objective C runtime can't identify a (second) function
call to make, it checks with Java to see if it knows what to do with
it (and COM too).  So, there's some extra indirection with message
dispatch that takes some time.  But even compared C++, the
dispatch costs of Objective C or Objective C with Java and COM auxiliary
backends are not big costs except in silly pathological cases.  

Now, Objective C objects hold data for an instance of a class (e.g. an
agent) and these structures have a particular physical memory layout.
The activity library is written with knowledge of this layout and that
helps with speed when it comes to to combine Agent Schedules and Swarms
and all that.

Java objects have a completely different physical layout, one that
isn't published.  So there isn't any practical way to unify Java
objects and Objective C objects.  Yet there are things in Swarm
(e.g. Schedules, Actions), that are inherently Objective C objects.

The objects that the Java user manipulates are, obviously, Java.
There are frequent cases in which you have two notions of an object.
You can have a Java facade in front of an Objective C object or a
Objective C proxy for a pure Java object.  In either case, Swarm has
to look in the `yellow pages' to figure out the peer of the other.
Although this lookup is fast, it can become a significant cost.  This
cost can be reduced by using features like ActionForEachHomogenous,
which communicate more specific intent which Swarm can use 
to avoid lots of needless lookups in the object `yellow pages'.

PJ> I'm guessing, for example, that in an agent that is a Java object,
PJ> I'd better not be making any unnecessary usage of Swarm
PJ> objects. I.e, use Java collections, and whatever else Java, rather
PJ> than subclassing Swarm Lists and such.

Use Java collections because these classes are well-documented,
complete, and well-understood by Java users, not because they might
have better performance characteristics in some cases.  For certain
kinds of operations the Swarm collections might even be faster, just
because it is native code.  Don't design programs around a performance
checklist.  Design programs around the problem they try to solve.

PJ> What else is important?

Clarity is important.  Empiricism is important.  Write your program, 
measure it, and then improve the slow parts.  Don't be neurotic about
speed when designing it unless it is clear there is something fundamentally
expensive about the computation.

PJ> Ideally, Swarm is supplying the scheduling, but nothing else?

To the extent you want the code to communicate to readers, I would say
if you write a model in Java, it is useful to follow Java idioms and
use common Java features.  Fix performance problems on a case by case
basis using profiling as a guide.

Now, suppose you study your Java Swarm model run and you identify some
method that consumes mysterious amounts of time.  Post your code.
Explain how to run the thing.  Chances are we can make it fast.



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