Re: Matrix Multiplication

[Brian Rogoff <bpr@shell5.ba.best.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2131 bytes --]

On Thu, 16 Dec 1999, Pascal Obry wrote:
> Robert A Duff <bobduff@world.std.com> a écrit dans le message :
> wcchfhkxjeg.fsf@world.std.com...
> > I do.  A fast language is one for which it is feasible to build
> > compilers that generate fast code.  A slow language is one for which
> > that is not feasible.
> 
> I pretty well understand that, but we are then talking about implementation
> in a compiler.
> 
> > Also I prefer to put the burden of proof on the language advocates --
> > that is, a language should be considered "slow" until proven "fast" by
> > the existence of at least one good production-quality compiler.
> >
> > By this definition, Smalltalk, for example, is slow -- I've never seen a
> > Smalltalk compiler that can generate fast code.  Furthermore, it seems

I like Bob Duff's definition, though it probably needs a bit more
elaboration. A few years ago Richard O'Keefe posted some interesting 
microbenchmarks to comp.lang.ada comparing Pascal, Scheme, and Ada 
programs for two dimensional integration using downward funargs, with the 
(GNAT) Ada code using generics to simulate this. The Scheme code was the
fastest. The Scheme compiler was an aggressive whole-program optimizer 
called Stalin. Despite the success of this microbenchmark, and Stalin, I 
suspect that Scheme would be classified as a "slow" language, like
Smalltalk, this compiler not proving itself "production quality" yet.  
So what's the litmus test for being production quality?

> Ok, we have never seen one, but is it really impossible ? I do remember
> something about IBM creating a Smalltalk compiler, is that true ? How
> fast was it ?

You can create compilers for any language. However, Smalltalk keeps a lot
of info around at runtime, so for example, when doing integer arithmetic 
you get transparent overflow into bignums if you need them. That costs!

If your Smalltalk were to make each element of a float or complex array a 
self identifying (tagged) object then I guarantee you Smalltalk numerical 
linear algebra will run much slower than Fortran or Ada!

-- Brian