HIPE'd stdlib modules rule !!!
Wed May 28 00:32:13 CEST 2003
On Tue, 27 May 2003 12:23:28 +0200 (MEST)
Kostis Sagonas <kostis@REDACTED> wrote:
> 1. The way the Erlang/OTP Makefiles work, the only safe way to make
> a library of the system is to touch the corresponding files and
> then issue a "make" command at the top-level. This will generate
> the appropriate header files (hipe_literals.hrl in this case).
Ah, thanks. I would then have to re-'make install'?
I've grown so used to 'erlc -o ebin src/*.erl' that it didn't occur to
me that the base system might need more delicate handling.
> 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, ...)
ets, yes, but ets.beam was recompiled +native as part of stdlib.
> that you have
> not compiled to native and you get penalized by mode switches?
Only http that I can think of, and that's only used once at startup.
> Is this using R9B, and on which platform?
R9B-1, on FreeBSD 4.8-STABLE (Apr 21 2003)
> > Anyway, my feeling is that judicious use of +native is probably a
> > better way to go than just compiling everything with HiPE
> > ("+naive"? :)
> Judicious use beats naive use of everything hands down, so I could not
> agree more with the above. However, my experience is that it is very
> easy to have the illusion that "everything" was compiled to native
Perhaps I should bang together a script to :module_info all the modules
it can find and say which ones aren't +native?
Erik Stenman mentioned that one reason could be the extensive use of
dynamic dispatching in the storage behaviour (calls in the form
Module:function(...)) I also suspect its performance just depends too
heavily on message passing. When I get some spare time I'll rewrite it
to eliminate the dynamic dispatching and turn the primary message
passing-reliant thing into function calls. I'm sure I'll get better
Meanwhile - with 'all' (most) of kernel+stdlib HiPE'd, common things
like using the shell, compiling, etc, do seem a little more sluggish
than normal, so it's not just this app...
More information about the erlang-questions