Hello all,
I've made a simple program that benchmarks a routine I just written. I added a second file (vfpu.c) with routines I use in my library, but not in the actual called functions for this benchmark.
I test my routine, I get 9.5 milliseconds. Quite good. Now I add a routine in vfpu.c that I will never call. The bench now says 11.5!!!!!! I add several other routines (8 cut&paste from the original routine, adding a number at the end of their name) and I get 11.8!
My benchmark is not the problem, I think. Here is my project:
http://membres.lycos.fr/brunni/test.zip (you have to right click and select save target as, I don't have anywhere else to host my file)
Note: It's a light version, I removed unused routines. If you open the VFPU.C file and remove the comment with the lot of functions at the end and recompile, you'll see the difference (but only something like 9.5 -> 10.7, because there's less routines).
Maybe it has something to do with the cache... Can someone help me please?
Thanks in advance.
My program becomes slower each time I define a function!
My program becomes slower each time I define a function!
Sorry for my bad english
Oldschool library for PSP - PC version released
Oldschool library for PSP - PC version releasedWell, www.megaupload.com to host your files.
But it makes since that a program would get slower with more functions, i dont see why it wouldnt.
But it makes since that a program would get slower with more functions, i dont see why it wouldnt.
I cant download the file to see exactly how you're doing this, but a bigger program should not be slower. Depending on what you're doing cache misses can be an issue, but honestly I think you're probably just going slower because of multithreading. If you want to run a test, Id suggest loading up the program, waiting a few seconds, and then executing the timed test loop. That way you can ensure the the threads calling your thread and allocating memory and such are all done with.
Its very likely that each time you run your program the timing is going to be off a bit. 2miliseconds isnt that much time....
Maybe you could do 100x as much processing as you're doing now, do wahtever test in a for loop and check the time. It should be more accurate then, too.
Its very likely that each time you run your program the timing is going to be off a bit. 2miliseconds isnt that much time....
Maybe you could do 100x as much processing as you're doing now, do wahtever test in a for loop and check the time. It should be more accurate then, too.
i'm obtaining something like this too on my code.
fps that changes between 45-47, i guess that even simple code modifications change some code/function alignments that produce this difference (this happen even with really simple modifications, like zeroing a variable in an initialization routine - so outside the bench code)
fps that changes between 45-47, i guess that even simple code modifications change some code/function alignments that produce this difference (this happen even with really simple modifications, like zeroing a variable in an initialization routine - so outside the bench code)
47 fps?
If you are on platform you cant get any other FPS values than 60, 30, 20, 15, 12,10, and then you get some strange ones. It has a 60Hz refresh rate and everyone should be using vsynch, so only fps values that are 60/x (x = int) can work.
Anyways, FPS is not a very good way of testing code speed. Here is what you should do:
1) Get a high speed clock value from the CPU, the PSP will give you a 64bit one that clicks something like every 10ns. Its pretty insanely fast.
2) Do a whole bunch of computations, the less 'outside' code (system calls) you do, the better. Dont call vsync in here because it'll screw up your timing. Look into nonblocking calls when you do syscalls. PSP supports nonblocking on almost all of its slow functions (Disk IO, network, etc)
3) Get the clock again, subtract the original clock from it.
-Bill
If you are on platform you cant get any other FPS values than 60, 30, 20, 15, 12,10, and then you get some strange ones. It has a 60Hz refresh rate and everyone should be using vsynch, so only fps values that are 60/x (x = int) can work.
Anyways, FPS is not a very good way of testing code speed. Here is what you should do:
1) Get a high speed clock value from the CPU, the PSP will give you a 64bit one that clicks something like every 10ns. Its pretty insanely fast.
2) Do a whole bunch of computations, the less 'outside' code (system calls) you do, the better. Dont call vsync in here because it'll screw up your timing. Look into nonblocking calls when you do syscalls. PSP supports nonblocking on almost all of its slow functions (Disk IO, network, etc)
3) Get the clock again, subtract the original clock from it.
-Bill
CyberBill, this is a bit OT :)
i know how to bench code (i'm already using sceRtcGetTickResolution / sceRtcGetCurrentTick and the code portion i'm benching doesn't contain vsync)
(i don't agree on your fps discussion - but let's not go OT too much here - drop me a pm if you want to discuss about this)
i know how to bench code (i'm already using sceRtcGetTickResolution / sceRtcGetCurrentTick and the code portion i'm benching doesn't contain vsync)
(i don't agree on your fps discussion - but let's not go OT too much here - drop me a pm if you want to discuss about this)