Comments on: Productive Waste of Time: Gradients and Altivec http://www.noodlesoft.com/blog/2006/10/05/productive-waste-of-time-gradients-and-altivec/ On Mac OS X programming Tue, 02 Dec 2008 12:24:07 +0000 http://wordpress.org/?v=2.6.3 By: mr_noodle http://www.noodlesoft.com/blog/2006/10/05/productive-waste-of-time-gradients-and-altivec/#comment-15 mr_noodle Fri, 06 Oct 2006 15:09:44 +0000 http://www.noodlesoft.com/blog/2006/10/05/productive-waste-of-time-gradients-and-altivec/#comment-15 Thanks for the very informative comment. So it seems I was right on both counts. My test was sub-optimal but in the end it probably doesn't matter. I probably won't be spending much more time on this (the VRSAVE suggestion is beyond the scope of my knowledge on the subject at this point), but in the end, it's always good when I can learn from my failed experiments. Thanks for the very informative comment. So it seems I was right on both counts. My test was sub-optimal but in the end it probably doesn’t matter. I probably won’t be spending much more time on this (the VRSAVE suggestion is beyond the scope of my knowledge on the subject at this point), but in the end, it’s always good when I can learn from my failed experiments.

]]> By: alexr http://www.noodlesoft.com/blog/2006/10/05/productive-waste-of-time-gradients-and-altivec/#comment-13 alexr Fri, 06 Oct 2006 00:53:52 +0000 http://www.noodlesoft.com/blog/2006/10/05/productive-waste-of-time-gradients-and-altivec/#comment-13 The faster way to do this function would be to either know that in is aligned and do one load, or do do two loads and a vec_perm(vec1,vec2,vec_lvsl(0,in)) to get the misaligned data. Loading four floats and storing them to memory, then reloading as a vector is slower. You need to "Show Assembly Code" from Xcode to see that the compiler is generating the instructions you expect. Pointer aliasing and other extra memory operations become evident this way. As you've noted, the real problem here is that the overhead of the callback mechanism swamps the work done in the function. If you can be 100% sure that CG calls this function back in the same thread as you, you could compile the function to not update VRSAVE in the prolog/epilog and then set VRSAVE to 0xFFFFFFFF before calling CG to run the function. That would save a few more instructions, but the overhead of the callbacks is probably still too high. The faster way to do this function would be to either know that in is aligned and do one load, or do do two loads and a vec_perm(vec1,vec2,vec_lvsl(0,in)) to get the misaligned data. Loading four floats and storing them to memory, then reloading as a vector is slower.

You need to “Show Assembly Code” from Xcode to see that the compiler is generating the instructions you expect. Pointer aliasing and other extra memory operations become evident this way.

As you’ve noted, the real problem here is that the overhead of the callback mechanism swamps the work done in the function. If you can be 100% sure that CG calls this function back in the same thread as you, you could compile the function to not update VRSAVE in the prolog/epilog and then set VRSAVE to 0xFFFFFFFF before calling CG to run the function. That would save a few more instructions, but the overhead of the callbacks is probably still too high.

]]>