On Mon, Mar 10, 2014 at 2:32 PM, Abhishek Bhowmick <abhowmic...@gmail.com> wrote: > > > > On Mon, Mar 10, 2014 at 10:04 PM, West, Nathan <n...@ostatemail.okstate.edu> > wrote: >> >> On Mon, Mar 10, 2014 at 9:33 AM, Abhishek Bhowmick >> <abhowmic...@gmail.com> wrote: >> > Hello, >> > I would like to clarify some things : >> > >> > 1. I feel it is tough to beat spiral implementations through manual >> > vectorization, performance wise. If so, is readability the prime and >> > only reason for using intrinsics manually, and hence of value to the >> > community ? >> >> Spiral is very good, and it would be hard to beat for the areas that >> Spiral covers. However, Spiral only covers DFTs and Viterbi decoders. >> >> > >> > 2. What is currently the state of adding support for sse4, neon in >> > stock volk kernels (project ideas page mentions some work is under >> > way) ? Would be great if someone who is working on this already shares >> > his branch, so that I may know how much/if any work is needed in this >> > before moving on to avx. Of course, new kernels will need support for >> > all. >> >> The different versions of SSE are very similar and mostly don't really >> replace each other, but are more complementary to each other. As for >> NEON, I've been doing work on adding NEON support for many of the >> currently existing kernels. It will be public (hopefully) around May. I'd >> like to see focus on new kernels at this point, with AVX2 support for >> some existing kernels thrown in if time permits. >> >> > >> > 3. How feasible/useful does it sound to incorporate the newly added >> > idea of 'turbo equalizer' within the ofdm system ? Are the >> > requirements of the proposed equalizer overkill for the ofdm blocks? >> >> I'm glad Martin answered that one :-) I'm pretty excited about a potential >> OFDM frame detection kernel. > > > I am afraid my question didn't come out correctly. I was referring to the > latest > project idea addition to the wiki page on 'turbo equalizer', supposedly by > openairinterfaces. I am not sure if I can incorporate that into my original > proposal, or does that go as a separate proposal for openair... > > And if yes, whether the throughput requirements for their applications are > much > higher than what we can get away with on in-tree ofdm. > >> >> >> > >> > Abhishek >> > >> >> Nathan > > > -- > Regards; > Abhishek Bhowmick, > Senior Undergraduate, > Department of Electrical Engineering, > IIT Bombay.
Ah! So there was a slight miscommunication. Yes, porting the OpenAirInterfaces SIMD code to VOLK is a good option as well. The turbo channel coder/decoder is part of that. I've *briefly* looked at the code to see what is currently there, and it's my understanding that the work involved will be to write generic C implementations of vectorized code where the generic version does not exist. Beyond that porting to newer/different ISAs (AVX or NEON depending on your preference and hardware availability). I think Florian is on the gr-discuss mailing list, but I've CCed him to hopefully provide more details as he's more familiar with the original code base. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio