tags:

views:

157

answers:

5

What is the performance difference between native and bytecode Erlang modules?

A: 

Native should be faster. I don't think theres a constant factor how much faster it is; It is surely different based on machine/architecture and so on.

ZeissS
I couldn't really find much on this on the web so was wondering if I could get like a 10x speed increase on a local machine.
Zubair
I don't know any source, neither. Sorry.
ZeissS
Ok, thanks anyway :)
Zubair
+6  A: 

For code that actually does a lot of work (as opposed to spending most of its time waiting for messages or calling built-in functions), typical speedups would be between 8 and 20 times.

This also depends a lot on exactly what the code does: loops over floating point operations or manipulation of binaries/bitstrings tend to get the best speedups, while more normal tuple-and-list-manipulating code might not get more than 8-10 times faster.

Also, keep in mind that a loop compiled to native code will not be much faster if the loop body is mainly calling other modules that are not compiled to native.

(It's been a while since I looked at fresh benchmark results, but I don't think a lot has changed.)

RichardC
Have you tried this yourself?
Zubair
Once or twice. :-) (http://www.it.uu.se/research/group/hipe/people.shtml)
RichardC
Ah, yes, I assume that is a picture of you at the computer in Sweden! :) Sorry I has to ask but alot of people post on StackOverflow without having actually done what they are talking about, and simply pass on "heresay", but you seem like the real deal
Zubair
+1  A: 

There are a few correct answers already, but I think you would actually need to measure the performance of your particular functionality. If the critical region is reasonably faster than the bytecode version, there is probably still work to clean up the module to make it fail-safe.

Yes, always measure! :)
Zubair
+1  A: 

Performance-wise, HiPE optimizes within modules - not inter-module calls. This can yield very good speedups (x4..x10 appear to be commonly touted numbers), however as others have replied, if your code spends a lot of time waiting for external events the speedup will be negligible.

Something to watch out for is that HiPE apparently does NOT support some progressive language features, such as Parameterized Modules. This means that some recent applications (such as MochiWeb) will not be runnable at all. Take this into account.

Alex Arnon
+1  A: 

On a related note, you might find this paper useful:

user.it.uu.se/~kostis/Papers/erlang03.pdf

Amongst describing the limitations that arise from using HiPE, it also has some (very basic) speed comparisations.

The two things I've found most notable:

  • old HiPE code, when reloaded, does not go away, but hangs around forever. So, a small memory leak, if you are in an environment where you reload code very frequently. Usually not really a problem, but worth considering if you do not have a good "exit-strategy" for your nodes (which allows you to seamlessly take nodes out of your cluster and replace them by fresh ones from time to time--also invaluable to have when you want to upgrade to a newer BEAM-VM version.)
  • There is some overhead when switching between native and interpreted code, so you would try to avoid that when possible (by compiling all modules that interact frequently with the same compiler)
Amadiro