Re: Request for comment: follow-up to Summer of Code

beliavsky@xxxxxxx writes:

> Eric Lavigne wrote:
> ...
> > Maybe you are thinking about library availability rather than the
> > language itself? If so, you might find this page interesting:
> >
> > http://www.nhplace.com/kent/Papers/Fortran-to-Lisp.html
>
> At that site, comparing the Fortran code
>
> SUBROUTINE MATMUL (X, Y, IDIM)
> REAL X(IDIM,1),Y(IDIM,1),Z(100)
> DO 100 I=1,IDIM
> Z(I)=0.
> DO 200 J=1,IDIM
> 200 Z(I)=X(I,J)*Y(J,I)+Z(I)
> DO 100 J=1,IDIM
> 100 X(I)=Z(I)
> RETURN
> END
>
> to the Lisp
>
> (FORTRAN (MATMUL X Y IDIM)
> (SUBROUTINE (REAL (X 1) (Y 1) (Z 100)) (INTEGER IDIM I J))
> (: I 1)
> DO-I-100 (: (Z I) 0.0)
> (: J 1)
> DO-J-200
> /200 (: (Z I) (+$ (Z I) (*$ (X I J) (Y J I))))
> (COND ((<= (: J (1+ J)) IDIM) (GO DO-J-200)))
> DO-J-100 (: (X I) (Z I))
> (COND ((<= (: J (1+ J)) IDIM) (GO DO-J-100)))
> (COND ((<= (: I (1+ I)) IDIM) (GO DO-I-100)))
> (RETURN T))
>
> it's not obvious to me what the benefit of translation is, unless you
> just prefer Lisp (as most readers here probably do). Fortran has had
> proper loops since the 1990 standard so the numbered lines could be
> replaced with ENDDO's (Yes, 1990 was too late. Many compilers had it as
> an extension years earlier.). Furthermore, Fortran 90 added an
> intrinsic function MATMUL for matrix multiplication.

That paper was written in 1978 and should be compared in context.

Also, the point of the translation results was to show that there were
two steps that were separately managed by my translator: syntactic and
semantic. The pseudocode you quote above was something that could be
edited to include Lisp operations and variables. The translator would
apply the appropriate kinds of calls (Lisp or Fortran) to the various
functions. Lisp variables were call-by-value, Fortran variables were
call-by-reference. That part of the translation was not done by the
translator per se, but by a set of macros that the translator expected
you to use to evaluate the output of its translation and a set of
subroutines that managed the Fortran virtual machine space, doing the
Fortran equivalent of automatic storage management, etc.

The issue of speed was orthogonal to that. In fact, the translator lost
speed that native coding would not lose. On the other hand, it was
sufficiently in range that it wasn't grossly slow. And it put into the
hands of MACSYMA users (who called out to Lisp a lot) the entire IMSL
Fortran library, which was a powerful set of tools whether they were
running 100% efficiently or not.

Automatic translation is never going to be a good comparison of two
languages speedwise, and part of the point of the paper is to identify
some of the ways in which the translation made it hard to do certain
optimizations because Lisp was not optimizable in certain cases
because it worried your use of that memory was more general-purpose
than it turned out to be, and that fear of general-purpose access inhibited
certain important optimizations.

JonL White (I think it was him) wrote a paper in the same timeframe showing
how natively coded Lisp code doing numerical stuff outperformed DEC Fortran.
But benchmarks are always transitory and saying one language is better than
another is really not as interesting as saying that the languages "care" and
"try to be competitive".
.

Relevant Pages

  • Re: Freepascal rocks!
    ... I've been experimenting with a few programming languages lately: Assembler, Lisp, Forth, Smalltalk. ... A language powerful enough to simply implement another language is damn powerful. ... The other day I joked to my colleagues that we should be writing more stuff in FORTRAN; my contention being that FORTRAN doesn't really do much, so you *have* to keep things simple. ... CurRow, CurCol: Integer; ...
    (comp.lang.pascal.misc)
  • Re: FreeBSD Programming
    ... Learn Fortran 95. ... >> pursue a career in either, then Fortran 95 is the language ... Lisp is by no means just for emacs programming. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Python gets macros - now XML does too
    ... why I asked you to provide a translation of my ... >> cumbersome to implement the code generation part in another language ... You have indeed misunderstood basically _everything_ about what Lisp ... macros are and what capabilities they provide. ...
    (comp.lang.lisp)
  • Re: thoughts on dynamic from a beginners perspective
    ... working engineering and heavy duty numerical codes from Fortran to ... reason to translate good code from another language. ... mainly talked about optimizing Lisp to run faster. ... I didn't see any reason not to use Lisp. ...
    (comp.programming)
  • Re: C++ sucks for games
    ... > Hopefully he'll end up with Lisp eventually, but maybe he's happy as he is. ... In Lisp you can just integrate the custom language into the program, ... Programmers who think in Fortran tend to believe that all languages ... fingers to spit out the translation. ...
    (comp.lang.cpp)
Loading