🚀 go-pugleaf

In article <260@quintus.UUCP>, ok@quintus writes:
> Version 5 of ICON (the one described in the book) had two implementations
> sharing a common front end: an "abstract instruction" version, and one
> which produced native code.  However, the book says that "a difference of
> 5% to 10%" in speed between "compiled" and "interpreted" versions was
> typical.  So the ICON group decided that it wasn't worth maintaining the
> native-code version any longer.
> 
> What I'd like to understand is why the difference was so slight.

I don't know as much about Icon implementation as I should, but my
impression (someone from the Icon project should correct me if I'm
wrong) is that 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.  Some recent research in Icon has,
in fact, been aimed at eliminating some of this redundant backtrack
point creation through static analysis.

-- 
Saumya Debray		CS Department, University of Arizona, Tucson

     internet:   debray@arizona.edu
     uucp:       arizona!debray