Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

re: Varied questions about squeezing more performance



On Thu, 20 Apr 2006 21:59:52 +0000, " Juan P. Pertierra "
<email@hidden> wrote:
> [...]
> Since I am accessing these struct members repeatedly, should I be instead
> assigning the values to local variables and using those instead?  I'm
> thinking perhaps the members are being fetched from memory each time, it
> would be much faster if I could force the processor to keep it in a
> register...i think?

Chances are the compiler is doing the right thing here. It probably not
where you're spending any significant amount of your CPU time.

> [...]
> For example, I have to take the red pixels from the raw data and spread them
out in an image such that
> the pixels sit only at locations where x and y coordinates are even.  I do
this in this manner:
>
> for(y = 0; y < HEIGHT; y++)
>  {
>   for(x = 0; x < WIDTH; x++)
>   {
>    if(x%2 == 0 && y%2 == 0)
>    {
>                              *((unsigned short int *)vBufferRed->data + (y *
WIDTH) + x) = (unsigned short int) *
> ((unsigned char *)vBufferRed0->data + (y * WIDTH) + x);
>                      }
>                      else {...similar code to set these locations to 0...}
>               }
>         }
>
> Is there anything fishy or perhaps a better way to do this?  As you can see I
> am also converting from the 8-bit raw data to a 16-bit image, it is my
> understanding that as long as i'm not converting to/from a float  this is OK
> to do.

You can eliminate the test by stepping x & y by 2 and doing the x+1 and y+1
cases inline in the same pass.

> 3.)Also, I'm not using any inline functions.  Should I be?  For example, would
> it benefit to make an inline function for the x%2 == 0 && y%2 == 0 statement?

Probably not. The compiler is smart enough to "do the right thing" here.

Theory aside, SHARK is your friend. Use it and let it tell you what you need
to do.

> 4.)The instance method which renders each frame only uses vImage functions
> and NSBitmapRep/ NSImage ot save each image...is it faster to use a plain
> C/C++ function for this kind of repeated calls for processing?

Offhand I'd say no but again SHARK is your friend.

> 5.)Finally, at the beginning of the render method I am defining some
convolution kernels as:
>
> const float kernel1[] = {..3x3 values...}
>
> since this is done on every frame, should I be defining this kernels outside
> and pass them to the method,

Yes. (But I bet the compiler does the right thing here also. ;-)

> or is this really as efficient as it gets?

If you're reading the image data into memory and writing it out then you can
get a performance boost out of using mmap. Especially if you're mapping a
file larger than what will fit in virtual memory. But even if you're not our
VM subsystem is very smart about mapping pages in & out of memory and
knowing when a page is dirty or not, etc.

If you have a function that walks thru your images in columns of pixels then
consider ways to make it walk rows of pixels instead. You'll incur less
unnecessary paging if you can access memory contiguously. If you are doing
something like a rotate where you're copying one axis into another the try
to make the output access memory contiguously since page flushes there are
much more expensive than the input pages (that don't have to be flushed).

Other than all this try to do as much as possible in as few passes as
possible. Don't let multiple load & stores be your bottleneck.

-- 
Enjoy,
George Warner,
Schizophrenic Optimization Scientist
Apple Developer Technical Support (DTS)








 _______________________________________________
Do not post admin requests to the list. They will be ignored.
PerfOptimization-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/perfoptimization-dev/email@hidden

This email sent to email@hidden



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.