GNOME.org
 

Re: [Vala] idea for vala performance optimization

Yes, I'm sorry.
I'm reading the code generated from

async int function2(int a) {
 return (a +1);
}

async int function1() {
 SourceFunc callback = function1.callback;
 int a = 0;

 stderr.printf(@"step1: $a\n");

 a = yield function2(a);

 stderr.printf(@"step2: $a\n");

 Idle.add(() => {
  a = a + 1 ;
  callback();
  return false;
 });

 yield;

 stderr.printf(@"step3: $a\n");

 return a;
}

and it is true 'a' is not copy in continuation (I was thinking that the
pointer was copyed, sorry, my fault). All the "stack" of the function
function1 is allocated on the heap.
But in an example like the previous one it is possible to use gcc nested
function to continue to use the stack of function1 avoiding to make any
dereference to access to the "stack" of function1. Use the stack instead
the heap will increase the performance because:
1. avoid to call malloc/free (quite slow)
2. stack is probably in the cache of the processor and is quite quick.



2015-11-21 15:19 GMT+01:00 Luca Bruno <lethalman88 gmail com>:


Where do you read that vala copies data for the closure? The closure data
is created to be used both for the lambda and for the method containing the
lambda. The closure data is shared, not copied.

On Sat, Nov 21, 2015 at 3:13 PM, Michele Dionisio <
michele dionisio gmail com> wrote:


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


_______________________________________________
vala-list mailing list
vala-list gnome org
https://mail.gnome.org/mailman/listinfo/vala-list





--
NixOS Linux <http://nixos.org>
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]