On 9/5/06, John Sundman <
[EMAIL PROTECTED]> wrote:
Ben,
Yes, that also helped. I appreciate your taking the time.
Somewhere some rusty hinges of my brain are swinging open to a memory
of dropping down into assembler from C.
Not exactly the same concept, but close enough.
Regards,
jrs
On Sep 5, 2006, at 7:54 PM, Benjamin Shine wrote:
> Here's an explanation that comes from the point of view of the
> application builder (rather than the compiler builder):
>
> Without inlining...
> function f(x) {
> return 3 + g(x);
> }
>
> function g(x) {
> return x * 2;
> }
>
> If f(x) was getting called a lot and was slow, one way to speed it
> up would be to get rid of the function call to g(x). You could do
> this by hand (as Adam did) by changing the definition of f(x) in
> your source code to..
> function f(x) {
> return 3 + (x * 2);
> }
>
> Or, if your compiler supported it, you could add the inline keyword
> to the definition of g(x), something like this:
> inline function g(x) {
> return x * 2;
> }
>
> That would be an instruction (or a clue, depending on the semantics
> of the language) to the compiler, replace every call to g(x) with
> the code in g(x), effectively making f(x) act like its definition
> is the condensed form above, and avoiding the overhead of a
> function call.
>
> In the case Adam was talking about, though, f(x) looked more like...
> {
> for (i = 0 to 5) {
> // do stuff
> stuff = foo + g(x);
> }
> for (j = 0 to 5) {
> bar = goop + g(x);
> }
> }
>
> ...which means that to inline it by hand, he had to write out the
> body of g(x) twice in the body of f(x). Which gets error-prone if
> you really want g(x) to be exactly the same thing both times you
> call it.
>
> Hope this helped...
>
>
> On Sep 5, 2006, at 2:51 PM, John Sundman wrote:
>
>> Tucker:
>>
>> Thank you. Now I understand.
>>
>> jrs
>>
>> On Sep 5, 2006, at 5:46 PM, P T Withington wrote:
>>
>>> Adam wishes that he could declare a function inline.
>>>
>>> An inline function is a function that works exactly like a regular
>>> function, but through black magic in the compiler, does not require
>>> a function call.
>>>
>>> Of course, if your function is actually a method, things become a
>>> bit harder, because a method name binds to a different function
>>> depending on the class of `this`. So the compiler needs even more
>>> black magic to be able to a) determine if the class of `this` is a
>>> constant, and b) if so, what that class is, and c) if that class is
>>> sealed, so d) it can actually determine which function the method
>>> name will map to.
>>>
>>> None of this is really black magic. Good compilers (e.g., the Self
>>> compiler), do this all the time as a matter of course. It's just
>>> that our compiler is a pretty naive little compiler by comparison.
>>>
>>> On 2006-09-05, at 16:41 EDT, John Sundman wrote:
>>>
>>>> I don't understand this conversation.
>>>>
>>>> Can anybody point me to a reference that gives a quick explanation
>>>> of inline keywords?
>>>>
>>>> jrs
>>>>
>>>> On Sep 2, 2006, at 4:16 PM, P T Withington wrote:
>>>>
>>>>> On 2006-09-02, at 14:47 EDT, Adam Wolff wrote:
>>>>>> I recently completed an optimization task by inlining two
>>>>>> levels of
>>>>>> method
>>>>>> calls. This yielded about a 65% speedup. Independent tests have
>>>>>> suggested
>>>>>> that the flash player method call overhead is extremely high.
>>>>>> How much
>>>>>> work would it be to add an explicit inlining feature to the
>>>>>> compiler? Can
>>>>>> we prioritize this?
>>>>>
>>>>> It's not trivial to get this right. There are several tasks that
>>>>> would need to be accomplished first:
>>>>>
>>>>> 1) Complete the compile-time class modeling, so we can compute
>>>>> most-applicable method at compile time
>>>>> 1a) Implement sealing -- you can't do anything if the
>>>>> applicable
>>>>> class is not sealed
>>>>>
>>>>> 2) Complete the compile-time _expression_ analyzer, so you can
>>>>> correctly substitute actuals for parameters in the substituted
>>>>> code.
>>>>>
>>>>> Still, this is pretty standard compiler stuff and doing 2 should
>>>>> also
>>>>> let us write a common sub-_expression_ elimination phase, which
>>>>> would
>>>>> mean the programmer wouldn't have to keep doing that by hand...
>>>>>
>>>>> And it is sure the right thing to do. In-lining by hand just
>>>>> makes
>>>>> for a maintenance nightmare.
>>>>>
>>>>> _______________________________________________
>>>>> Laszlo-dev mailing list
>>>>> [email protected]
>>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>>
>>>
>>
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> [email protected]
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
