caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yotam Barnoy <yotambarnoy@gmail.com>
To: Gerd Stolpmann <info@gerd-stolpmann.de>
Cc: "Alain Frisch" <alain.frisch@lexifi.com>,
	"Frédéric Bour" <frederic.bour@lakaban.net>,
	"Soegtrop, Michael" <michael.soegtrop@intel.com>,
	"Christoph Höger" <christoph.hoeger@tu-berlin.de>,
	"caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Closing the performance gap to C
Date: Wed, 21 Dec 2016 11:39:29 -0500	[thread overview]
Message-ID: <CAN6ygOkPX=ubw-J9dBMiBaY1Ur+Hh2Q1wfNU2wOuJzFXm-djfw@mail.gmail.com> (raw)
In-Reply-To: <1482337872.4629.108.camel@gerd-stolpmann.de>

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
> ------------------------------------------------------------
>
>

  reply	other threads:[~2016-12-21 16:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-17 13:01 Christoph Höger
2016-12-17 13:02 ` Christoph Höger
2016-12-19 10:58   ` Soegtrop, Michael
2016-12-19 11:51   ` Gerd Stolpmann
2016-12-19 14:52     ` Soegtrop, Michael
2016-12-19 16:41       ` Gerd Stolpmann
2016-12-19 17:09         ` Frédéric Bour
2016-12-19 17:19           ` Yotam Barnoy
2016-12-21 11:25             ` Alain Frisch
2016-12-21 14:45               ` Yotam Barnoy
2016-12-21 16:06                 ` Alain Frisch
2016-12-21 16:31                   ` Gerd Stolpmann
2016-12-21 16:39                     ` Yotam Barnoy [this message]
2016-12-21 16:47                       ` Gabriel Scherer
2016-12-21 16:51                         ` Yotam Barnoy
2016-12-21 16:56                         ` Mark Shinwell
2016-12-21 17:43                           ` Alain Frisch
2016-12-22  8:39                             ` Mark Shinwell
2016-12-22 17:23                             ` Pierre Chambart
2016-12-21 17:35                       ` Alain Frisch
2016-12-19 15:48     ` Ivan Gotovchits
2016-12-19 16:44       ` Yotam Barnoy
2016-12-19 16:59         ` Ivan Gotovchits
2016-12-21  9:08           ` Christoph Höger
2016-12-23 12:18             ` Oleg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN6ygOkPX=ubw-J9dBMiBaY1Ur+Hh2Q1wfNU2wOuJzFXm-djfw@mail.gmail.com' \
    --to=yotambarnoy@gmail.com \
    --cc=alain.frisch@lexifi.com \
    --cc=caml-list@inria.fr \
    --cc=christoph.hoeger@tu-berlin.de \
    --cc=frederic.bour@lakaban.net \
    --cc=info@gerd-stolpmann.de \
    --cc=michael.soegtrop@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).