search for: bitexact

...s that might cause, since (like most speech codecs) we can use slightly unstable filters. If there was a big speed advantage it might be worth the testing to make sure nothing diverges here significantly (and it's _probably_ fine), but I think you can actually do this faster while remaining bitexact. If you shift up the contents of coef32 by 15 bits (which you can do, since you are already transforming them specially for this platform), you can use vqdmulhq_s32() to emulate SMULWB. You then have to do the addition in a separate instruction, but because you can keep all of the results in 3...

...ult to > the original function. If you can make the output be always within one > of two LSBs of the C version, then the asm check can simply be a little > bit more lax than usual. Otherwise it becomes more complicated. This > isn't a function that scares me too much about going non-bitexact, but > it's also not one of the big complexity costs either. In any case, let > me know what you find. > Tested the proposed NEON optimization change, it can increase the whole encoder speed by about 1% at Complexity 8 and 10 for stride = 2 (compared to the NEON optimization in the pr...

On Mon, Apr 24, 2017 at 5:52 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 24/04/17 08:03 PM, Linfeng Zhang wrote: > > Tested on my chromebook, when stride (channel) == 1, the optimization > > has no gain compared with C function. > > You mean that the Neon code is the same speed as the C code for > stride==1? This is not terribly surprising for an IIRC

...e always > within one > of two LSBs of the C version, then the asm check can simply be a > little > bit more lax than usual. Otherwise it becomes more complicated. This > isn't a function that scares me too much about going > non-bitexact, but > it's also not one of the big complexity costs either. In any > case, let > me know what you find. > > > Tested the proposed NEON optimization change, it can increase the > whole encoder speed by about 1% at Complexity 8 and 10 for st...

...you can make the result to the original function. If you can make the output be always within one of two LSBs of the C version, then the asm check can simply be a little bit more lax than usual. Otherwise it becomes more complicated. This isn't a function that scares me too much about going non-bitexact, but it's also not one of the big complexity costs either. In any case, let me know what you find. Cheers, Jean-Marc

...since (like most speech codecs) > we can use slightly unstable filters. If there was a big speed advantage > it might be worth the testing to make sure nothing diverges here > significantly (and it's _probably_ fine), but I think you can actually > do this faster while remaining bitexact. > > If you shift up the contents of coef32 by 15 bits (which you can do, > since you are already transforming them specially for this platform), > you can use vqdmulhq_s32() to emulate SMULWB. You then have to do the > addition in a separate instruction, but because you can keep...

...the original function. If you can make the output be always within one >> of two LSBs of the C version, then the asm check can simply be a little >> bit more lax than usual. Otherwise it becomes more complicated. This >> isn't a function that scares me too much about going non-bitexact, but >> it's also not one of the big complexity costs either. In any case, let >> me know what you find. >> > > Tested the proposed NEON optimization change, it can increase the whole > encoder speed by about 1% at Complexity 8 and 10 for stride = 2 (compared > to...

...ne > > of two LSBs of the C version, then the asm check can simply be a > > little > > bit more lax than usual. Otherwise it becomes more complicated. > This > > isn't a function that scares me too much about going > > non-bitexact, but > > it's also not one of the big complexity costs either. In any > > case, let > > me know what you find. > > > > > > Tested the proposed NEON optimization change, it can increase the > > whole encoder speed by about...

As promised, here's a re-send of all my Aarch64 patches, following comments by John Ridges. Note that they actually affect more than just Aarch64 -- other than the ones specifically guarded by AARCH64_NEON defines, the Neon intrinsics all also apply on armv7; and the OPUS_FAST_INT64 patches apply on any 64-bit machine. The patches should largely be independent and independently useful, other