Deterministic Proposal

[Lars Hansen]

On Thu, Jun 22, 2017 at 9:14 AM, Andreas Rossberg <rossberg at google.com>
wrote:

> On 22 June 2017 at 01:24, Guy Ellis <wildfiction at gmail.com> 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 <rossberg at google.com>
>> wrote:
>>
>>> On 21 June 2017 at 18:40, Bradley Meck <bradley.meck at gmail.com> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170622/75ddf497/attachment.html>