Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
If you are doing live audio, or a FPS game, an extra 100 milliseconds latency can take your guitar effects processing or fast 3D game from great to unusable. Even an extra 33 mS can be really bad.

Right - that's why I included the bit about things demanding immediate feedback like games and interface input. When you're in that realm of performance being demanded, the question becomes what difference does 10 ms or 1 ms make. I'm sure someone can come up with something demanding sub-ms precision.... Maybe a super high speed camera or something.
 
When you're in that realm of performance being demanded, the question becomes what difference does 10 ms or 1 ms make. I'm sure someone can come up with something demanding sub-ms precision.... Maybe a super high speed camera or something.

Low latency audio effects are commonly done with buffer callbacks that come at an app every 5.8 to 2.9 mS, which MUST be handled on time, or else the users hears a really nasty audio "POP". The iPhone 5s 120 FPS "slo-mo" mode produces a new 720P frame every 8.3 mS, which averages to a new pixel to process every 9 nanoseconds if you want to keep up while doing real-time image processing.
 
You probably don't want to access ivars inside critical loops either. You'll want to copy them to local variables so they can be stored in registers.
 
You probably don't want to access ivars inside critical loops either. You'll want to copy them to local variables so they can be stored in registers.

Would the compiler not automatically handle this for you?

... I suppose maybe if the compiler didn't realize the variable wasn't being used elsewhere it might not...
 
You probably don't want to access ivars inside critical loops either. You'll want to copy them to local variables so they can be stored in registers.

It would be interesting to see if the compiler does that for you. Modern compilers are really good at optimization, so I would not be at all surprised if the compiler copies the iVar to a register inside the loop.
 
There's always the alias problem to confound the optimizer. So I expect that the answer is "it depends."

I agree that the compilers these optimize very well but correctness can cause problems. If you care you'll need to profile and maybe inspect the disassembly.
 
There's always the alias problem to confound the optimizer. So I expect that the answer is "it depends."

I agree that the compilers these optimize very well but correctness can cause problems. If you care you'll need to profile and maybe inspect the disassembly.

Sure. You can also help the compiler with some simple steps like declaring the variables in time-critical loops with the register qualifier.
 
You are an old timer ;-)

I would bet that the register keyword is ignored no matter what. On architectures that have more than 4 registers the compiler does a better job than you can to figure out what to keep in registers. I doubt that it's used in any way today.
 
You are an old timer ;-)

I would bet that the register keyword is ignored no matter what. On architectures that have more than 4 registers the compiler does a better job than you can to figure out what to keep in registers. I doubt that it's used in any way today.

I remember when I was programming a microchip last year there were some odd keywords I had to use... something like "distant", that signified that a variable needed to be kept in registers that took longer to access (because I already had all of the "nearby" registers filled with variables. I doubt it was a standard C keyword.)
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.