<div>Hi Jean-Marc,</div><div><br></div><div>I tried "==" before, and it failed when both results are 0.0. Maybe the exponent or sign has difference because of the different 0.0 representation in NEON. If anybody know how to handle this 0.0 comparison, that would be great.</div><div>Or just use if(a==b || (a==0.0 && b==0.0)) ... but I haven't try this.</div><div><br></div><div>Thanks,</div><div>Linfeng</div><div><br><div class="gmail_quote"><div>On Mon, Jun 5, 2017 at 8:43 PM Jean-Marc Valin <<a href="mailto:jmvalin@jmvalin.ca">jmvalin@jmvalin.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Linfeng,<br>
<br>
On 05/06/17 03:31 PM, Linfeng Zhang wrote:<br>
> Yes we'll have one more patch set related to xcorr in next week. Please<br>
> don't wait if it's too late for 1.2 release.<br>
<br>
Assuming there's no issue with the patches, next week isn't too late.<br>
<br>
Also, I've started looking at your patches. So far there's one thing<br>
that puzzles me a bit. In the OPUS_CHECK_ASM section of patch 0004, you<br>
have:<br>
<br>
+        celt_assert(ABS32(xy1_c - *xy1) <= VERY_SMALL);<br>
<br>
Given the normal range of the values (the xy values are often much<br>
larger than one) and the precision involved here (24-bit mantissa), it<br>
seems like this test can only succeed if the two values are actually<br>
equal. Is the float patch actually bit-exact? If so, then maybe you<br>
should be using actual equality. If not, then I guess we need to find<br>
the right condition (which isn't obvious for floating point).<br>
<br>
Cheers,<br>
<br>
        Jean-Marc<br>
<br>
<br>
> Thanks,<br>
> Linfeng<br>
><br>
> On Mon, Jun 5, 2017 at 12:28 PM, Linfeng Zhang <<a href="mailto:linfengz@google.com" target="_blank">linfengz@google.com</a><br>
> <mailto:<a href="mailto:linfengz@google.com" target="_blank">linfengz@google.com</a>>> wrote:<br>
><br>
>     Hi Jean-Marc,<br>
><br>
>     I attached the new version in inner_prod_5patches_v2.zip which<br>
>     synced to the current master.<br>
><br>
>     For fixed-point ARM, only<br>
>     0003-Optimize-fixed-point-celt_inner_prod-and-dual_inner_.patch<br>
>     changes the performance.<br>
>     For floating-point ARM, only<br>
>     0004-Optimize-floating-point-celt_inner_prod-and-dual_inn.pa<br>
>     <<a href="http://elt_inner_prod-and-dual_inn.pa" rel="noreferrer" target="_blank">http://elt_inner_prod-and-dual_inn.pa</a>>tch changes the performance.<br>
>     Patch 1 and 2 are code clean-up and can only affect x86 performance.<br>
>     Patch 5 has neglectable effect on floating-point ARM performance.<br>
><br>
>     Thanks,<br>
>     Linfeng<br>
><br>
>     On Fri, Jun 2, 2017 at 11:26 AM, Jean-Marc Valin <<a href="mailto:jmvalin@jmvalin.ca" target="_blank">jmvalin@jmvalin.ca</a><br>
>     <mailto:<a href="mailto:jmvalin@jmvalin.ca" target="_blank">jmvalin@jmvalin.ca</a>>> wrote:<br>
><br>
>         Hi Linfeng,<br>
><br>
>         I'll look into your patches. Can you let me know what's the expected<br>
>         effect on performance (if any) for each of your patches? Also,<br>
>         are these<br>
>         all the patches you intend to merge for 1.2 or are there more<br>
>         upcoming ones?<br>
><br>
>         Cheers,<br>
><br>
>                 Jean-Marc<br>
><br>
>         On 01/06/17 06:33 PM, Linfeng Zhang wrote:<br>
>         > Hi,<br>
>         ><br>
>         > Attached are 5 patches related to celt_inner_prod()<br>
>         > and dual_inner_prod() NEON intrinsics optimization.<br>
>         ><br>
>         > In<br>
>         0004-Optimize-floating-point-celt_inner_prod-and-dual_inn.pa<br>
>         <<a href="http://elt_inner_prod-and-dual_inn.pa" rel="noreferrer" target="_blank">http://elt_inner_prod-and-dual_inn.pa</a>>tch, the<br>
>         > optimization changed the order of floating-point inner<br>
>         products, which<br>
>         > will change the results. I<br>
>         > created celt_inner_prod_neon_float_c_simulation()<br>
>         > and dual_inner_prod_neon_float_c_simulation() to simulate the<br>
>         order<br>
>         > floating-point operations in NEON optimization and compare their<br>
>         > results. Sorry that I cannot bond the distance between original C<br>
>         > function and NEON function to any giving reasonable small<br>
>         number or<br>
>         > ratio. It's easy to create an input which 0 and 1,000 are both<br>
>         correct<br>
>         > results by just manipulating the inner product order.<br>
>         ><br>
>         > The total speed gain is about 1.0% for fixed-point encoder,<br>
>         and 1.8% for<br>
>         > floating-point encoder, in Complexity 8, tested on my Chromebook.<br>
>         ><br>
>         > Thanks,<br>
>         > Linfeng<br>
>         ><br>
>         ><br>
>         > _______________________________________________<br>
>         > opus mailing list<br>
>         > <a href="mailto:opus@xiph.org" target="_blank">opus@xiph.org</a> <mailto:<a href="mailto:opus@xiph.org" target="_blank">opus@xiph.org</a>><br>
>         > <a href="http://lists.xiph.org/mailman/listinfo/opus" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/opus</a><br>
>         <<a href="http://lists.xiph.org/mailman/listinfo/opus" rel="noreferrer" target="_blank">http://lists.xiph.org/mailman/listinfo/opus</a>><br>
>         ><br>
><br>
><br>
><br>
</blockquote></div></div>