🚀 go-pugleaf

>From: debray@arizona.edu (Saumya Debray)
>
>in the old implementation, "backtrack points" were
>created most of the time, even in contexts where they weren't really
>necessary.  Given current wisdom about the cost of creating backtrack
>points, this overhead might account for the relatively small speedup
>obtained in going to native code.

Actually, in the distributed version of Icon, backtrack points are
still created where they aren't needed.  Ralph Griswold did some
measurements that indicated that the interpreter spends about 90% of
its time in the run-time system, and only 10% interpreting the icode.
Obviously, a compiler that uses the same run-time system can only hope
to improve the speed by 10% at the most.

Also, I have a couple of comments to make about the previous article,
which I didn't have time to formulate before...

(1) The article described an experiment in which a program was written
in Prolog and in Icon, and the Prolog implementation was faster.  I
don't know how much the author knows about Icon, but Icon is like
Prolog in that an experienced programmer can get a lot more
performance out of the language by knowledge of the implementation.
The Icon implementation is a lot different from Prolog
implementations, and a Prolog guru can be depended on to make a lot of
wrong assumptions about speed in Icon.

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.  Icon is a procedural language, so you should
not expect functional and logical approaches to work well in Icon.

(2) Also, the distributed version of Icon is supported as a research
project, and little of the research has gone into efficiency (until
recently).  That means that a lot more money has gone into Prolog
implementations, so Prolog has a decided advantage in that regard.

Given (1) and (2), I don't think the speed difference can be
attributed to inherent properties of the languages tested.  My own
feeling is that Icon and Prolog both fit into the same category when
you are listing languages by how "high-level" they are.  Each language
though, is much stronger than the other in particular problem domains.

					David Gudeman

					    Department of Computer Science
gudeman@arizona.edu			    Gould-Simpson Science Building
{allegra,cmcl2,ihnp4,noao}!arizona!gudeman  The University of Arizona
602-621-2858				    Tucson, AZ 85721