[erlang-questions] divrem eep?

[Björn-Egil Dahlberg]

On 2014-08-21 12:11, Tony Rogvall wrote:
> May I suggest a two stage commit, in the good old OTP way?
>
> - First step is to implement a fairly simple bif that call the 
> functionality I really want to get
> (the remainder when doing bignum div calculations.)
>
> This includes  the work of checking special considerations with GC. It 
> works now, but
> needs more testing. As an example, I needed to blank the memory 
> between the quotient
> and the remainder in the case when both quotient and reminder where 
> both bignums.
> (It should not really be needed, but I think the debug compiled 
> emulator/gc expect everything to be super clean?)
>
> - Seconds step is to use the previous work and implement an 
> instruction that can be
> used instead of call erlang:divrem when possible. This instruction 
> needs a couple of
> variants I guess: One that return a tuple and one that store remainder in
> a X register as instructed by compiler.
>
> What about that ?

Please, not an additional BIF.

Do an optimization pass in beam-assembler to rewrite the two 
gc-bif-instructions to a single divrem instruction. Or better, yet .. 
just reorder them so you can please the loader and rewrite it in the 
load-step. No need for an additional assembly instruction in the 
compiler, just a specific instruction in the beam which is optimized 
with a load trick.

>
> :-)
>
> /Tony
>
>
> On 20 aug 2014, at 20:04, Björn-Egil Dahlberg 
> <wallentin.dahlberg@REDACTED <mailto:wallentin.dahlberg@REDACTED>> 
> wrote:
>
>> It should probably be an instruction instead.
>>
>> The compiler should recognize if div and rem is used and combine them 
>> to one instruction. You have no issue with multiple return values if 
>> you do it in core for instance. I did some doodling with this on my 
>> previous summer vacation .. along with sub-expr-elim .. I stopped 
>> after the doodling phase =)
>>
>> No eep necessary if you do it as an optimization pass, only light-eep.
>>
>> // Björn-Egil
>>
>>
>> 2014-08-20 19:41 GMT+02:00 Tony Rogvall <tony@REDACTED 
>> <mailto:tony@REDACTED>>:
>>
>>     Hi list.
>>
>>     I have been playing with a new BIF called divrem today. Calling
>>     erlang:divrem(A,B) has the the same result
>>     as calling {A div B, A rem B}. (possibly with some strange
>>     exceptional cases that remain to be found :-)
>>
>>     Since the bignum div operation has always calculated the
>>     remainder as a "waste product" I thought it was
>>     about time to pick it up and make use if it.
>>
>>     The speedup when comparing calculation of {Q,R} =
>>     erlang:divrem(A,B) and Q=A div B, R=A rem B,
>>     is about 70-80% already around 60 bit arguments (64bit platform)
>>     (max speedup is of course 100%),
>>     currently the downside is that divrem for small numbers are a bit
>>     slower, since a tuple {Q,R} is constructed
>>     and the emulator have instructions for div and rem.
>>
>>     The above could probably be handle by regarding divrem as a
>>     builtin function with a multiple return value
>>     and have the compiler to generate an instruction for some
>>     instances of divrem.
>>
>>     I remember some work for handling multiple return values?
>>
>>     What about it ? eep?
>>
>>     /Tony
>>
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> "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"
>
>
>
>
>
> _______________________________________________
> 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/20140821/45ff4cce/attachment.htm>