[erlang-questions] native

[Kostis Sagonas]

On 09/10/2012 02:41 PM, Thomas Lindgren wrote:
>
>> I started playing with a simple implementation of MD5 (basically straight from the wiki page)
>> When the implementation produce the correct output, I did some timing for fun and also
>> tried to native compile it.
>> To my astonishment I discovered that the code was slower when native compiled.
>> I am using R15B01 on mac.  Can this be true? And in this case why?
>>
>> Note that I do not care to optimize the implementation it self! I am more interested why
>> the native compiler produce slower code on this example.

Aside: I contacted Tony privately and he is creating a 1MB binary and 
this is what I am using below:

   Bin =  << <<X>> || X <- lists:seq(1, 1024*1024) >>.


> On my Mac, the best native result 7% is faster than the best beam result. But the timing varies by 20% from run to run, so I think the proper claim is they are about the same. (I also think Hipe ought to comfortably beat Beam on this sort of code.)

I do not have a Mac, but on my i7-desktop, using vanilla R15B01 
configured with --enable-native-libs (I do not think this matters here) 
I get:

Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] 
[hipe] [kernel-poll:false]

Eshell V5.9.1  (abort with ^G)
1> Bin =  << <<X>> || X <- lists:seq(1, 1024*1024) >>.
<<1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,
   22,23,24,25,26,27,28,29,...>>
2> f(T), c(md5), {T, _} = timer:tc(md5, md5, [Bin]), T.
2050951
3> f(T), c(md5), {T, _} = timer:tc(md5, md5, [Bin]), T.
2061353
4> f(T), c(md5), {T, _} = timer:tc(md5, md5, [Bin]), T.
2086817
5> f(T), c(md5, [native]), {T, _} = timer:tc(md5, md5, [Bin]), T.
1889809
6> f(T), c(md5, [native]), {T, _} = timer:tc(md5, md5, [Bin]), T.
1865581
7> f(T), c(md5, [native]), {T, _} = timer:tc(md5, md5, [Bin]), T.
1927650

So indeed there is some fluctuation in the results, but native code 
execution does not appear to be slower in this test.

(Many other runs on the same platform basically confirm the results 
above...)


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.


> 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]}]).

Kostis