From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 15842800A3 for ; Wed, 21 Dec 2016 17:48:29 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=gabriel.scherer@gmail.com; spf=Pass smtp.mailfrom=gabriel.scherer@gmail.com; spf=None smtp.helo=postmaster@mail-io0-f193.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.193; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.193 as permitted sender) identity=mailfrom; client-ip=209.85.223.193; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-io0-f193.google.com) identity=helo; client-ip=209.85.223.193; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-io0-f193.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AwX9gpxyXMgFXt77XCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?0ekfIJqq85mqBkHD//Il1AaPBtSAraIewLWI++C4ACpbvsbH6ChDOLV3FDY7yu?= =?us-ascii?q?wu1zQ6B8CEDUCpZNXLVAcdWPp4aVl+4nugOlJUEsutL3fbo3m18CJAUk6nbVk9?= =?us-ascii?q?Dq3PF4XTl8W60fyps92WOl0QxWmLWq5pNBi9sSnWs8AXh8MidvdwmVP1pS55fP?= =?us-ascii?q?hfwCtCLEiVmAe0sta34Jdm+S1KvfUw38FFWKT+Oa8/SOoLIi4hNjUa7cfxtBTH?= =?us-ascii?q?BTCE5nYGX39exhVBCRLE4RW8RZzxvzH3rMJy3SCbOYv9SrViCmfq1LtiVBK90H?= =?us-ascii?q?RPDDU+6myCz5EpgQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AAC2sVpYf8HfVdFdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBFAEBAQEBAQEBAQEBBwEBAQEBgwoBAQEBAXl3EAeBNqJlgjSKMYo?= =?us-ascii?q?4KoV4AoFXB0IRAQEBAQEBAQEBAQESAQEJCwsJGzKCMwQBFQWCFgEBAQMBIx0BF?= =?us-ascii?q?AcQAgsBAwELBgMCCw0NHQICIQEBEQEFAQoSBhMJCYg+AQMPCA6KdZELP4wCggQ?= =?us-ascii?q?FAR6DDQWDZwoZJwMKVIJjAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQIGEoYkhFmCS?= =?us-ascii?q?IFoHCGCV4JdBYcQDIFJhxyKQTWBeoRYhnADg3SCRo4LiWyEOIJJFB6BFA8mgSh?= =?us-ascii?q?REoMYLIImIDQBhwiBTwEBAQ?= X-IPAS-Result: =?us-ascii?q?A0A5AAC2sVpYf8HfVdFdGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBgwoBAQEBAXl3EAeBNqJlgjSKMYo4KoV4AoFXB0IRA?= =?us-ascii?q?QEBAQEBAQEBAQESAQEJCwsJGzKCMwQBFQWCFgEBAQMBIx0BFAcQAgsBAwELBgM?= =?us-ascii?q?CCw0NHQICIQEBEQEFAQoSBhMJCYg+AQMPCA6KdZELP4wCggQFAR6DDQWDZwoZJ?= =?us-ascii?q?wMKVIJjAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQIGEoYkhFmCSIFoHCGCV4JdBYc?= =?us-ascii?q?QDIFJhxyKQTWBeoRYhnADg3SCRo4LiWyEOIJJFB6BFA8mgShREoMYLIImIDQBh?= =?us-ascii?q?wiBTwEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,384,1477954800"; d="scan'208,217";a="251065330" Received: from mail-io0-f193.google.com ([209.85.223.193]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 21 Dec 2016 17:48:27 +0100 Received: by mail-io0-f193.google.com with SMTP id j76so1994352ioe.0 for ; Wed, 21 Dec 2016 08:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/dVYvkjxpioxuea+SpGj+m6Jxf+kDKUH0xNsdBZFwr4=; b=PnPXgdLSX/YovqdyWMZv7y0eQbxDB3R/Kj2gEKuYXqBcOS/mE8xtevFTHrs9XxlGAP 957mZA5Ki5fwG8lO3jisakr+FV1HY1sA2Fln6gVWdEnLTehHXvON8LwfjS8JJ2fHEwGD v2bnk9ssVWIgNvGwYGTnQ0HgHxtRJ8eqzgHQmuX2PZRNMsSYMgF3skCm/kAfjOKmIhey BQjXTTmLeu2QrD1VlnpaOeXRf2AP4h9d06ipVZSl1BtkUyLh88mjaeB5XvG0CwamPtZH 4HxjRyeCZLFN4nSJ8HqKxGP/m+7jHtZQ15eeHcVApU4myvN8mp+E/ZY5OKqcdkMVCSU/ sxIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/dVYvkjxpioxuea+SpGj+m6Jxf+kDKUH0xNsdBZFwr4=; b=d2+QHch5QePcPZuhqH304qUphZpBHdoifGgkvveiUfVsnDuktqahCHQdez6oCOkLS3 0DQ1InV5pe1krO2DBNLIQvvSbW2oIpO7pEIc/NNYOlcCLVC8PWbGNbZmg01vmprL1TqT K4XfSuj3AtICvRjQsIk8Dv1gbsUJSLLER2d6AxF8qdm1AnaZdHQlGXc4wGEB38W70D/m xb+myYGkDgddHFqyX0zku8fXoz9IqOJ5z2pB5/O8YjG6ak+KX24wZYD17M9MJ4SjBTUl x/RmltXF45dgXWoXUXr/MmtXoEs2OpH29uLwLRm5NyG2e3TcCg6yJGhJoAp4VWldPwRV 2FQA== X-Gm-Message-State: AIkVDXLTnTzLVaADHFkwlDg9/zUUy/DIdnoOfXlMfEinRhiUDcVOeuZRLHdCJ/j9U7IOCBDzLKdPCwn1dobbKA== X-Received: by 10.107.2.210 with SMTP id 201mr5946937ioc.67.1482338905975; Wed, 21 Dec 2016 08:48:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.140.195 with HTTP; Wed, 21 Dec 2016 08:47:45 -0800 (PST) In-Reply-To: References: <7bc766a2-d460-524b-35ca-89609a34b719@tu-berlin.de> <1482148297.4629.19.camel@gerd-stolpmann.de> <0F7D3B1B3C4B894D824F5B822E3E5A172CFB9581@IRSMSX102.ger.corp.intel.com> <1482165686.4629.28.camel@gerd-stolpmann.de> <1506c421-618a-28d4-9a7b-7ba49baf47fa@lexifi.com> <45f9251b-c362-ac9f-fa71-07ab42087c90@lexifi.com> <1482337872.4629.108.camel@gerd-stolpmann.de> From: Gabriel Scherer Date: Wed, 21 Dec 2016 11:47:45 -0500 Message-ID: To: Yotam Barnoy Cc: Gerd Stolpmann , Alain Frisch , =?UTF-8?B?RnLDqWTDqXJpYyBCb3Vy?= , "Soegtrop, Michael" , =?UTF-8?Q?Christoph_H=C3=B6ger?= , "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a113a00beed7a8605442deb0c Subject: Re: [Caml-list] Closing the performance gap to C --001a113a00beed7a8605442deb0c Content-Type: text/plain; charset=UTF-8 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 wrote: > On Wed, Dec 21, 2016 at 11:31 AM, Gerd Stolpmann > 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 > --001a113a00beed7a8605442deb0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 lev= el could be complementary with the work that Alain is describing.

(I think it is difficult to accurately discuss these optimization quest= ions at a high/conceptual level only.)
=
On Wed, Dec 21, 2016 at 11:39 AM, Yotam Barn= oy <yotambarnoy@gmail.com> wrote:
On Wed, Dec 21, 2016 at 11:31 AM, Gerd Stolp= mann <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 ma= ke
> 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 al= l 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<= br> >> with a
>> default value.=C2=A0 Any function taking float arguments or return= ing 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).=C2=A0 On call site, when the called function is = known,
>> one
>> calls the specialized version instead.=C2=A0 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 ha= s largely been
>> done,
>> since the ticket came with a working patch (some more effort would=
>> be
>> needed to bring it up to date, though).=C2=A0 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 stab= le and
>> usable on large projects.
>>
>>
>>
>> -- Alain
>>
> --
> ------------------------------------------------------------
> Gerd Stolpmann, Darmstadt, Germany=C2=A0 =C2=A0 gerd@gerd-stolpmann.de
> My OCaml site:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.camlcity.org=
> Contact details:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.caml= city.org/contact.html
> Company homepage:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.gerd-stolpma= nn.de
> ------------------------------------------------------------
>
>

--
Caml-list mailing list.=C2=A0 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

--001a113a00beed7a8605442deb0c--