Re: vDSP_conv very slow --> very fast now!
Re: vDSP_conv very slow --> very fast now!
- Subject: Re: vDSP_conv very slow --> very fast now!
- From: "Cor Jansen" <email@hidden>
- Date: Mon, 12 Feb 2007 09:32:26 +0100
Thanks Ian,
This helped! The FilterStride need indeed to be 1.
According to the documentation a value of -1 should also involve vector
code. But it does not.
Now I can do a strereo 44.1Kc FIR filter with 10.000 coefficients in about
50% cpu time. Thats good enough for me.
Thanks again.
----- Original Message -----
From: "Ian Ollmann" <email@hidden>
To: <email@hidden>
Sent: Thursday, February 08, 2007 9:31 PM
Subject: Re: vDSP_conv very slow
vDSP_conv(bufSignal,1,bufIR+ROOMCORRECTION_FILTSIZE-1,-1,bufResult,
1,nSampleFrames,ROOMCORRECTION_FILTSIZE);
The current internal decision path for scalar vs. vector code in
vDSP_conv looks like this:
StrideType StrideMask = InputStride^1 | FilterStride^1 | OutputStride^1;
uintptr_t AddressMask = (uintptr_t) Filter & 0xf;
// If eligible, use high-performance routine.
if ((StrideMask | AddressMask) == 0)
//call vector code
else
//go to scalar code purgatory
So, it looks like you may need to reverse the order of the data in the
coefficients in the filter. Sorry about that. Reversing the order of
your filter coefficients seems unreasonable to me. I think we should be
at least vectorizing the stride -1 case. Alas, that's the way things are
at the moment.
Ian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden