[erlang-questions] divrem eep?

[Tony Rogvall]

On 21 aug 2014, at 12:34, Björn-Egil Dahlberg <egil@REDACTED> wrote:

> 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. 
> 
Why not? What is the problem ?

> 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.
> 
I think one boring thing with this is that I need then to be dependent on that the compiler is smart enough to figure
this out (even if I have to implement it my self ;-)
How can a user be sure that the compiler really this optimisation? I think at least Björn G used to have 
thought about having to smart compilers ? 

/Tony


>> 
>> :-)
>> 
>> /Tony
>> 
>> 
>> On 20 aug 2014, at 20:04, Björn-Egil Dahlberg <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>:
>>> 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
>>> 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
> 
> _______________________________________________
> erlang-questions mailing list
> 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"



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