hi. jsut some comments (although i have commented it in the cvs-logs)...
1. TV is gone (now in pix) 2. a wee change in the imageStruct-class: reallocate() only allocates memory if the old buffer is too small. 3. [pix_tIIR]: another time-domain filter for images. is alike [pix_biquad] (but faster) and [pix_blur] (but more flexible). You can give 2 arguments: the number of feedback-taps and the number of feedforward-taps (in this order). No yuv-optimization is made (because of genericity). A test: [pix_blur] takes (on my machine) between 16% and 26% (mean: ~20%) [pix_tIIR 1 0] takes approx. 24% to 28%.
an ignorant question: how can i make use of loop-unrolling of the compiler ? (how do i have to built the loops? my experiments showed rather worse results when i did large loops (which could have been unrolled by the compiler))
4. what else ? cannot remember.
mfg.asd.r IOhannes
On Mon, 24 Feb 2003, IOhannes zmoelnig wrote:
how can i make use of loop-unrolling of the compiler ? (how do i have to built the loops? my experiments showed rather worse results when i did large loops (which could have been unrolled by the compiler))
excerpt from gridflow/base/number.c :
template <class O> class Op2Loops { public: template <class T> static void op_map (int n, T *as, T b) { while ((n&3)!=0) { *as++ = O::foo(*as,b); n--; } while (n) { as[0] = O::foo(as[0],b); as[1] = O::foo(as[1],b); as[2] = O::foo(as[2],b); as[3] = O::foo(as[3],b); as+=4; n-=4; } } [...]
and then you have to limit the size of your vectorizations in order to reduce cache-misses.
afaik, gcc only does unrolling when it knows exactly the number of iterations. maybe recent versions are different, but gcc 2.95 is still quite in use (and i still use it).
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
hi. jsut some comments (although i have commented it in the cvs-logs)...
- TV is gone (now in pix)
- a wee change in the imageStruct-class: reallocate() only
allocates memory if the old buffer is too small. 3. [pix_tIIR]: another time-domain filter for images. is alike [pix_biquad] (but faster) and [pix_blur] (but more flexible). You can give 2 arguments: the number of feedback-taps and the number of feedforward-taps (in this order). No yuv-optimization is made (because of genericity). A test: [pix_blur] takes (on my machine) between 16% and 26% (mean: ~20%) [pix_tIIR 1 0] takes approx. 24% to 28%.
cool. i will have to take a look at this and see about writing yuv and altivec code for it. i have some FIR code as well. can you post some specifics of your testing like cpu/ram/movie file and frame rate so we can compare performance?
an ignorant question: how can i make use of loop-unrolling of the compiler ? (how do i have to built the loops? my experiments showed rather worse results when i did large loops (which could have been unrolled by the compiler))
hmm, this sort of confirms what i've heard about this in regards to x86 vs PPC. loop unrolling benefits PPC/RISC a lot since these chips tend to have lots of registers (PPC has 32), so by unrolling the loops you make sure all of the registers are filled constantly. 4x unrolling is typically a sweet spot. now on x86 there are considerably fewer registers (is it still only 4???) so this technique is not as effective, but current x86 chips like the p4/athlon have gotten really good at Out of Order Execution (OOOE) so unrolling should be a bit better on those. i have not done any loop unrolling or load-hoisting or cache streaming for the GEM scalar code on PPC simply because it doesn't work cross platform. instead the altivec code uses things like cache streaming to achieve even bigger speed increases over the scalar versions. if unrolling the loops using the compiler options is faster then do that because i suspect that if you compile for a cpu like the p3 it actually doesn't unroll them. or try doing it with some MMX or SSE code and see if that shows an improvement. i haven't done much optimizing on x86 so this is mostly second hand info, but at least x86 has some compilers that will produce ridiculously optimized code given the right circumstances. (i wonder if the SPEC stuff has any convolution code in it, maybe the compiler intel uses to over inflate those scores would be of use...)
- what else ?
cannot remember.
i don't know, but thanks for the post on the changes.
cgc
mfg.asd.r IOhannes
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
chris clepper wrote:
- [pix_tIIR]: another time-domain filter for images.
is alike [pix_biquad] (but faster) and [pix_blur] (but more flexible). You can give 2 arguments: the number of feedback-taps and the number of feedforward-taps (in this order). No yuv-optimization is made (because of genericity). A test: [pix_blur] takes (on my machine) between 16% and 26% (mean: ~20%) [pix_tIIR 1 0] takes approx. 24% to 28%.
cool. i will have to take a look at this and see about writing yuv and altivec code for it. i have some FIR code as well. can you post some specifics of your testing like cpu/ram/movie file and frame rate so we can compare performance?
CPU: p3-1.2GHz RAM: 256MB-DDR movie: anim-1.mov fps: 20
mfg.asd.f IOhannes
-
chris clepper -
IOhannes zmoelnig -
Mathieu Bouchard