[Openmcl-devel] Lisp Comparison

Craig Lanning craig.t.lanning at gmail.com
Tue Apr 18 20:39:24 PDT 2017

On Tue, 2017-04-18 at 16:34 -0700, David McClain wrote:
> Hi Craig,
> There is also a lot left unstated in your presentation, e.g.,
> Delivery Level in LW, Mac ? Windows ? Linux? (I assume you are using
> Linux given the wide variety of trials, but maybe not. Maybe Mac? )

Yes, this is all done on Linux (specifically, Fedora 24).

Delivery Level 4 in LW.

> I would expect a 64-bit implementation to outperform a 32-bit
> implementation, given my own experiences with Lispworks.  Almost a
> factor of 2 in some situations. But too, you haven’t said much about
> what kind of processing you are doing, threading, how you are
> handling text, what algorithms and data structures are being used. (I
> should go look at your sources…)

The code reads the schema file and uses it to build instances for each
object in the schema: p11:schema, p11:entity, p11:type, p11:function,
p11:rule, p11:procedure, and p11:subtype_constraint.

It then takes the two schema objects and compares them using generic
functions that have methods specialized on the pair of objects being
compared.  The intent is to do a better job of comparing the two
schemata than putting the schema files through diff.  We refer to it as
an EXPRESS aware comparison.

No threads are used for this processing.  While they might be helpful,
they have not been important enough for me to spend time figuring out
how to make use of them.

> A 5:1 spread in performance is typical of what I have found when
> comparing native compiled code against interpreted byte code for the
> same algorithms. Can you be sure that all versions were fully
> compiled to native code?

Yes, all code is compiled.  No code is run interpreted.  It is designed
the way it is specifically for that reason.

The original application would read the EXPRESS schema file, translate
the declarations into Lisp and write out a .lisp file.  Then it would
turn around and read that .lisp file back in and do its job.  Aside
from being slow it had some other issues that this method was intended
to fix.

> Still, if running something like this produces results on a laptop,
> does it really matter whether it happens in 7 sec or 30 sec? Is this
> the kind of code that would be placed into continuous service and
> production? Or just something to give you some answers to chew on?

This application is a tool to help the EXPRESS Schema developers do
their job, which is the produce a new version of some ISO 10303 product
data document.  This particular comparison is to help the EXPRESS
Schema developers determine what has changed between the two compared
schema files.  In this case, two different versions of the same schema.
Also the application is capable of outputing the differences as a
specifically formatted XML file that can be included in the next
version of the standards document as a change description between the
new schema and the previous one.

Craig Lanning

More information about the Openmcl-devel mailing list