On Thu, Jun 22, 2017 at 9:14 AM, Andreas Rossberg <[email protected]> wrote:
> On 22 June 2017 at 01:24, Guy Ellis <[email protected]> wrote: > >> My thoughts are along the lines that the developer would decide what a >> deterministic function was and decorate/tag it as such. That's why I used >> the word deterministic and not pure. Basically the developer is signaling >> the compiler that given an identical parameter signature the result >> received back from the first call can be used for all subsequent results. >> >> The developer implementing compiler optimization would then have a flag >> available against any method that would signal if it is deterministic or >> not and would decide to use that information or not. >> > > Except in a very small set of uninteresting cases, such an optimisation is > not allowed, because it changes the semantics of the function. A "tag" as a > compiler hint would not change that. The semantics of every language > construct has to be well-defined, and must not depend on whether or not a > compiler chooses to apply certain optimisations. > Well, the annotation could be a hint that the optimization is allowed, and if the implementation could check cheaply that the function is indeed pure it might still be a win. Depending on details, of course. Not that I'm advocating it :) I *think* that a purity annotation was at least proposed for early versions of the Parallel JS work (Intel's "RiverTrail", later Intel/Mozilla's "PJS") but I can't find any details anywhere. If there were such annotations they were already gone by 2012 [1]. All PJS work I know about based itself on assuming a kind of observational purity of the kernel functions that were being run in parallel -- side effects were OK as long as you were only touching memory that was private to the invocation, in general this required a combination of compile-time and run-time checks -- with a fallback to sequential execution. This turned out to be hard to spec and to implement [2]. A purity annotation would probably not move the needle on the difficulty; in effect, all kernel functions for PJS were implicitly annotated as pure (or really, observationally pure, which is more powerful). --lars [1] http://smallcultfollowing.com/babysteps/blog/2012/10/10/rivertrail/ [2] https://groups.google.com/forum/#!msg/mozilla.dev.tech.js-engine/H-YEsejE6DA/BLERtTTm8GYJ <https://groups.google.com/forum/#!msg/mozilla.dev.tech.js-engine/H-YEsejE6DA/BLERtTTm8GYJ;context-place=forum/mozilla.dev.tech.js-engine> > > > > >> The question is: Would that extra information provide the Compiler >> Optimizing Developer with information that they could use to improve >> performance or anything else? If you are/were such a >> Compiler-Optimizing-Developer how would you use this information? >> >> >> On Wed, Jun 21, 2017 at 9:59 AM Andreas Rossberg <[email protected]> >> wrote: >> >>> On 21 June 2017 at 18:40, Bradley Meck <[email protected]> wrote: >>> >>>> You probably mean "pure", not "deterministic", which has nothing to do >>>>> with this. However, JavaScript is far, far too impure for any such >>>>> annotation to ever make sense or enable any sort of memoization. Consider >>>>> let i = 0 >>>>> let o = {valueOf() {return i++}} >>>>> sum(o, 0) >>>>> sum(o, 0) >>>> >>>> >>>> If type coercion was disabled within "pure" functions I am not sure >>>> this would be a problem. >>>> >>> >>> A new language mode with modified semantics is a whole new dimension >>> that is far from simple to add to JS. And even then the pure subset of JS >>> would remain tiny. >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
