[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] More On Ticket 141

From: Michael Dickens
Subject: Re: [Discuss-gnuradio] More On Ticket 141
Date: Tue, 6 Mar 2007 11:04:43 -0500

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]