Re: [Caml-list] Closing the performance gap to C

[Yotam Barnoy <yotambarnoy@gmail.com>]

Fair enough. I'm all for low-hanging fruit.

On Wed, Dec 21, 2016 at 11:47 AM, Gabriel Scherer
<gabriel.scherer@gmail.com> wrote:
> I think there is an information asymmetry here. Alain has done a lot of work
> on float unboxing in old and recent OCaml releases, and if he says that some
> approach is a low-hanging fruit it is reasonable to trust him. I suspect,
> Yotam, that you have different issues in mind that correspond to the fact
> that inlining and specialization at the flambda level could be complementary
> with the work that Alain is describing.
>
> (I think it is difficult to accurately discuss these optimization questions
> at a high/conceptual level only.)
>
> On Wed, Dec 21, 2016 at 11:39 AM, Yotam Barnoy <yotambarnoy@gmail.com>
> wrote:
>>
>> On Wed, Dec 21, 2016 at 11:31 AM, Gerd Stolpmann <info@gerd-stolpmann.de>
>> wrote:
>> > Dumb question because you are effectively suggesting an alternate
>> > calling convention in addition to the existing one: wouldn't it make
>> > more sense to switch to a completely different convention? Like: we
>> > pass fp values always in fp registers so far available?
>> >
>> >
>> > Gerd
>>
>> As far as I understand, the current calling convention has to do with
>> generic functions. Having to be polymorphic over all types, including
>> primitive ones, such as floating point and ints of different widths,
>> is really difficult. This is why OOP languages don't do it -- only
>> classes are polymorphic.
>>
>> And Alain, even if we create these alternate calling conventions, the
>> tricky part is still detecting when it's ok to call using direct
>> calling conventions. That's the hard part, and it's best done by
>> Flambda with its inlining.
>>
>> -Yotam
>>
>> >
>> > Am Mittwoch, den 21.12.2016, 17:06 +0100 schrieb Alain Frisch:
>> >> On 21/12/2016 15:45, Yotam Barnoy wrote:
>> >> >
>> >> > I think it's not worth the effort. You need to examine all the code
>> >> > dealing with a parameter (ie. its flow) to see if any generic
>> >> > function
>> >> > is called on that parameter.
>> >> This would be treated a bit like the stubs for optional arguments
>> >> with a
>> >> default value.  Any function taking float arguments or returning a
>> >> float
>> >> would be compiled to a specialized version with an unboxed calling
>> >> convention plus a stub which implements the generic calling
>> >> convention
>> >> and delegate the call to the specialized version (or copy its body if
>> >> it
>> >> is small enough).  On call site, when the called function is known,
>> >> one
>> >> calls the specialized version instead.  This is a systematic, local
>> >> compilation scheme, similar to other optimizations made in
>> >> closure/cmmgen; it does not require a more global analysis nor a
>> >> radically different representation of the code.
>> >>
>> >> About the "it's not worth the effort": the effort has largely been
>> >> done,
>> >> since the ticket came with a working patch (some more effort would
>> >> be
>> >> needed to bring it up to date, though).  In my opinion, this seems
>> >> like
>> >> a rather low-hanging fruit with very immediate and significant
>> >> gains.
>> >> I'd rather have this soon than wait for flambda to become stable and
>> >> usable on large projects.
>> >>
>> >>
>> >>
>> >> -- Alain
>> >>
>> > --
>> > ------------------------------------------------------------
>> > Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
>> > My OCaml site:          http://www.camlcity.org
>> > Contact details:        http://www.camlcity.org/contact.html
>> > Company homepage:       http://www.gerd-stolpmann.de
>> > ------------------------------------------------------------
>> >
>> >
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>