Mark Cave-Ayland wrote:
Indeed. I had a similar inspiration earlier this evening, with the only problem being how to switch code into next() without causing a performance hit. However, I think I've just worked out a cute little hack that would solve this. I'm at a conference over the next few days, so it might not be until next week that I get a chance re-work the patch and resubmit.
Okay, so I've come across an interesting problem with regard to reworking this. Attached is a patch that demonstrates some very alarming behaviour, at least here on x86_64 gcc 4.3.2. What happens is that just by adding a single function pointer to kernel/internal.c, the runtime for my fibonacci benchmark goes up by 40%!
With the attached patch for OpenBIOS SVN, I get the following runtime for the Fibonacci benchmark:
build@zeno:~/src/openbios/openbios-devel$ time echo "28 fib-rec u. bye" | ./obj-x86/openbios-unix ./obj-x86/openbios-x86.dict Welcome to OpenBIOS v1.0 built on Nov 9 2009 17:17 Type 'help' for detailed information
[unix] Booting default not supported.
0 > 28 fib-rec u. bye 6197ecb Farewell!
ok
real 0m52.564s user 0m52.027s sys 0m0.012s
If the line "void (*debughook) (void);" is then commented out from kernel/internal.c then the runtime looks like below (which is roughly the same as running the fib-rec benchmark on plain OpenBIOS SVN):
build@zeno:~/src/openbios/openbios-devel$ time echo "28 fib-rec u. bye" | ./obj-x86/openbios-unix ./obj-x86/openbios-x86.dict Welcome to OpenBIOS v1.0 built on Nov 9 2009 17:12 Type 'help' for detailed information
[unix] Booting default not supported.
0 > 28 fib-rec u. bye 6197ecb Farewell!
ok
real 0m37.946s user 0m37.178s sys 0m0.020s
So in other words, simply defining a pointer variable (which hasn't even been used anywhere in the code yet) is increasing the runtime by 40%?! Can anyone shed any light on this behaviour? It just doesn't seem to make any sense to me.
ATB,
Mark.