discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimizati


From: Abhishek Bhowmick
Subject: Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK
Date: Tue, 25 Feb 2014 02:03:49 +0530

On Mon, Feb 24, 2014 at 9:00 PM, Tom Rondeau <address@hidden> wrote:
> On Mon, Feb 24, 2014 at 12:15 AM, West, Nathan
> <address@hidden> wrote:
>> On Sun, Feb 23, 2014 at 12:52 AM, Abhishek Bhowmick
>> <address@hidden> wrote:
>>> Hello,
>>> I have completed a Bachelor's degree in Electrical Engineering from IIT
>>> Bombay, India and will be joining a masters program in Computer Science in
>>> August. For the summer, I am interested in participating GSoC 2014 and GNU
>>> Radio is an organization where my background fits nicely.
>>>
>>> I went through the ideas page and was particularly interested in doing
>>> performance optimization with VOLK.
>>
>> Great to hear. Just keep in mind we have another ~13 hours before we
>> as an organization
>> know whether we were accepted or not.
>>
>>> After going through some online
>>> documentation about the library and the SDR'12 paper, I realised that
>>> following areas need work :
>>> 1. Profiling GNU radio code to identify new kernels and implement them for
>>> existing Intel SIMD extensions, also porting kernels to other ISA
>>> extensions.
>>> 2. Better testing of the effects of more complex scheduler logic on larger
>>> environments (beyond simple kernels)
>>> 3. Exploring extension of Volk to GPU ISAs, to leverage chips such as AMD
>>> Fusion (However, this seems to more research than software development)
>>>
>>> According to the GSoC proposal, point (1) seems to be the expectation. Given
>>> this, I would like some advice on how to go ahead looking for potential
>>> ideas (and some feedback on feasibility of the other ideas as well)
>>>
>>> My background : C++, Python, Signal Processing, Computer Architecture
>>>
>>> Thanks,
>>> Abhishek Bhowmick
>>>
>>
>> Abhishek,
>>
>> Right, so points 1 and 2 are what I had in mind when I wrote the idea
>> on our list. Point 3
>> is technically possible to do in VOLK, but probably not really worth
>> using GPUs in this way
>> since the transport costs would dwarf any acceleration from the
>> current VOLK kernel. That said,
>> there's nothing really wrong with a proposal that is on a research
>> area, but I do think we would want
>> code and something contributed back to the community at the end of the
>> project. Also, don't let that
>> prevent you from submitting a proposal about GPU programming if that's
>> what you're interested in, it's
>> probably just not best targeted for VOLK. My understanding of GSoC
>> proposals is that you can submit
>> any number,so you can submit one for doing some GPU acceleration and
>> another for something more
>> related to VOLK.
>
>
> I agree with Nathan that VOLK is probably not the right abstraction
> for GPUs. The Fusion concept with the GPU and GPP on the same die is
> compelling, but maybe too specific. There is another project called
> gr-gpu that's focusing on the GPU problem more generally.
>
>> So for points 1 and 2 it would be good to see a specific algorithm or
>> module that you think would
>> benefit from moving to VOLK, which would take some research on your
>> part. I think gr-atsc is a
>> good place to look for some acceleration gains, and it would be good
>> to see that application run
>> real time. One of the things I had in mind is accelerating OFDM frame
>> sync. Martin's ofdm_{rx,tx}
>> and gr-80211 are good examples where they use blocks that have VOLK
>> kernels in them to do the
>> sync, but that's somewhat inefficient because we move data in and out
>> of SIMD registers. Of course
>> there's the old trade-off of modularization and code re-use vs. speed.
>> I'd be glad to discuss this and
>> similar ideas more once we know we are accepted as an org. There's one
>> more possibility that recently
>> came up, but I'd like to wait until things are official before
>> recommending it (and I'll need to talk with
>> other interested parties).
>
> We're working with Andrew Davis on updating gr-atsc
> (https://github.com/glneo/gnuradio/tree/atscfixup). If you decide to
> focus on ATSC speedups with VOLK, look into that project instead of
> the one inside gnuradio (which will be deprecated).
>
> Tom
>

Firstly, congratulations on being accepted as a mentor organization.

Thanks for the pointers to gr-atsc and gr-80211. I have started
looking there as a
starting point. Are there similar modules which are undergoing volk
speedup fixes?
I am also trying to meet up with other people who have been using GNU radio
to identify potential modules for acceleration. As you are now a
mentor organization, I feel it's a good time for us to get into
detailed discussions.

>
>> At the moment the only mainstream ISA not being targeted is probably
>> AVX2, which has
>> some nice features for the type of kernels we're doing.  If you went
>> that route it would likely need add
>> protokernels to a pretty large number of kernels.
>>
>> Nathan

This also seems to be promising, though I guess it would require me to
come up to speed with AVX2 (which I would love to do). Could you
please elaborate
a little on the kind of beneficial features you have in mind ? I am
concerned that the
job of adding proto-kernels might turn out to be mundane/tedious ? Is
that a valid
concern ?

Abhishek



reply via email to

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