1

My question is specific to iPhone, iPod, and iPad, since I am assuming that the architecture makes a big difference. I'm hoping there is either a specification somewhere (for the various chips perhaps), or a reliable way to measure T for each specific instruction. I know I can use any number of tools to measure aggregate processor time used, memory used, etc. I want to quantify at a lower level.

So, I'm able to figure out how many times I go through the main part of the algorithm. For example, I iterate n * (n-1) times in a naive implementation, and between n (best case) and n + n * (n-1) (worst case) in another. I can also make a reasonable count of the total number of instructions (+ - = % * /, and logic statements), and I can compare those counts, but that's assuming the weight of each operation is the same. Also, I don't have any idea how to weight the actual time value of a logic statement (if, else, for, while) vs a mathematical operator... is "if" as much work as "+" each time I use it? I would love to know where to find this information.

So, for clarity, my goal is to discover how much processor time I am demanding of the CPU (or GPU or any U) so that I can design an optimal algorithm around processor time. Can someone give me an idea of where to start for iOS hardware?

Edit: This link to ClockServices.c and SIMD stuff in the developer portal might be a good start for people interested in this. A few more cups of coffee tonight and I might get through it ;)

Rab
  • 2,806
  • 2
  • 16
  • 20
  • Most of what I want to evaluate is just C. I would be happy with that. However, it would be nice to know the cost of iterating through an NSArray; but that sounds like it could be complex and variable. I just don't know how much I can hope to find out... I'll settle for the basic C operations for sure ;) – Rab Jan 06 '11 at 09:45
  • Yeah I thought of that (the million tests), but it's a good comment. I considered running tests like you say, but I have two fears about the results. One is that my test will be naive in some way, and I'll do a lot of work for information that doesn't hold up when the compiler decides to do something different. Second, I only have a few devices, and some have different chips. So my dearest hope is maybe someone has charts with close estimates for time value of C operations for a particular processor. – Rab Jan 06 '11 at 09:56
  • Got a chuckle out of the NSArray comment. I hope my NSArray doesn't bluescreen on me or something ;) – Rab Jan 06 '11 at 09:58

2 Answers2

2

On a modern platform, processor time isn't the only limiting factor. Often, memory access is.

Still, processor time:
Your basic approach at an estimation for the processor load is OK, though, and is sensible: Make a rough estimate of the cost based on your knowledge of typical platforms.

In this article, Table 1 shows the times for typical primitive operations in .NET. While your platform may vary, the relative time is usually very similar. Maybe you can find - or even make - one for iStuff.

(I haven't come across one so thorough for other platforms, except processor / instruction set manuals, but they deal with assembly instructions)

memory locality:
A cache miss can cost you hundreds of cycles, a disk access a thousand times as much. So controlling your memory access patterns (i.e. reducing the working set, restructuring and accessing data in a cache-friendly way) is an important part of evaluating an algorithm.

peterchen
  • 40,917
  • 20
  • 104
  • 186
  • Thank you. This is really useful information. Also, I'm glad to know that my basic approach is not too far off. – Rab Jan 06 '11 at 11:46
0

xCode has instruments to measure performance of each function/operation, you can simply use them.

Nickolay Olshevsky
  • 13,706
  • 1
  • 34
  • 48
  • I do use them. But the number of tests I would need to do to inform a new algorithm design could potentially be very large. Exponentially, quadratically, logarithmically large. That's why I would like to find guidelines (at least) as to the computational complexity of various operations. In other words, I am happy to read the manual, but I don't want to write the manual for a whole language+compiler+architecture set. – Rab Jan 06 '11 at 10:53