Re: [Vala] idea for vala performance optimization

[Michele Dionisio <michele dionisio gmail com>]

Sorry, I was thinking too much but only write too short email.

It is true the gcc nested function does not manage any reference counting
to the object or manage any garbege collector. but thinks about this quite
common scenario:

async function1() {
int a=1;

yield function2();

yield function3();

}

when function1 is converted in C we can split functio1 in more than one
neasted function that all can access to the local variable 'a';

something like:

function1() {
 int a=1;

void function1_2() {
}

 void function1_1() {
   function1_2();
 }

function2( function1_1() );
}

now 'a' is visible to all. So the continuation can be implemented without
problem because function1 is not terminated before calling function1_1 and
function1_2 and there is no copy of memory.

I think that gcc is quite efficient to manage that because it access
directly to the stack allocated object of function1 from function1_1 and
function 1_2. It can be done because of:
"If you try to call the nested function through its address after the
containing function has exited, all hell will break loose. If you try to
call it after a containing scope level has exited, and if it refers to some
of the variables that are no longer in scope, you may be lucky, but it's
not wise to take the risk. If, however, the nested function does not refer
to anything that has gone out of scope, you should be safe."

but yes it is true it is quite difficult to be implemented and I don't know
from where start and if this can really introduce notable
performance benefit.

regards

2015-11-21 13:44 GMT+01:00 Al Thomas <astavale yahoo co uk>:

> > From: Michele Dionisio <michele dionisio gmail com>
>
> > Sent: Saturday, 21 November 2015, 9:37
> > Subject: [Vala] idea for vala performance optimization
> >
> > Ok, this is the only way because the C standard does not support closures
> > by itself. But gcc support closure in not standard "nested functions".
> >
> > https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
> >
> > so it is teorically possible to avoid to make a lot of copy.
>
> >
>
>
> From the document you reference:
>
> "If you try to call the nested function through its address after the
> containing function has exited, all hell will break loose. If you try to
> call it after a containing scope level has exited, and if it refers to some
> of the variables that are no longer in scope, you may be lucky, but it's
> not wise to take the risk. If, however, the nested function does not refer
> to anything that has gone out of scope, you should be safe."
>
> GCC nested functions are not closures.
>
> > do you think that it can be convenient to try to develop a special "vala
> to
> > c converter" for gcc to test the real speed benefit?
>
>
> Unfortunately not a good idea. GCC nested functions are not closures. Even
> if they were it would
> tie Vala to a specific C compiler which I find a valid objection. Finally
> a pointer to the
> context data is passed in a closure, not the data itself. Why are you so
> sure the C compiler
> handles this in an inefficient manner?
>
>
> Al
> _______________________________________________
> vala-list mailing list
> vala-list gnome org
> https://mail.gnome.org/mailman/listinfo/vala-list