Re: Is this a bug in Tiger's NSBitmapImageRep?
Re: Is this a bug in Tiger's NSBitmapImageRep?
- Subject: Re: Is this a bug in Tiger's NSBitmapImageRep?
- From: John Stiles <email@hidden>
- Date: Wed, 4 May 2005 11:07:18 -0700
On May 4, 2005, at 9:32 AM, Cameron Hayne wrote:
On 4-May-05, at 12:00 PM, Rick Hoge wrote:
What reason could there be for avoiding powers of two?
I was referring to the comment in the vImage example code (that Marc
Liyanage linked to) that said something about some PPC processors
having trouble with access on powers of two. That vImage code took
specific steps to avoid powers of two.
There are some cases where subtle cache effects can cause memory
accesses with large power-of-two strides to have poor performance. This
is a drastically simplified explanation, but imagine if the L1/L2 cache
used the lower 14 bits of an address to decide which slot in the cache
to use. Now if you accessed every 16K-th byte of your data in a row,
you would only use a single slot in the cache while the rest sat idle,
and every write you performed would need to flush the previous write
out to main memory. Stalls galore. But if you accessed every (16K-1)th
byte, you'd get to use the whole cache.
Like I said, the real situation is more complicated but it has to do
with cache associativity. I remember some old-school games got big
speed boosts by playing on this effect (i.e. apparently Doom 1 relied
on this trick).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden