| ??? 11/10/03 00:59 Read: times |
#58160 - RE: Throughput Responding to: ???'s previous message |
I would start by suggesting that you better define what you mean by throughput. Nonetheless, I will offer the following comments based on my understanding (that is to say, best guess) of what you mean. If you are writing your code directly in machine specific instructions (hex or binary) then it is a simple matter to sum the machine cycles per instruction. If, on the other hand, you are writing your code in a higher level language (if your code has to be compiled) then you will likely measure the time your compiled code takes to operate. I'm sure there are several people on this site who can share examples of how to do this. This is frequently a quite sufficient approximation of run time. Of course, this is all dependent on the measurement or calculation being applied to a segment of code that runs for a definite period. If your algorithm iterates over a variable number of cycles (e.g. as in successive approximation) then you will only be able to speak to the time per cycle. Your "throughput" then becomes a function of the specific circumstances of each application and must be treated statistically. I hope this is of some help. |
| Topic | Author | Date |
| Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| RE: Throughput | 01/01/70 00:00 | |
| OFF TOPIC | 01/01/70 00:00 | |
RE: OFF TOPIC | 01/01/70 00:00 |



