Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!nntp.sei.cmu.edu!news.psc.edu!hudson.lm.com!godot.cc.duq.edu!news.duke.edu!zombie.ncsc.mil!simtel!news.sprintlink.net!howland.reston.ans.net!torn!nott!cunews!dbuck
From: dbuck@superior.carleton.ca (Dave Buck)
Subject: Re: code optimization
X-Nntp-Posting-Host: superior.carleton.ca
Message-ID: <DG2GM2.MCH@cunews.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Organization: Carleton University, Ottawa, Canada
References: <451dig$fgq@news.ccit.arizona.edu>
Date: Sat, 7 Oct 1995 06:56:26 GMT
Lines: 60

In article <451dig$fgq@news.ccit.arizona.edu>,
Edwin Tsun <etsun@ece.ece.arizona.edu> wrote:
>There was another post on how smalltalk code is being executed.
>
>smalltalk code --> bytecode --> native code
>               
>Is optimization being done during this process like some sophisticated
>fortran compiler does? 

Some optimizations are performed on the code in the translation from
smalltalk code to bytecodes, but nowhere near the number of
optimizations performed by a sophisticated FORTRAN compiler.  The
problem is that polymorphism, dynamic binding and encapsulation make
it virtually impossible for the Smalltalk compiler to determine
exactly what's going on and how to optimize it.  For example, consider the
statement:

   a := b * 5 * 6.

A Fortran compiler would convert the "5*6" into "30".  Smalltalk can't
do this because in general, b could have been any object and it's not
clear that (b*5)*6 is the same as b*(5*6).

Fortran can optimize loop invariant code - that is, code in a loop
that does the same thing and calculates the same result each time
through the loop can be removed from the loop.

eg.
1 to: 30 do: [:i |
   x := a * 4 * 5.
   y := x + i].

A Fortran compiler can move the calculation of x outside the loop
because it knows that it has no side effects and that each time
through the loop, it will be calculated as the same value.  Again,
Smalltalk can't figure this out because it doesn't know that a is so
it doesn't know where a*4*5 can have a side effect of changing a.

Smalltalk will do optimizations of whileTrue:, ifTrue:, and a bunch of
other messages by assuming that they will never be polymorphic and
directly translating the code into Jump statements.  In general, the
methods whileTrue: and ifTrue: will never be called.

Having said all this, in general, I believe that optimizations like
those done by traditional compilers don't buy you much unless you are
being lazy with your coding.  If you code the methods more carefully,
you can achieve the same effect as the compiler optimizations.

David Buck
dbuck@ccs.carleton.ca

_________________________________
| David K. Buck                 |
| dbuck@ccs.carleton.ca         |
| The Object People             |
|_______________________________|




