[plt-scheme] xxx chooses MzScheme as preferred language

Greetings!

On Sun, 4 Jun 2006, Hans Oesterholt-Dijkema wrote:

> I understand the concern for performance and memory usage. But I've seen
> systems around that are total failure because people don't know about
> creating good algorithms. The speed of the language only becomes a major
> concern, if the application requests it and the programmers have done a
> great job on the algorihmic level.  But at that point, a performance
> increase can also simply be gotten by improving the hardware.
>
> --Hans

Implementations matter, because most algorithmic improvements can be done
in most languages (some languages may make it easier to do).  For example,
hash tables in many languages are functionally equivalent, but note that
hash tables in C/C++ are usually _much_ faster than hash tables in Scheme,
and not much can be done to improve this without redoing the compiler and
memory models.

An area in which C/C++-like languages shine is the use of stack
allocations/deallocations and the use of block mallocs/frees for
manipulating data structures, allowing wholesale removal of values for
minimal cost. Lack of regional allocation in Scheme, combined with no
ability to use stack semantics even when you are not using continuations
and are simply returning values, means garbage collection becomes a prime
issue (we ran into this one when doing XSLT transformations, as each node
needed to be allocated/collected separately, whereas in C/C++
implementations, the known lifetimes of intermediate trees allowed for
large blocks of mallocs/frees - we were observing 40% of the CPU
utilization dedicated to garbage collection). This example is not simply
an "algorithmic change", and would require large changes in most Scheme
implementations to be able to achieve these optimizations/models as you do
not have access to pointers (unless you count delving into the Scheme
implementation as an algorithmic change for the application) (or unless
you are willing to accept jumping into C code as an acceptable
alternative, but then most foreign-function interfaces are not really that
nice to use and I'd rather stick to the better language).

If a person cannot write a good algorithm, using MzScheme will not
easily fix that. We are really discussing good quality programmers who
know how to extract value out of their tools, and so the algorithmic
argument cannot really be used as a reason not to have performance.

One project we have is creating a new database engine, and MzScheme is not
even on the radar as a possible implementation language. We are already at
the limits of hardware, and taking a 10x-100x hit on performance is just
not available to us. And there are a large number of projects in similar
positions. As an extreme example, when some groups need to embed the web
server in the kernel to avoid context switches because of overhead, you
know you are dealing on the edge of performance requirements.

Regards!
Ed