On Thu, Mar 1, 2012 at 5:52 PM, Tom Rondeau <[email protected]> wrote:
> On Mon, Feb 27, 2012 at 11:01 AM, Tom Rondeau <[email protected]> wrote: > >> On Thu, Feb 23, 2012 at 9:08 PM, Nowlan, Sean < >> [email protected]> wrote: >> >>> Hi Tom,**** >>> >>> ** ** >>> >>> I tested with your merged branch. No segfault and same tests fail as >>> expected.**** >>> >>> ** ** >>> >>> I noticed several weird numbers in the orc results. Some of them >>> correspond to the failed cases. Do you know what is causing these? Printf >>> formatting issue? Hitting bounds of float type and wrapping around? >>> Relevant output: >>> >> >> So these test results are really interesting. The time results are one >> thing, but it might be that the numerical results you pointed out are >> hopefully easy to fix. In the volk_32fc_s32f_magnitude_16i_a block, it >> could be an issue with rounding. At first, I was thinking it was the >> direction of the rounding operation, but the documents from ARM say that >> the only mode is to round to nearest neighbor and that other modes are >> disabled (which is what we've set the SSE to, as well). Perhaps instead of >> truncation when converting to 16-bit shorts it rounds first. >> >> The 32fc_x2_multiply_32fc_a kernel looks like all of the numbers are >> correct. This is probably just a precision thing and we're asking for the >> numbers to be exact for way too many decimal places. >> >> Hopefully I'll get access to an E100 soon to look into this more. >> >> Tom >> > > Well, I can't seem to make anything out of those errors. They just don't > make sense. Especially the volk_32fc_x2_mutliply_32fc_a, which gives what > look like are the exact same results, but the tests fail. This even happens > when I turn the tolerance way up. > > When I run volk_profile, the same tests fail in the same way. Also, the > timing numbers still don't make sense, even when running much longer tests. > > Now, the good news is that after running volk_profile, those failed tests > are never selected for use. So when using Volk, these errors will never > effect the system at runtime. It's too bad, since we won't benefit from the > speedup of Orc, but I don't think the current blocks in GNU Radio make use > of these particular blocks, anyways. > > I was also getting an new error running make test in gr-core-test-all. Is > anyone else seeing this? > > Tom > I just recompiled the gr-core-test-all and the error went away. I'm not entirely happy about that, but until I can recreate it, I think it's time to declare success and walk away... Tom > RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a**** >>> >>> generic completed in 42.47s**** >>> >>> orc completed in 3.10883e-39s**** >>> >>> Best arch: orc**** >>> >>> --**** >>> >>> RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2_a**** >>> >>> generic completed in 17.28s**** >>> >>> orc completed in -3.90577e+11s**** >>> >>> Best arch: orc**** >>> >>> --**** >>> >>> RUN_VOLK_TESTS: volk_32fc_s32f_magnitude_16i_a**** >>> >>> generic completed in 4.37s**** >>> >>> orc completed in 1.35136e+09s**** >>> >>> offset 1107 in1: 29281 in2: 29282**** >>> >>> offset 1187 in1: -27601 in2: -27600**** >>> >>> offset 1522 in1: -31248 in2: -31249**** >>> >>> offset 2396 in1: 26146 in2: 26145**** >>> >>> offset 2486 in1: 25394 in2: 25393**** >>> >>> offset 4084 in1: 16452 in2: 16451**** >>> >>> offset 5052 in1: 28692 in2: 28691**** >>> >>> offset 5296 in1: 30869 in2: 30868**** >>> >>> offset 5467 in1: -32706 in2: -32705**** >>> >>> offset 6388 in1: 19556 in2: 19557**** >>> >>> volk_32fc_s32f_magnitude_16i_a: fail on arch orc**** >>> >>> Best arch: generic**** >>> >>> --**** >>> >>> RUN_VOLK_TESTS: volk_32fc_magnitude_32f_a**** >>> >>> generic completed in 35.24s**** >>> >>> orc completed in 6.93125e+10s**** >>> >>> Best arch: generic**** >>> >>> --**** >>> >>> RUN_VOLK_TESTS: volk_32fc_x2_multiply_32fc_a**** >>> >>> generic completed in 52.66s**** >>> >>> orc completed in -3.4978e+12s**** >>> >>> offset 3 in1: 0.382086 in2: 0.382086**** >>> >>> offset 4 in1: 0.496706 in2: 0.496706**** >>> >>> offset 8 in1: 0.170967 in2: 0.170967**** >>> >>> offset 10 in1: 0.165878 in2: 0.165878**** >>> >>> offset 14 in1: 0.398192 in2: 0.398192**** >>> >>> offset 15 in1: 0.492358 in2: 0.492358**** >>> >>> offset 17 in1: 0.568251 in2: 0.568251**** >>> >>> offset 19 in1: 0.0630723 in2: 0.0630723**** >>> >>> offset 20 in1: 0.251459 in2: 0.251459**** >>> >>> offset 22 in1: 0.348539 in2: 0.348539**** >>> >>> volk_32fc_x2_multiply_32fc_a: fail on arch orc**** >>> >>> offset 0 in1: 0.140486 in2: 0.140486**** >>> >>> offset 1 in1: 0.691375 in2: 0.691375**** >>> >>> offset 5 in1: 0.63745 in2: 0.63745**** >>> >>> offset 11 in1: 0.644697 in2: 0.644697**** >>> >>> offset 14 in1: 0.858205 in2: 0.858205**** >>> >>> offset 15 in1: 0.94011 in2: 0.94011**** >>> >>> offset 16 in1: 0.490713 in2: 0.490713**** >>> >>> offset 18 in1: 0.190573 in2: 0.190573**** >>> >>> offset 19 in1: 0.0226408 in2: 0.0226408**** >>> >>> offset 20 in1: 0.895774 in2: 0.895774**** >>> >>> volk_32fc_x2_multiply_32fc_a: fail on arch orc**** >>> >>> offset 1 in1: 0.524585 in2: 0.524585**** >>> >>> offset 2 in1: 0.236218 in2: 0.236218**** >>> >>> offset 6 in1: 0.733853 in2: 0.733853**** >>> >>> offset 9 in1: 0.290247 in2: 0.290247**** >>> >>> offset 11 in1: 0.529422 in2: 0.529422**** >>> >>> offset 12 in1: 0.180218 in2: 0.180218**** >>> >>> offset 14 in1: 0.496568 in2: 0.496568**** >>> >>> offset 15 in1: 0.0297472 in2: 0.0297472**** >>> >>> offset 19 in1: 0.351138 in2: 0.351138**** >>> >>> offset 20 in1: 0.300737 in2: 0.300737**** >>> >>> volk_32fc_x2_multiply_32fc_a: fail on arch orc**** >>> >>> Best arch: generic**** >>> >>> ** ** >>> >>> Sean**** >>> >>> ** ** >>> >>> *From:* [email protected] [mailto:[email protected]] *On Behalf >>> Of *Tom Rondeau >>> *Sent:* Thursday, February 23, 2012 11:18 AM >>> >>> *To:* Nowlan, Sean >>> *Cc:* Nick Foster; [email protected] >>> *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report**** >>> >>> ** ** >>> >>> On Wed, Feb 22, 2012 at 10:19 PM, Nowlan, Sean < >>> [email protected]> wrote:**** >>> >>> I confirmed this works on E100 insofar as I no longer get a segfault on >>> volk_32fc_s32fc_multiple_32fc_a. But volk_32fc_s32f_magnitude_16i_a and >>> volk_32fc_x2_multiply_32fc_a still fail as expected.**** >>> >>> **** >>> >>> Sean**** >>> >>> ** ** >>> >>> ** ** >>> >>> Sean,**** >>> >>> I just merged Nick's branch into my safe_align branch. Can you check >>> that one out and test when you get a chance? I just want to make sure we're >>> all on the same branch here. And please post the output of 'ctest -V -R >>> volk'.**** >>> >>> ** ** >>> >>> Thanks!**** >>> >>> Tom**** >>> >>> ** ** >>> >>> **** >>> >>> **** >>> >>> *From:* [email protected] [mailto:[email protected]] *On Behalf >>> Of *Tom Rondeau >>> *Sent:* Tuesday, February 21, 2012 6:49 PM >>> *To:* Nick Foster >>> *Cc:* Nowlan, Sean; [email protected]**** >>> >>> >>> *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report**** >>> >>> **** >>> >>> On Tue, Feb 21, 2012 at 6:43 PM, Nick Foster <[email protected]> wrote:**** >>> >>> Tom, Sean,**** >>> >>> **** >>> >>> There's a couple of things here. First, the >>> Orc volk_32fc_s32f_magnitude_16i_a function is rounding differently than >>> the generic versions on E100 for some reason. Not fatal, totally usable, >>> but it makes the QA code fail. Second, the volk_32fc_x2_multiply_32fc_a >>> looks like it's working fine but the thresholds are too close in the >>> comparison function, which is strange because it uses the same threshold I >>> use everywhere else. I'll keep looking into that. In any case, they're fine >>> for use in Volk as-is.**** >>> >>> **** >>> >>> I think the segfault in volk_32fc_s32fc_multiply_32fc_a is being caused >>> by a bug in the profiler code as well. It's not correctly handling complex >>> scalars. The function itself doesn't actually work either, which doesn't >>> help, but it wasn't caught because the profiler code was buggy...**** >>> >>> **** >>> >>> Tom, I pushed a fix to my github under "volk_fix". For now I've disabled >>> volk_32fc_s32fc_multiple_32fc_a since I can't figure out a clean way to get >>> it to work under Orc; I had a misunderstanding of how float parameters are >>> handled inside array operations. I also added complex scalar handling. I'll >>> keep looking into solving this one for real but this will get things >>> working for now.**** >>> >>> **** >>> >>> --n**** >>> >>> **** >>> >>> Nick,**** >>> >>> Thanks a ton for working on this. I'll merge your branch asap.**** >>> >>> **** >>> >>> Tom**** >>> >>> **** >>> >>> **** >>> >>> On Sat, Feb 18, 2012 at 1:05 PM, Tom Rondeau <[email protected]> wrote: >>> **** >>> >>> On Fri, Feb 17, 2012 at 6:04 PM, Nowlan, Sean < >>> [email protected]> wrote:**** >>> >>> Don’t know how helpful these are, but here you go.**** >>> >>> **** >>> >>> Sean**** >>> >>> **** >>> >>> Sean,**** >>> >>> It looks like a couple of functions are failing from the stdout:**** >>> >>> **** >>> >>> volk_32fc_s32f_magnitude_16i_a: fail on arch orc**** >>> >>> volk_32fc_x2_multiply_32fc_a: fail on arch orc**** >>> >>> **** >>> >>> These are both the Orc implementations of the functions, which seem to >>> work fine on my Intel processors. I don't have access to an OSX box or an >>> E100, so I can't really test this out. The files you sent me don't (appear >>> to) tell me what the real problem is.**** >>> >>> **** >>> >>> We'll need some other brave soul out there who can dig into these issues >>> on the platforms for us.**** >>> >>> **** >>> >>> Thanks,**** >>> >>> Tom**** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> *From:* [email protected] [mailto:[email protected]] *On >>> Behalf Of *Tom Rondeau >>> *Sent:* Friday, February 17, 2012 5:25 PM >>> *To:* Nowlan, Sean >>> *Cc:* Nick Foster; [email protected]**** >>> >>> >>> *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report**** >>> >>> **** >>> >>> On Fri, Feb 17, 2012 at 5:11 PM, Nowlan, Sean < >>> [email protected]> wrote:**** >>> >>> I built Tom’s safe_align branch on E100 and ran volk_profile. It >>> segfaulted on “RUN_VOLK_TESTS:volk_32fc_s32fc_multiply_32fc_a. I’ll get a >>> stack trace for you.**** >>> >>> **** >>> >>> Sean**** >>> >>> **** >>> >>> Really interesting that it's the same block. Hopefully, it's a single, >>> simple fix. I'll look into it when you can get me the stack trace.**** >>> >>> **** >>> >>> Thanks for reporting!**** >>> >>> Tom**** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> *From:* [email protected][mailto: >>> [email protected]] *On >>> Behalf Of *Tom Rondeau >>> *Sent:* Friday, February 17, 2012 2:33 PM >>> *To:* Nick Foster >>> *Cc:* [email protected] >>> *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report**** >>> >>> **** >>> >>> On Fri, Feb 17, 2012 at 2:30 PM, Nick Foster <[email protected]> wrote:**** >>> >>> On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez < >>> [email protected]> wrote:**** >>> >>> Thanks for the inputs! >>> >>> We are interested in determining the best architecture at instantation >>> time. What would be the best strategy? We though about running the >>> same operations several times for each architecture, measure the >>> results and use the fastest one for the processing blocks. Would this >>> be the right approach?**** >>> >>> **** >>> >>> Carles,**** >>> >>> **** >>> >>> Run volk_profile. It does exactly what you said, and writes the results >>> to ~/.volk/volk_config. Volk reads this file when it is involked (sorry) to >>> determine which particular function to execute. So all you do is run >>> volk_profile once on any given machine, and it's optimized.**** >>> >>> **** >>> >>> --n**** >>> >>> **** >>> >>> Carles,**** >>> >>> This is discussed on the webpage:**** >>> >>> http://gnuradio.org/redmine/projects/gnuradio/wiki/volk**** >>> >>> **** >>> >>> We'll be updating this as things progress with Volk, but the profiler >>> info is there already.**** >>> >>> **** >>> >>> Tom**** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> **** >>> >>> ** ** >>> >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
