caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Oleg <oleg@okmij.org>
To: christoph.hoeger@tu-berlin.de
Cc: ivg@ieee.org, yotambarnoy@gmail.com, caml-list@inria.fr
Subject: Re: [Caml-list] Closing the performance gap to C
Date: Fri, 23 Dec 2016 21:18:01 +0900	[thread overview]
Message-ID: <20161223121801.GA4938@Magus.localnet> (raw)
In-Reply-To: <e6051480-00ae-7550-8279-6567d994ca33@tu-berlin.de>


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





      reply	other threads:[~2016-12-23 12:18 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
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 [this message]

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=20161223121801.GA4938@Magus.localnet \
    --to=oleg@okmij.org \
    --cc=caml-list@inria.fr \
    --cc=christoph.hoeger@tu-berlin.de \
    --cc=ivg@ieee.org \
    --cc=yotambarnoy@gmail.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).