Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!seismo!sundc!pitstop!sun!quintus!tim
From: tim@quintus.UUCP (Tim Lindholm)
Newsgroups: comp.lang.prolog
Subject: Re: Inline expansion versus threaded code
Keywords: threaded versus inline
Message-ID: <999@quintus.UUCP>
Date: 14 Apr 89 22:45:56 GMT
References: <1635@kulcs.kulcs.uucp> <8489@russell.STANFORD.EDU>
Reply-To: tim@quintus.UUCP (Tim Lindholm)
Organization: Quintus Computer Systems, Inc.
Lines: 41

lee@munmurra.UUCP (Lee Naish) writes:
>pereira@russell.UUCP (Fernando Pereira) writes:
>>soon after your program starts paging
>>you may as well forget about it

>>compact encoding is essential in that it allows us to run an
>>n times larger problem without paging (n varying from 4 to 10
>>depending on the size ratio between native compiled code and threaded
>>code)

> When I was visiting SICS over the northern winter I ran the MTS natural
> language system, written by Xiuming Huang, under Sicstus Prolog using
> the bytecode emulator and the (new) native code system.  I have to agree
> that paging really kills the system.  However, the code size factor was
> not as great as Fernando suggests in this system.  The native code
> version was between 14 and 15 Mb; the emulated system between 6 and 7 Mb
> (if I recall correctly).  Sicstus emulated code is not particularly
> compact (instructions are halfword or word aligned to speed up loading
> of instructions and operands) but I think that is true for many Prolog
> systems (eg, Quintus uses 16 bit opcodes, I've heard).

But remember that code compactness among emulated systems can also vary
widely!  While both Quintus and SICStus Prologs use a basic 16-bit opcode
when emulating, there are differences in compilation and encoding that make
Quintus' emulated code somewhat more compact than SICStus'.  (For one thing,
emulated SICStus Prolog has shallow backtracking support that is paid for by
some additional head code.)  I remember a difference of something like
50-100%, but as I don't have a SICStus 0.6 system to play with, please don't
take that number too seriously.

Would anyone at SICS (or anyone else with access to Quintus Prolog and
SICStus Prolog 0.6) be willing to compile some code and post the results?  I
would bet that they would bring SICStus' native code expansion over Quintus'
emulated code to within the factor of 4-10 that Fernando estimated.  (For
that matter, does anyone have both QP and the SICStus native code compiler
to compare directly?  Does the native code compiler do things like shallow
backtracking???)  Incidentally, that the expansion SICStus' native code over
Quintus' emulated code is probably near the low end of Fernando's range
should be taken as a source of praise, not blame!

-- Tim