HIPE'd stdlib modules rule !!!

[Thomas Lindgren]

--- Kostis Sagonas <kostis@REDACTED> wrote:
>  > Clearly, not what I expected.  Looking at the
> pibfi code, it may be
>  > that, even though it 'looks' sequential, it just
> relies on message
>  > passing too much (between the interpreter and the
> store, etc.)
>  >
>  > On the other hand - everything still worked; the
> output was correct.
> 
> Without knowing more about your application, it is
> very difficult to
> say something intelligent here.  Can it be that your
> application is
> also heavily using other parts of OTP 9e.g. ets,
> ...) that you have
> not compiled to native and you get penalized by mode
> switches?

Some more thoughts on this.

First, if the program spends its time doing ets
operations, message passing and other stuff already
done in C, then native code compiling the Erlang parts
clearly won't help much. Amdahl's law ensures that.

Furthermore, it is possible that things could even get
worse from doing so. Consider when the extra native
code also produces extra cache misses (that are not
tolerated). This is a classic problem, and when it
occurs a bytecoded VM might be quite competitive.

We experienced precisely that with an older version of
Beam vs an ancient version of Hipe used on AXD301,
running on an UltraSparc.

The current Hipe appears to have evolved quite a bit
since then, as has Beam -- not to mention that the
underlying platform may be quite different. So I won't
say this is the problem. (Being "BIF bound" might be a
likelier culprit, from what it sounds like.) But if
you have a big program that doesn't behave, I think
it's definitely a factor to consider.

(Those interested in "the AXD301 experience" can
consult 
<http://www.docs.uu.se/astec/Reports/Reports/9903.ps.gz>
)

Best,
Thomas


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com