Xref: utzoo comp.lang.prolog:1224 comp.lang.misc:1782
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!ig!agate!labrea!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.prolog,comp.lang.misc
Subject: Re: Is ICON higher level than Prolog?
Message-ID: <320@quintus.UUCP>
Date: 26 Aug 88 10:57:02 GMT
References: <6797@megaron.arizona.edu>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 52

In article <6797@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes:
>Also, I have a couple of comments to make about the previous article,
>which I didn't have time to formulate before...

Since I wrote it, I'll reply.

>(1) The article described an experiment in which a program was written
>in Prolog and in Icon, and the Prolog implementation was faster.

For heaven's sake, nobody claimed that that PROVED anything!
The experiment showed that Prolog and Icon were comparable, i.e. that
the Icon implementation wasn't doing anything outrageously bad.
Actually, it showed more than that.  The Prolog implementation in
question uses a threaded-code interpreter implemented at a low level.
An implementation in C runs about twice as fast.  The Icon implementation
is entirely in C.  Other things being equal, that should mean that Icon
could be made to go about twice as fast, but the claim was made in the
Icon books that that sort of speed-up had not been attained.

>In particular I was horrified at the description of using Icon records
>to implement linked lists.  Icon lists are a _lot_ faster than this if
>they are used right.  You have to forget the old lisp tradition of
>recursing on the cdr.

Why should you be horrified at using records for sequences?  They are
in the language, and they are supposed to be useful for that amongst
other things.  Icon does have things called lists, but they are not at
all what everyone else means by lists:  they are flex arrays.  There
are two reasons why my test code didn't use them.  (1) The code was
much clumsier, and (2) the implementation book frightened me away from
them, because the sequences were being constructed dynamically and the
space and time overheads would have been rather high.  (I'm quite
serious: I found that the space cost for a sequence made of records
would *in this case* be about half the space cost of a flex array.)

>Given (1) and (2), I don't think the speed difference can be
>attributed to inherent properties of the languages tested.

Neither do I, and that isn't what was claimed.
Not speeds, but speedUPs.
The point is that the current Icon implementation *is* comparable to
Prolog systems using similar implementation methods, but that Prolog
can be speeded up quite a bit by elementary means, and that it was
claimed *by the Icon project* that such speedups have not been obtained
for Icon.  It has been explained that 90% of the Icon time is spent in
the run-time system.  Well, that's not true for Prolog, so there we
have the explanation.  Yes, Icon *is* a higher-level language than
Prolog, in that its basic operations (replace a substring &c) are more
remote from conventional machines than the basic operations of Prolog.
If the run-time system of Icon were implemented in a lower-level
language, that might give the kind of speedup that one gets from
improving a Prolog instruction emulator.