| CrashMan said: The only way you can cantinue processing a function after calling another function is if the calling function does not rely on a return value from the called function. In cases like that, you are almost universally talking about another subsystem to the game than the calling function resides in, which would be on another thread any way for optimization. The instances of long, intensive functions with no return value, and no variables passed by refference is extrordinarily low. They are usually short functions that should probably be inlined any way. The actual function call on the core won't be any faster than a standard function call any way. You will need to push the variables to some data structure in memory (probably the stack for that core) and push the return value back to the calling core (stack again) You will have to set the function pointer on the called core to the proper function as well. the only thing that wouldn't need to be done would be to have the calling function's call memory location pushed and popped off the stack. You would have some sort of memory write/read to tell when the return variable is ready, so there is no speed up when calling a function on a separate core than a standard core. I don't see how mulitple cores could possibly speed up the following int funa(int a, int b, int c) { int x = funb(a,b); int y = func(c,x); int z = fund(y,a) return z; } |
I am talking about a whole design change, where essentially each core would have it's own ingoing and outgoing queues, so they could begin processing imeediately.
core1: call funb in core2, read a, pass a to funb, read b, pass b to funb, wait for return from call b, assign into x
core1: call func, read parameter c, pass c to func, pass x to func, wait for return from call c and assign to y
core1: call fund, pass y to fund, pass a to fund, wait for return from d and assign to z, pass z back to calling function
Now the cool thing is, but this gets into messy side-effects (not really in your example, as it mostly safe in this case because of int type and non overlapping variables, but global variables could be modified in both functions making them unsafe), is the second group could actually process the steps on the second line upto pass x to func before it gets a return result. So func actually gets a head start processing things until it needs the x parameter. Simillarly fund can get a head start doing some initialization until it requires the value for y.
With dedicated queues between cores, you save a lot of use of the stack (although register passing would work for this simple case). This is a whole new architecture I am suggesting once there are enough cores on a single chip.
Where the benifits would really be seen is in data manipulation, where one set of data goes through multiple stream functions.
