🚀 go-pugleaf

>How much slower is that than the C++ or C version?  Timings are meaningless
>without some basis for comparison.

Well, it's sort of like comparing apples and oranges, because
the C version basically hard codes the Petri net and has
lots of direct array accesses (like Place[3].count). I think the
C compiler produces good code for direct array accesses.  However, the
C version  has no object-oriented features--mine does.

Also, the lisp version that I wrote handles marking dependent firing
rates which the C implementor admits would slow down his
system--though I don't know by how much.  Anyways, mine running in CMU
Common Lisp on a Sparcstation ELC executes about 400 transitions a
second (it's slower running in Eulisp on a Stardent).  The C version running
on a Sparcstation 2 (I don't know how much faster that is than an ELC) executes
about 20,000 transitions a second.  Note I was running a smaller petri net
simulation and it had marking dependent firing rates.  That's why I just
said that the Lisp version  is way, way, slower.


I have one of his large ones (860 transitions) that I am starting to code
now which doesn't use marking dependent firing rates.  When I finish that,
it should give a better performance comparison.

>Consider why you implemented it in Lisp in the first place.  Because
>implementing complex applications like these is more feasible with
>Lisp/CLOS than most other languages.  Perhaps you might have gotten a
>program that runs twice as fast using C++, but it might have taken twice as
>long to get it working in the first place; could you have afforded to take
>that long?  (Well, you're in academia, so there may be less deadline
>pressure than in industry, so answer as if you were in industry)

Yeah it definitely took less time to implement in Lisp.  That's why I use
it, but this is a general simulator that is to be used over and over
with different petri nets.  Thus performance becomes an issue.

As far as deadlines go, I think that for a tool that is to be used over
and over again, it is probably worthwhile to have spent more time
coding it to perform fast.  Because, there is a lot of time
lost waiting for it to execute when you are experimenting with different
Petri nets.  Yeah, I go and do other things while it's running, but
say in industry if you had to test out some Petri net designs and
had a tight deadline.  Which system would you choose?  I'm sure you would pick
the one that executed faster.

>You managed to speed it up significantly by converting your CLOS stuff to
>structures.  Lisp's strength is as a rapid prototyping language, and you've
>demonstrated that beautifully: consider the CLOS version to be the
>prototype.  If it was well designed, it probably wasn't all that hard to
>convert to a structure-based version once it was complete.  Lisp is good
>for incremental redesign like this.

That's a good point.  It only took a day to convert it to structures.

>On the other hand, many complex applications are continually being
>extended.  There's no way to guarantee exact types, and they need to stay
>in an OO language throughout their life cycle.  CLOS is excellent for this
>as well.

This is true as well, but I still think that performance should
count for something.  It just seems like C has the ability to get
tuned to run really fast and people that are experts at doing
so are very valuable.  It just seems to me that in some cases it might
make it a lot easier to justify the use of Lisp if the object system
had some tuneability to make it run fast if it was really important.

Chris