🚀 go-pugleaf

Oliver Plohmann wrote:
> 
> Jeff Sutherland wrote:
> 
> > There is a benchmark in this month's Smalltalk Report showing how a Smalltalk
> > application can be tuned to run *faster* than C.
> 
> In Smalltalk all methods are bound dynamically. No way method invocation can ever be
> faster as function invocation in C with function addresses determined at compile time.
> With some people you just can't argue that Smalltalk is slow.


Bzzzt!  Not according to the benchmarks I've done.  Go benchmark the factorial or fibonacci 
functions (implemented recursively) in both C and a good Smalltalk.  You are in for a big
surprise.  The problem is NOT that message sends are slower than function calls, but rather
that you have to do almost everything by sending a message.

The reasons that a C program may be faster than a Smalltalk program would be:

1) Numeric values can be manipulated more efficiently, both because there are neither
any function nor message sends required, and because the CPU is designed to optimize
the value-oriented representation of numeric values (the latter could be addressed
with different CPU design).

2) Much processing/data twiddling can be done by direct access into array and
structure internals without the necessity of calling functions or sending messages.

3) The compiler can perform many optimizations that rely on the fact that values 
are not encapsulated and that functions can be bound by static analysis of the
program text.

4) Smalltalk (and Java) objects are always stored on the heap, and are always
accessed by at least one level of indirection (except for SmallInteger and
Character, in the case of Smalltalk.

--Alan