[erlang-questions] unpacking big/little endian speed difference

[Jan Chochol]

The difference is really in "i_bs_get_integer_32_rfId" and
"i_bs_get_integer_small_imm_xIfId".

When looking in code, the "i_bs_get_integer_32_rfId" can extract 32 bit big
endian integer from bitstring - it is quite simple function, which can not
do much more, and even has fast path for binary (bitstring with byte
boundary).
On the other side "i_bs_get_integer_small_imm_xIfId" is quite complex
function, which can extract integer with any bit size, signed, or unsigned,
little, or big endian. It is quite complex, and even use some temporary
allocated buffers.

So the reason is, that there is special "fast" opcode for extracting 32 bit
big endian integer (probably because authors of BEAM VM thought, that it
will be more useful).

On Tue, Oct 13, 2015 at 4:31 PM, Kostis Sagonas <kostis@REDACTED> wrote:

> On 10/13/2015 02:59 PM, Sergej Jurečko wrote:
>
>> How come unpacking integers as big endian is faster than little endian,
>> when I'm running on a little endian platform (intel osx)?
>> I know big endian is erlang default, but if you're turning binaries into
>> integers, you must turn them into little endian anyway, so unpacking
>> should basically be memmcpy.
>>
>> The test:
>>
>> % Takes:  ~1.3s
>> -define(ENDIAN,unsigned-big).
>>
>> % Takes: ~1.8s
>> % -define(ENDIAN,unsigned-little).
>>
>
> Well, if you are interested in performance, simply compile to native code
> your module and the time will drop to less than half...
>
> ================================================================
> Eshell V7.1  (abort with ^G)
> 1> c(endian).
> {ok,endian}
> 2> endian:loop().
> 1097971
> 3> endian:loop().
> 1327621
> 4> endian:loop().
> 1162506
> 5> endian:loop().
> 1103813
> 6> c(endian, [native]).
> {ok,endian}
> 7> endian:loop().
> 414000
> 8> endian:loop().
> 441327
> ================================================================
>
> Kostis
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151014/32d4a193/attachment.htm>