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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 0BD17800B6 for ; Fri, 23 Dec 2016 13:18:30 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=oleg@okmij.org; spf=Pass smtp.mailfrom=oleg@okmij.org; spf=None smtp.helo=postmaster@mail1.g3.pair.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oleg@okmij.org) identity=pra; client-ip=66.39.3.114; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of oleg@okmij.org designates 66.39.3.114 as permitted sender) identity=mailfrom; client-ip=66.39.3.114; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="oleg@okmij.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail1.g3.pair.com) identity=helo; client-ip=66.39.3.114; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oleg@okmij.org"; x-sender="postmaster@mail1.g3.pair.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AlzSbfx/+7vPjdv9uRHKM819IXTAuvvDOBiVQ1KB4?= =?us-ascii?q?0e4cTK2v8tzYMVDF4r011RmSDN6du60P0bKempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9ZDeZwtFiCC+bL5wIxm6sxndvdQKjIV/Lao81gHHqWZSde?= =?us-ascii?q?RMwmNoK1OTnxLi6cq14ZVu7Sdete8/+sBZSan1cLg2QrJeDDQ9LmA6/9brugXZ?= =?us-ascii?q?TQuO/XQTTGMbmQdVDgff7RH6WpDxsjbmtud4xSKXM9H6QawyVD+/6apgVR3mhz?= =?us-ascii?q?odNzMh/m/ZitJ+gr9Yrh2uuxNw3ozbb4+OOfpiYq/QZ88WSXZbU8pPUSFKH4Oy?= =?us-ascii?q?b5EID+oEJetWto39qEUBrRCjAgSsA+fvxSFHhnLt2q060OEhEQDE3AA6GNIOqn?= =?us-ascii?q?vUoczzOawPX+61y6zIwi/Cb/NQwTr96Y7Icgogof6WR75wf9DRxVEuFwzZlFmf?= =?us-ascii?q?s5DqMymI1uQOtWWQ8uluVfq3hmMmqgx9uDaiy8M2hoTHnI4Z103I+CphzIooK9?= =?us-ascii?q?C0VFR3bNCrHZdKqi2XM5V6TtksTmxnvisx16cItoShfCcQzZQq3x7fZOKDc4iP?= =?us-ascii?q?+h/jUfyeITZ8hH54Yr6/iBi//VK4yuLmV8m0ykxGoTZCktnJrnwN1hrT5dabSv?= =?us-ascii?q?Zl/0qs2CyD2g7X5+1eL004j7fXJ4Muz7Iok5ocq0XDHiv4mEXsi6+Wc10p+u+s?= =?us-ascii?q?6+v5bbXrvZicN4xxigH/MKQigMu/Af43MgQWRWiU5fy81KH//U3+WLhFkuc5kq?= =?us-ascii?q?zdsJzDIcQbp7W5AxNO34Y46xe/Ci+m384CkXkGKlJFYhOHgJLzN1HAOvCrRcu4?= =?us-ascii?q?1l+sijZw2/fePvvhBZjCI2LrjKqkd7tn709ajgY+nv5F4JcBLbUML7qnXUv8u/?= =?us-ascii?q?TfDRo4MUqz2emxW4Y17Z8XRW/aWvzRC6jVq1Ldvu8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CIAADMFV1Yh3IDJ0JeFgQBAQEBAgEBA?= =?us-ascii?q?QEIAQEBARUBAQEBAgEBAQEIAQEBAYMMAQEBAQF8gQmNU3KqdoIJLIV2AoF0PxQ?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEKCwkJHTCCMxiCHgQCOi0FDRshNAVwB4hUDq4fiwEBC?= =?us-ascii?q?yaGR4NcgQeFFoJlgjAFkACKeoJNjmINgXWBU4M2g0qGDJI8H4FiLoN5gXdjAQG?= =?us-ascii?q?JBgEBAQ?= X-IPAS-Result: =?us-ascii?q?A0CIAADMFV1Yh3IDJ0JeFgQBAQEBAgEBAQEIAQEBARUBAQE?= =?us-ascii?q?BAgEBAQEIAQEBAYMMAQEBAQF8gQmNU3KqdoIJLIV2AoF0PxQBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEKCwkJHTCCMxiCHgQCOi0FDRshNAVwB4hUDq4fiwEBCyaGR4NcgQeFFoJ?= =?us-ascii?q?lgjAFkACKeoJNjmINgXWBU4M2g0qGDJI8H4FiLoN5gXdjAQGJBgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,393,1477954800"; d="scan'208";a="205669281" Received: from mail1.g3.pair.com ([66.39.3.114]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2016 13:18:15 +0100 Received: from Magus.localnet (g.sf.ecei.tohoku.ac.jp [130.34.192.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.g3.pair.com (Postfix) with ESMTPSA id D3BAB3FBBE7; Fri, 23 Dec 2016 07:18:10 -0500 (EST) Date: Fri, 23 Dec 2016 21:18:01 +0900 From: Oleg To: christoph.hoeger@tu-berlin.de Cc: ivg@ieee.org, yotambarnoy@gmail.com, caml-list@inria.fr Message-ID: <20161223121801.GA4938@Magus.localnet> Mail-Followup-To: Oleg , christoph.hoeger@tu-berlin.de, ivg@ieee.org, yotambarnoy@gmail.com, caml-list@inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Subject: Re: [Caml-list] Closing the performance gap to C > @Ivan: Your point about the optimization is well taken, but please > consider that the runge-kutta integrator is a sophisticated, general > numerical method. Usually, the user of such a method has neither the > knowledge nor the time to manually adapt it, but rather implements a > standard interface. Therefore, the unused arguments and > algebraic/trigonometric identities have to be resolved by the compiler. > Otherwise, we could as well compute the exact solution, anyways ;). I would like to concur with Ivan and to strongly emphasize his point. This discussion about compiler optimizations has been done before -- decades before -- in the HPC community. We know the conclusion: the era of compiler optimizations is over. All further gains in HPC computing can only be expected from *domain-specific* optimizations, specific to a particular domain. Because the most profitable optimizations are domain-specific, one cannot, should not and must not count on *general-purpose* compiler to do them. Compiler writers should think of optimizations that universally profitable, rather than applicable only in specific (and not entirely clear-cut) circumstances. The compiler cannot do algebraic/trigonometric identities! First of all, there are too many of them, and it is not clear in which direction to apply them. Second, most of the identities are not generally valid, in the presence of NaNs etc (for example, 0*x = 0 is not valid for FP computations). A lot has been written about it. This list is not the best place to discuss all this work. Let me give three references: -- The recent talk by Paul Kelly http://www.doc.ic.ac.uk/~phjk/Presentations/2015-09-LCPC-Keynote-PaulKelly-V03-ForDistribution.pdf plus many more publications from his group http://www.doc.ic.ac.uk/~phjk/phjk-Publications.html He talks about finite element methods, far more sophisticated than Runge-Kutta -- A very old paper with lots of references to the debate about compiler optimizations http://www-rocq.inria.fr/~acohen/publications/CDGHKP06.ps.gz -- Stream Fusion, to completeness paper mentioned on this list a couple of months ago. The paper shows yet another example that domain-specific optimizations really work, generating code as if it were written by hand. The paper takes great pains to emphasize why the optimizations cannot be carried out by a general-purpose compiler. Please be sure to read the discussion section near the end, with some notable quotes about GHC optimizer.