<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 21 aug 2014, at 15:18, Björn-Egil Dahlberg <<a href="mailto:egil@erlang.org">egil@erlang.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2014-08-21 13:36, Tony Rogvall
wrote:<br>
</div>
<blockquote cite="mid:F0441E17-B7DC-4151-B3AA-FC24486BD460@rogvall.se" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On 21 aug 2014, at 12:34, Björn-Egil Dahlberg <<a moz-do-not-send="true" href="mailto:egil@erlang.org">egil@erlang.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=windows-1252" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2014-08-21 12:11, Tony
Rogvall wrote:<br>
</div>
<blockquote cite="mid:D354611C-F2BE-48EC-B91C-4C9F5903DE1A@rogvall.se" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
May I suggest a two stage commit, in the good old OTP way?
<div><br>
</div>
<div>- First step is to implement a fairly simple bif that
call the functionality I really want to get</div>
<div>(the remainder when doing bignum div calculations.) </div>
<div><br>
</div>
<div>This includes the work of checking special
considerations with GC. It works now, but</div>
<div>needs more testing. As an example, I needed to blank
the memory between the quotient </div>
<div>and the remainder in the case when both quotient and
reminder where both bignums.</div>
<div>(It should not really be needed, but I think the
debug compiled emulator/gc expect everything to be super
clean?)</div>
<div><br>
</div>
<div>- Seconds step is to use the previous work and
implement an instruction that can be</div>
<div>used instead of call erlang:divrem when possible.
This instruction needs a couple of </div>
<div>variants I guess: One that return a tuple and one
that store remainder in</div>
<div>a X register as instructed by compiler.</div>
<div><br>
</div>
<div>What about that ? <br>
</div>
</blockquote>
<br>
Please, not an additional BIF. <br>
<br>
</div>
</blockquote>
Why not? What is the problem ?</div>
</blockquote>
<br>
My issue is that we are already littering erts with BIFs and several
of them are probably unnecessary.<br>
<br></div></blockquote>After looking around a bit I found the following languages having a divrem / divmod build in function / operator!</div><div><br></div><div>Haskell: quoteRem, divMod</div><div><div style="margin: 0px;">Python: divmod</div><div style="margin: 0px;">Ruby: divmod</div></div><div><div style="margin: 0px;">Visual Basic: DivRem</div><div style="margin: 0px;">C#: DivRem</div><div style="margin: 0px;">C++: DivRem</div><div style="margin: 0px;">JScript: DivRem</div><div style="margin: 0px;">C: div / ldiv</div><div style="margin: 0px;"><br></div><div style="margin: 0px;">So why don't we ? </div></div><div><br></div><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<blockquote cite="mid:F0441E17-B7DC-4151-B3AA-FC24486BD460@rogvall.se" type="cite">
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000"> 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.<br>
<br>
</div>
</blockquote>
I think one boring thing with this is that I need then to be
dependent on that the compiler is smart enough to figure</div>
<div>this out (even if I have to implement it my self ;-)</div>
<div>How can a user be sure that the compiler really this
optimisation? I think at least Björn G used to have </div>
<div>thought about having to smart compilers ?</div>
</blockquote>
<br>
I think compilers should be smart and Erlangs compiler should be
smarter than it is today. I don't know why you say Björn G. is
against smart compilers. I don't presume to speak for him but he has
implemented optimization passes for bitsyntax and ref-sends for
instance, and that is kind of smart don't you think?<br>
<br>
There are of course several way one might implement a divrem
optimization. And it is an optimization and should thusly be treated
as such.<br>
<br>
Let's assume we implement an erlang:divrem/2 BIF which returns a
two-tuple.<br>
A late pass in core erlang should recognize erlang:divrem/2 and
translate it to a primop with two return values.<br>
In addition to that pass you may also have an earlier pass that
recognizes the div rem operators and translate them to a divrem BIF
so old code can benefit from this without rewriting the code.<br>
<br>
The primop will be translated to a multiple Dst beam assembly code
in v3_codegen .. and the loader just make a normal instruction for
it.<br>
<br>
The BIF will never enter into the equation unless you do apply ..
but you could implement divrem(A,B) -> {A div B, A rem B}. in the
erlang module and the optimizer would take care of it for you. You
will of course build the tuple in that case.<br></div></blockquote><div><br></div><div>A lot of arguments just to avoid a tiny BIF ! :-)</div><div><br></div><div>I think that return values from exported functions may present a small problem as well ?</div></div><div><br></div><div>-module(foo).</div><div>-export([kaka/2]).</div><div><br></div><div>kaka(A, B) -></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>erlang:divrem(A, B).</div><div><br></div><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
<br>
This whole thing reduces the divrem BIF to a placeholder, you still
need the functionality of course but it will be implemented solely
in the instruction. In other words, the BIF is unnecessary, just do
it in the compiler and implement it as an instruction.<br>
<br>
Furthermore, do away with the placeholder BIF and the pass to
rewrite the divrem to a primop. Instead, recognize the occurrences
of div rem operators and replace *them* with the primop instead.<br>
<br>
If you fear the optimization will not take, just do erlc +S and look
for it .. just like for any other compiler.<br>
<br></div></blockquote>Unless you have a language among the list above.</div><div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
But you know all this .. you are just yanking my chain =)<br>
<br></div></blockquote><div><br></div>Yes. :-)</div><div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
I say yes to a divrem optimization, it will probably help a few
libraries. We have a couple in OTP that would surely benefit from
it.<br>
I say no to a BIF since it is completely unnecessary .. especially
since it is an optimization.<br>
<br></div></blockquote><div><br></div><div>I would like it both ways. That way I and other developers know what they get when they call divrem,</div><div>in all other cases the compiler may sometimes (when sunny) optimise div and rem, to exectue a bit faster.</div><div><br></div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
// Björn-Egil<br>
<blockquote cite="mid:F0441E17-B7DC-4151-B3AA-FC24486BD460@rogvall.se" type="cite">
<div><br>
</div>
<div>/Tony</div>
<div><br>
</div>
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote cite="mid:D354611C-F2BE-48EC-B91C-4C9F5903DE1A@rogvall.se" type="cite">
<div><br>
</div>
<div>:-)</div>
<div><br>
</div>
<div>/Tony</div>
<div><br>
</div>
<div><br>
<div>
<div>On 20 aug 2014, at 20:04, Björn-Egil Dahlberg
<<a moz-do-not-send="true" href="mailto:wallentin.dahlberg@gmail.com">wallentin.dahlberg@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">It should probably be an instruction
instead.
<div><br>
</div>
<div>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 =)</div>
<div><br>
</div>
<div>No eep necessary if you do it as an
optimization pass, only light-eep.</div>
<div><br>
</div>
<div>// Björn-Egil</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-08-20 19:41
GMT+02:00 Tony Rogvall <span dir="ltr"><<a moz-do-not-send="true" href="mailto:tony@rogvall.se" target="_blank">tony@rogvall.se</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div><span style="border-collapse:separate;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px">
<div style="font-family: Helvetica;"> <span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;font-size:12px">Hi
list.</span></div>
<div style="font-family: Helvetica;"><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;font-size:12px"><br>
</span></div>
<div style="font-family: Helvetica;"><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;font-size:12px">I
have been playing with a new BIF
called divrem today. Calling
erlang:divrem(A,B) has the the same
result</span></div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif">as
calling {A div B, A rem B}.
(possibly with some strange
exceptional cases that remain to be
found :-)</font></div>
<div><br>
</div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif">Since
the bignum div operation has always
calculated the remainder as a "waste
product" I thought it was</font></div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif">about
time to pick it up and make use if
it.</font></div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif"><br>
</font></div>
<div> <font color="#333333" face="Geneva, Arial, Helvetica,
sans-serif">The speedup when
comparing calculation of {Q,R} =
erlang:divrem(A,B) and Q=A div B,
R=A rem B,</font></div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif">is
about 70-80% already around 60 bit
arguments (64bit platform) (max
speedup is of course 100%), </font></div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif">currently
the downside </font><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;text-align:-webkit-auto">is
that divrem for small numbers are a
bit slower, since a tuple {Q,R} is
constructed </span></div>
<div><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;text-align:-webkit-auto">and
the emulator have instructions for
div and rem.</span></div>
<div><span style="color:rgb(51,51,51);font-family:Geneva,Arial,Helvetica,sans-serif;text-align:-webkit-auto"><br>
</span></div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif">The
above could probably be handle by
regarding divrem as a builtin
function with a multiple return
value</font></div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif">and
have the compiler to generate an
instruction for some instances of
divrem.</font></div>
<div><br>
</div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif">I
remember some work for handling
multiple return values?</font></div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif"><br>
</font></div>
<div><font color="#333333" face="Geneva,
Arial, Helvetica, sans-serif">What
about it ? eep?</font></div>
<span class="HOEnZb"><font color="#888888">
<div><font color="#333333" face="Geneva, Arial, Helvetica,
sans-serif"><br>
</font></div>
<div><font color="#333333" face="Geneva, Arial, Helvetica,
sans-serif">/Tony</font></div>
<div><font color="#333333" face="Geneva, Arial, Helvetica,
sans-serif"><br>
</font></div>
</font></span></span></div>
</div>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a moz-do-not-send="true" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a moz-do-not-send="true" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
<div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;">
<div><span class="Apple-style-span" style="color:
rgb(51, 51, 51); font-family: Geneva, Arial,
Helvetica, sans-serif; font-size: 12px; ">"Installing
applications can lead to corruption over time. </span><span class="Apple-style-span" style="color: rgb(51,
51, 51); font-family: Geneva, Arial, Helvetica,
sans-serif; font-size: 12px; ">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"</span></div>
<div><span class="Apple-style-span" style="color:
rgb(51, 51, 51); font-family: Geneva, Arial,
Helvetica, sans-serif; font-size: 12px; "><br>
</span></div>
</span><br class="Apple-interchange-newline">
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a moz-do-not-send="true" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote>
</div>
<br>
<div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;">
<div><span class="Apple-style-span" style="color: rgb(51, 51,
51); font-family: Geneva, Arial, Helvetica, sans-serif;
font-size: 12px; ">"Installing applications can lead to
corruption over time. </span><span class="Apple-style-span" style="color: rgb(51, 51, 51);
font-family: Geneva, Arial, Helvetica, sans-serif;
font-size: 12px; ">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"</span></div>
<div><span class="Apple-style-span" style="color: rgb(51, 51,
51); font-family: Geneva, Arial, Helvetica, sans-serif;
font-size: 12px; "><br>
</span></div>
</span><br class="Apple-interchange-newline">
</div>
<br>
</blockquote>
<br>
</div>
</blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 12px; ">"Installing applications can lead to corruption over time. </span><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 12px; ">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"</span></div><div><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Geneva, Arial, Helvetica, sans-serif; font-size: 12px; "><br></span></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>