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 92869800A4 for ; Wed, 21 Dec 2016 17:52:30 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=yotambarnoy@gmail.com; spf=Pass smtp.mailfrom=yotambarnoy@gmail.com; spf=None smtp.helo=postmaster@mail-yb0-f196.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yotambarnoy@gmail.com) identity=pra; client-ip=209.85.213.196; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yotambarnoy@gmail.com designates 209.85.213.196 as permitted sender) identity=mailfrom; client-ip=209.85.213.196; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="yotambarnoy@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-yb0-f196.google.com) identity=helo; client-ip=209.85.213.196; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yotambarnoy@gmail.com"; x-sender="postmaster@mail-yb0-f196.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3ANXT8nxeZ8Ac/r7J8iF5ATEM/lGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxc65bR7h7PlgxGXEQZ/co6odzbGH6OawAydfv97B6ClEK8McEUddyI?= =?us-ascii?q?0/pE8JPo2sMQXDNvnkbig3ToxpdWRO2DWFC3VTA9v0fFbIo3e/vnY4ExT7Mhdp?= =?us-ascii?q?dKyuQtaBx+z+7e25+oXSbgNUn3L9JOoqdFTlmz7MrdEbipdOLaM4yx2B4icZOr?= =?us-ascii?q?ce+WQ9CluZhRfx4o+L955u6SlK86Yu/sRaUKj+Ob8zTbFCAS4OPGU85cmtvh7G?= =?us-ascii?q?G1ih/HwZB1QRjhNNSyLM9hf9T9+loyzmv+930TOcOtzeQrU9WDDk5KBuHky7wB?= =?us-ascii?q?wbPiI0pTmEwvd7i7hW9Vf8/hE=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxAAAKs1pYhsTVVdFdGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBFAEBAQEBAQEBAQEBBwEBAQEBgwoBAQEBAT86dxAHpBuCNIoxijg?= =?us-ascii?q?qhXgCgVcHQhEBAQEBAQEBAQEBARIBAQEICwsJHTCCMwQBFQWCFwEFIx0BFAcQA?= =?us-ascii?q?gsBAwwGBQsNAgIJHQICIQEBEQEFAQoSBhMJCYg+AQMXDpwCP4wCggQFAR6DDQW?= =?us-ascii?q?DZgoZJwMKVIJjAQEBAQEBAQEBAQEBAQEBAQEBARcCBhJ5hSuEWYJIgWgcgniCX?= =?us-ascii?q?QWHEAyBSYccikE1hlKGcAODdIJGjguJbIQ4gkkUHoEUNYEoURKDRCCCBiA0AYc?= =?us-ascii?q?IgU8BAQE?= X-IPAS-Result: =?us-ascii?q?A0BxAAAKs1pYhsTVVdFdGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBgwoBAQEBAT86dxAHpBuCNIoxijgqhXgCgVcHQhEBA?= =?us-ascii?q?QEBAQEBAQEBARIBAQEICwsJHTCCMwQBFQWCFwEFIx0BFAcQAgsBAwwGBQsNAgI?= =?us-ascii?q?JHQICIQEBEQEFAQoSBhMJCYg+AQMXDpwCP4wCggQFAR6DDQWDZgoZJwMKVIJjA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARcCBhJ5hSuEWYJIgWgcgniCXQWHEAyBSYccikE?= =?us-ascii?q?1hlKGcAODdIJGjguJbIQ4gkkUHoEUNYEoURKDRCCCBiA0AYcIgU8BAQE?= X-IronPort-AV: E=Sophos;i="5.33,384,1477954800"; d="scan'208";a="251065882" Received: from mail-yb0-f196.google.com ([209.85.213.196]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 21 Dec 2016 17:52:09 +0100 Received: by mail-yb0-f196.google.com with SMTP id 84so1166781ybe.0 for ; Wed, 21 Dec 2016 08:52:09 -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=LR3r68szUuQKy9M6zTW8Iu9Uiye16EjnYeMR106IgTg=; b=NPdAii0Udt4je8G6FCUIVdoYyHInqvptYSkLe3dw7zF3iMe2GAwLXgVO8bCosNsZj/ IVgVb/jt3R5+kjAA61pgdC6dPxTd3U4RFML0OOP+bJyZZwSdUMgtxwzJBU2XgLIRxvaS gNyYWNWm90pCfyyTBKQCKgj+IfyeVaCkU7QMgQeoytkiwcqpnL1cLXstIFQSw4DBXEuS 8uVWVFJ6wQuXEdeOP+FhkJmP4bQ2cBsnub80z4Zx1xBUS4lNw/gvOz/iBbN7MVlog0An rhTV43vdGdrUNjFoduIjvzS1rjwFvMEM9doTTQk4GEIqMrvOdNTOj526CfJ8XoEv+phw zBQA== 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=LR3r68szUuQKy9M6zTW8Iu9Uiye16EjnYeMR106IgTg=; b=Wz2CV9vKfIaXO7nxq95O8TBJK4QeAaeestiyTZ0gH96lgn/gOZR8lZBgYJ6VmOM02y oWIfvBr5a3Z6lzQhbJ6SZ7tA0sR7EAUlWQm+Q6gJmHFxGcbEDBCH2R1iTKIFGjA3JeeP SdpwIZ6OPm1ZmlCUThrb855epTlsIZ1A+Azb+Bk82Cl3NSQpTcpCn8ooCzfx3fdYwYXo zyl0jj1+BHCyPzvainu+r8yvTAavOBAhvr1hNGBX+a8ukaIC+FoElYmC00EFEGrUNZOw +RXaJHvxRj1fZVb3vPiWQfOZAhSDaS2tTFIlT52+G4StnnQovTdPKf6ylN9vRpuJFqt1 GDuA== X-Gm-Message-State: AIkVDXKRVAG452K9Nds/FiGDC2SXOJQK5tYxCIZM/K0E4xsBcg2EBBuaL2s5c5AD7BNwrFxRw4T9mVQ5Ir6xIA== X-Received: by 10.37.64.12 with SMTP id n12mr3417497yba.92.1482339128557; Wed, 21 Dec 2016 08:52:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.18.86 with HTTP; Wed, 21 Dec 2016 08:51:48 -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: Yotam Barnoy Date: Wed, 21 Dec 2016 11:51:48 -0500 Message-ID: To: Gabriel Scherer Cc: Gerd Stolpmann , Alain Frisch , =?UTF-8?B?RnLDqWTDqXJpYyBCb3Vy?= , "Soegtrop, Michael" , =?UTF-8?Q?Christoph_H=C3=B6ger?= , "caml-list@inria.fr" Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Closing the performance gap to C Fair enough. I'm all for low-hanging fruit. On Wed, Dec 21, 2016 at 11:47 AM, Gabriel Scherer 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 > 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 > >