07-25-2006 01:42 PM
07-25-2006 01:53 PM
In addition to the answer you linked, there's also a LabVIEW-based example that uses the RDTSC (ReaD TimeStamp Counter) instruction to query a counter that increments at CPU freq (or thereabouts, I don't know the raw gory details down at that low level).
It was intended for use under Pentium-based RT systems, but I recall using it under Windows as well. Here's a link.
Just keep in mind that the timing uncertainty for a chain of function calls under Windows may be orders of magnitude greater than the actual CPU usage time.
When I'm checking performance under Windows, I usually look for some type of average time over maybe 10000+ calls, depending on the thingy I'm benchmarking. Also note that sometimes performance during a benchmark can be significantly better than it is in normal use. The tight looping may keep a lot of things in a local cache and require many fewer than normal wait states for memory access.
Good luck! Despite the quirks and difficulties of performing benchmarks, it's still good to take your best shot at it.
-Kevin P.
07-25-2006 01:58 PM
Thanks a lot. I will give this a try.
Spending most of my adult life in embedded, I am used to being able to get statistically significant information with just a few samples (assuming you know the architecture). I realize that just won't happen with a PC, but I would like to get a general idea what I'm up against.
Thanks again.
07-25-2006 03:39 PM
07-25-2006 03:41 PM
Thanks a bunch.
I will take a look at this later.
LabView 7 is perfect as I am using 7.1
07-25-2006 03:45 PM
07-25-2006 04:02 PM
I found an old version compiled under 7.1
Hopefully this one should work for you
05-22-2007 11:23 AM
Hi Matt,
I believe you made an error in your code to join two 32-bit numbers. The high part should be multiplied by 2^32 = 4,294,967,296 (an even number), not 4,294,967,295. Unless you are trying to compensate for the code processing time to do the calculation.
Regards, Jay
05-22-2007 03:03 PM
09-03-2007 09:25 AM