[erlang-questions] native

Tony Rogvall tony@REDACTED
Tue Sep 11 09:06:19 CEST 2012


On 10 sep 2012, at 19:03, Thomas Lindgren <thomasl_erlang@REDACTED> wrote:

> 
> 
> 
> 
> 
>> ________________________________
>> From: Kostis Sagonas <kostis@REDACTED>
>> 
>> 
>> 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.

My goal with this implementation was not speed. I really wanted something simple to look at. erlang:md5 already exists, and
there is no point competing with that. I just compiled it native for fun. So do not be amazed! :-)
But as shown by kostis and others it looks like it is my computer that behaves badly, I will have a look.

Thanks

/Tony



> 
>> 
>>> Unfortunately, 'pp_native' gave broken/confusing output so it's hard to trace what happens.
>> 
>> Well, this happens because the HiPE compiler compiles in parallel by default (!).  If you want to see the native code in the non-scrambled version use:
>> 
>>     c(md5, [native, {hipe, [no_concurrent_comp, pp_native]}]).
> 
> 
> Well well, you learn something new every day.
> 
> Best,
> Thomas

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120911/e0610616/attachment.htm>


More information about the erlang-questions mailing list