Re: [Discuss-gnuradio] More On Ticket 141

[Eric Blossom]

On Tue, Mar 06, 2007 at 11:04:43AM -0500, Michael Dickens wrote:
> On Mar 5, 2007, at 11:21 PM, Eric Blossom wrote:
> >you made two changes:
> >
> >  -g1 -> -g
> >  -O1 -> -O2
> >
> >Does -g -O1 work on PPC-OSX?
> >
> >We really want to "turn down" the level of optimization used while
> >compiling the SWIG stuff.  The SWIG stuff is not performance critical,
> >and using a lower level of optimization speeds up the compilation.
> 
> Here are the results of "time make -j3" from compiling with different  
> options (as listed; run only once, so not statistically significant  
> but still useful).  After compiling, I run "make check" and it either  
> works ("+") or doesn't ("-") in the sense of ticket:141.
> 
> 1) "-g -O2"
> Intel +: 514.437u 225.594s  7:28.93 164.8%       0+0k 159+2045io 0pf+0w
> PPC   +: 790.567u 437.716s 11:45.85 174.0%       0+0k  12+2514io 0pf+0w
> 
> 2) "-g1 -O2"
> Intel +: 511.048u 227.164s  7:23.83 166.3%       0+0k 115+2063io 0pf+0w
> PPC   +: 779.509u 435.124s 11:35.84 174.5%       0+0k   1+2317io 0pf+0w
> 
> 3) "-g -O1"
> Intel +: 485.501u 229.842s  7:20.63 162.3%       0+0k   0+2061io 0pf+0w
> PPC   -: 729.166u 436.894s 11:10.46 173.9%       0+0k   0+2395io 0pf+0w
> 
> 4) "-g1 -O1"
> Intel +: 481.946u 229.679s  7:11.07 165.0%       0+0k   0+1975io 0pf+0w
> PPC   -: 724.620u 443.608s 11:10.59 174.2%       0+0k   0+2394io 0pf+0w
> 
> Thus for PPC-OSX, (2) is the best choice while for Intel-OSX (4) is  
> the best.  I've modified configure.ac to handle those cases, and it  
> works fine on both PPC- and Intel-OSX for me.  Again, it won't affect  
> any OS except Darwin.
> 
> NOTE:  On PPC-OSX, those that work ("+") always get the following  
> failure:
> +++++++++++++++++++++++++
> FAIL: test_pll_refout (__main__.test_sig_source)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "./qa_pll_freqdet.py", line 158, in test_pll_refout
>     self.assertFloatTuplesAlmostEqual (expected_result, dst_data, 4)
>   File "/GNURadio/t141/gnuradio-core/src/python/gnuradio/ 
> gr_unittest.py", line 86, in assertFloatTuplesAlmostEqual
>     self.assertAlmostEqual (a[i], b[i], places, msg)
> AssertionError: 98.939748723299999 != 98.939695362490014 within 4 places
> +++++++++++++++++++++++++
> 

Thanks for running all the experiments.

Regarding the failure in test_pll_refout, I suspect that this depends
on minor differences in floating point implementations.  E.g.,
x87 FPU, scalar SSE, or Altivec.   I think we should just ease the
criterion on the test.  Will you please change the "4" to a "3"?

With regard to the real failures in the two -O1 cases, that looks like
a genuine compiler bug.

Eric