[clean-list] Matrices, memory and efficiency

[Jerzy Karczmarczuk]

Siegfried Gonzi wrote about matrices and efficiency:

...
> Why can Yorick manage memory so much better? Yorick itself is only a
> interpreter (but Fast Fourier and all array manipulations are 
> build in functions, and they have compiled speed). I want not
> discuss here which is better Yorick or Clean, but I cannot
> understand why Yorick manages memory better, because Yorick only
> "interprets" code and Clean compiles code to stand-alone native
> PowerPC code.

John van Groningen answers the questions related to Clean.
I only add:

But an interpreter usually *can* provide for a more performant
memory management system than a compiled package with the run-time
compiled separately. It the latter case the addressing is more often
indirect, more registers to save (blindly), etc.

A garbage collector in a monolithic system may be much more 
efficient than a "plug-in" GC attached to the run-time
of a compiled language.
====

>From another posting:

> I was (first) impressed by Forth, because there are a physicist 
> who claims for Forth. He also often writes articles about Forth 
> (the last was in the peer-reviewed magazine: "Computing in 
> Science and Engineering", Sep./Oct. 2000, p. 6ff, from J.Noble.").

> And I often red that some people want to get people from Fortran90
> to Forth. Oh, Oh, Forth is slow and slow. For example a tuned 
> (with subarray tricks) matrix-matrix-multplication takes 3 to 4
> times longer than the multiplication with Clean.

Forth is based on a (relatively) fast threaded code interpreter
which might be quite competitive if a program spends most of
its time within its compiled, basic procedures. (That's why
PostScript is not as bad). Also, when the user program is
able to manipulate manually (uygh, can you manipulate with
your feet?...)
the system stack. Highly tuned postix code efficient very be may,
but natural it not is, and people crazy go makes.

I see no sense in comparing the speed of interpreted and compiled
languages, unless the compilation is for a similar virtual
machine, or if you are a prophet trying to convince people that
interpreters are not as bad as that.

On the other hand, the threaded code paradigms are really very good
as the interpreter building techniques, and they seem to be well
adapted for the implementation of functional languages. The
Haskell STG machine is a kind of threaded machine.



Jerzy Karczmarczuk