@SlowPath renaming discussion
Christian Wirth
christian.wirth at oracle.com
Mon Sep 29 09:46:27 UTC 2014
Hi,
Michael, I agree. We will have to give a good description of e.g.
partial evaluation. Truffle developers need to understand the basic
concepts to achieve high performance. Every Truffle developer should
know what "PE" means and understand that concept.
I vote for @PEBoundary.
-- Christian Wirth
Am 29.09.2014 11:29, schrieb Michael Haupt:
> Hi,
>
> @PEBoundary is non-threatening and apt, but heavy on jargon. The documentation will have to explain part of the underlying concepts clearly.
>
> Best,
>
> Michael
>
> Am 29.09.2014 um 10:39 schrieb Laurent Daynes <laurent.daynes at oracle.com>:
>
>> Alright, I'm sold.
>> However, I strongly encourage a more developed comment in the source for the annotation that the current succinct one for SlowPath, which
>> doesn't reflect the subtleties hidden behind it.
>>
>> Laurent
>> On 9/29/2014 10:30 AM, Lukas Stadler wrote:
>>> I’m a big fan of @PEBoundary - because:
>>> - it’s concise
>>> - it says exactly what it is (entry into this method is a boundary for partial evaluation)
>>> - it’s non-threatening (as opposed to stop, cut or exit)
>>> - “inlining” and “interpreted” are overloaded with too many different meanings, so I think we should avoid these terms
>>>
>>> - Lukas
>>>
>>> On 26 Sep 2014, at 18:01, Bernhard Urban <bernhard.urban at jku.at> wrote:
>>>
>>>> @ExitPartialEvaluator / @ExitPE
>>>>
>>>> fwiw, in pypy there's a @jit.dont_look_inside annotation.
>>>>
>>>> -Bernhard
>>>> On Sep 26, 2014 5:30 PM, "Christian Humer" <christian.humer at gmail.com>
>>>> wrote:
>>>>
>>>>> I also agree not to use inline. I usually use "guest language inlining" for
>>>>> 1), "expansion" for 2) and "host language inlining" for 3).
>>>>>
>>>>> Will keep the suggestions flowing and will wrap up a vote later on.
>>>>>
>>>>>
>>>>>
>>>>> - Christian Humer
>>>>>
>>>>> On Fri, Sep 26, 2014 at 5:09 PM, Gero Leinemann <gero.leinemann at oracle.com
>>>>> wrote:
>>>>>
>>>>>> Though I find the simplicity of "@NotInlined" etc. appealing, I'd
>>>>>> recommend not to use the word "inline", as this is highly overloaded in
>>>>> the
>>>>>> Truffle/Graal context:
>>>>>> 1. inlining by AST rewriting (language level)
>>>>>> 2. inlining during/for PE (Truffle level)
>>>>>> 3. inlining done by the compiler (Graal/compiler level)
>>>>>> This confused - at least - me quite a bit when I started working at
>>>>> FastR.
>>>>>> What about @StopPE?
>>>>>>
>>>>>> Best,
>>>>>> Gero
>>>>>>
>>>>>> Am 26.09.2014 um 16:49 schrieb Chris Seaton:
>>>>>>
>>>>>> What about something less Truffle specific? What about @StopInlining,
>>>>>>> @NotInlined or @DontInline?
>>>>>>>
>>>>>>> On 26 Sep 2014, at 15:28, Michael Haupt <michael.haupt at oracle.com>
>>>>> wrote:
>>>>>>> Hi Christian,
>>>>>>>> Am 26.09.2014 um 16:11 schrieb Christian Humer <
>>>>>>>> christian.humer at gmail.com>:
>>>>>>>> I would suggest these names:
>>>>>>>> @Boundary
>>>>>>>> @TruffleBoundary
>>>>>>>> @PartialEvaluationBoundary (or @PEBoundary)
>>>>>>>>
>>>>>>>> Please add more suggestions and vote for whatever you think is best.
>>>>>>>>
>>>>>>>> I'll try to first give my rationale for how I try to come up with a
>>>>>>>> name. It should express the intent of the annotation with regard to the
>>>>>>>> method it is attached to, at a level that is understandable by a
>>>>> Truffle
>>>>>>>> user.
>>>>>>>>
>>>>>>>> Applying this, and note that this is purely my personal view, @Boundary
>>>>>>>> is a bit too fuzzy; @TruffleBoundary is more apt, but regarding a
>>>>> method as
>>>>>>>> a boundary is a bit odd; and @PEBoundary is rather technical (not
>>>>> focused
>>>>>>>> on the user).
>>>>>>>>
>>>>>>>> Alternative suggestions (more may be coming): @TruffleInterpreted,
>>>>>>>> @TruffleInterpretOnly. (Prepending "Truffle" should indicate that the
>>>>>>>> method is not exempt from compilation.)
>>>>>>>>
>>>>>>>> If the technical stance of @PartialEvaluationBoundary is agreeable but
>>>>>>>> the name is too long, how about @NoPE? ;-)
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Michael
>
More information about the graal-dev
mailing list