Integer micro-benchmarks [Smalltalk Multi-Precision Numerics vis-a-vis Highly Optimized Fixed Size Integer C++ Numerics]

[David Simmons]

"Andrea Ferro" <AndreaF at UrkaDVD.it> wrote in message
news:9caaru$75k$1 at serv1.iunet.it...
> "David Simmons" <pulsar at qks.com> wrote in message
> news:unqF6.19479$Jh5.19552912 at news1.rdc1.sfba.home.com...
> >
> ...
> > Better still for our true testing purposes of raw numerics performance,
what
> > a hand coded assembly routine would do. I probably should hand code an
> > assembly version since I'm really expert in that area and issues of
> > pipelining -- I have often had to do this for small hot-spot areas where
a
> > C++ (or other static language) compiler just wasn't satisfactory.
>
> There's not much data cache work involved here. It's most register stuff.
And
> code is so tiny that should go to cache at first pass.

My comment here had more to do with looking at pipelining (instruction
scheduling) issues and ensuring that we really tested similar numerics
rather than invariant optimizations. As you say, the instruction and data
caches are basically irrelevant to the c++/assy code.

The comments regarding the instruction and data caches were for the
10,000,000 case which generated LargeInteger values in Smalltalk and
therefore invoked many other parts of the execution engine (possibly
including one or more aspects of the automatic garbage collector
facilities).

...snip interesting stuff...

> Fiew years ago I heard rumours of experiments to add some sort of type
awareness
> to Smalltalk. Now, making smalltalk statically typed is a nonsense. But
> *allowing* type specification of parameters, return types and some other
> semantic aids (like the concept of constness to indicate a method is not
> supposed to modify the object) could maybe enable very optimized
execution. What
> is the *current* smalltalk community position on this sort of reasoning.

You're probably referring to StrongTalk? Or you may be referring to early
information regarding my work on SmallScript?

In any case, as I understand it, StrongTalk was not designed with the goals
you're describing.

SmallScript's intrinsic type system does enable those goals and can make
extensive use of optional type information. The type system is formalized
and integrated in with the language (including the mixin/MI interface
system). As a result the type system enables transparent FFI marshalling,
overloaded methods (multi-methods), etc.

> /DisclaimerOn
> I do not want to start a flame on this. I'm not suggesting in any way that
> Smalltalk should be typed. I'm just asking what reasoning is behind NOT
even
> allowing that sort of meta information. Smalltalk now has namespaces and
parcels
> and protocols and other usefull stuff that was no-no for Smaltalkers in
the
> past. An *optional* meta info that tells to the JIT and to the compiler
that a
> method has no side effects or that it returns an object guaranteed to be
of a
> given class should not actually change the language. Or does it?
> /DisclaimerOff

...snip more interesting comments...

> hmmmm I'm still to keep up with Smalltalk "news". I'll take self some time
in
> the future. I told you, no matter how much I like this sort of languages I
> couldn't yet "sell" their use here in Italy. But maybe that's because I'm
doing
> too much embedded stuff!

Actually, its interesting you should say that. A 4:1 performance ratio for a
worst case numerics scenario is not indicative of general performance. I
would suggest that general purpose code on that same architecture would
perform roughly equal to C++.

Certainly the object allocation and GC would exceed performance of
non-auto-(stack)-objects. The adaptive nature of the JIT enables optimizing
various constructs that a static compiler could not.

But most important of all is that an virtual machine opcode instruction set
is *much* more compact in memory than statically compiled code and therefore
it should be possible to support significantly more (easily upgradable)
functionality in the same memory footprint. A dynamic language architecture
allows restructuring of classes (objects) and their behavior on the fly
without ever quitting an application -- that and many other dynamic language
features are quite attractive for mobile computing, agent technology,
factory automation systems, and data collection and processing facilities.

...snip more interesting stuff...

Cheers,

-- Dave S.

>
> Andrea Ferro
>
> ---------
> Brainbench C++ Master. Scored higher than 97% of previous takers
> Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
> More info http://www.brainbench.com/transcript.jsp?pid=2522556