Mon Sep 10 22:44:23 CEST 2012
----- Original Message -----
> From: Thomas Lindgren <>
>> From: Kostis Sagonas <>
>> I do not know why Thomas thinks that HiPE should be able to confortably beat
> BEAM on this sort of code (care to elaborate?). From a brief glance it seems to
> me that the code spends a lot of time in BIFs written in C (most notably
> list_to_tuple/1 and element/2, but also trunc/1, abs/1 and math:sin/1. All of
> these are outside the reach of the native code compiler.
> The regular MD5 algorithm is basically a loop doing lots of integer arithmetic
> and bit operations as well as accessing a few arrays. This ought on the face of
> it to be quite amenable to native code compilation. I'm amazed that the
> implementation Tony used managed to get trunc/abs/sin into the inner loop, but
> that might as you say well explain the problem.
After some thinking, it might also be interesting to see the effect of more BIFs getting optimized in Hipe. The result in this case would of course still be unlikely to be competitive with an efficient MD5, but doing so might gain some performance. So, list_to_tuple/1 could expand to an RTL loop, trunc/1 and abs/1 could be expanded to simple code (esp. with a float argument), etc. (Element/2 already gets optimizer attention but it seems not to help here.) Give the compiler more to work with.
More information about the erlang-questions