Smalltalk too slow?

[Martin Prange]

***@lagosantafe.com (Jim Thompson) writes:
[...]

Our company uses both Java and VW Smalltalk. Java is way slower
and bloated.

[...]

I have my complaints about Smalltalk, but speed isn't one of them.

In my opinion S# with the many different heaps toi support different object lifetimes seems
to have the finest VM anyway.

Just to be curious:

http://groups.google.de/groups?q=%22the+toll+of+garbage-collection%22&hl=de&lr=&ie=UTF-8&selm=a6efbf46.0403190010.6557eefe%40posting.google.com&rnum=1

references
http://www.geocities.com/carsten_frigaard/the_toll_of_garbage_collection.pdf,

a description of the "phonecode" example solutions measured in C# and C++, unfortunately not including S#,
(well, lets say) "proving" C# being 37 times slower for that problem.

It would be nice to have a broader comparison like http://www.hack.org/mc/texts/prechelt2.pdf ( from 2000 ),
and, to prove my (pre)conception of S#'s VM, including S# code of course.

--
Martin Prange, OO SW-Consultant, european space agency ( ESA )

[Dmitry Ponyatov]

Smalltalk may be too slow for realtime digital signal processing (DSP), or
video processing/rendering (just to mention two examples). If you are
working on such kind of projects, you probably won't need most of
Smalltalk's high-level features anyway.

In real it does not matter how slow is Smalltalk.
Smalltalk is metalanguage in roots, so use it as the metalanguage (and IDE platform).

Bind it to say LLVM (native JIT or cross-compiler to ARM) and develop a specially-dedicated managed compiler for your concrete task (DSP or distributed data crunching). If LLVM still too slow, write a model translator from some Smalltalk objects set to Verilog/VHDL.