|
| From: | Abhishek Bhowmick |
| Subject: | Re: [Discuss-gnuradio] Google Summer of Code 2014 applicant : Optimization with VOLK |
| Date: | Wed, 19 Mar 2014 21:23:29 +0530 |
Can you enter this through Melange? It should be sufficient to link to
your PDF/repo on Melange.
It's good to see you were able to get control port and oprofile results.
On Sat, Mar 15, 2014 at 4:37 AM, Abhishek Bhowmick
<address@hidden> wrote:
> Here is the link for my first proposal draft :
> https://github.com/abhowmick22/GSoc14-Proposal
>
> I will keep revising it. Seeking feedback in meantime. Thanks all.
>
> Abhishek
>
>
> On Sat, Mar 15, 2014 at 3:37 AM, Martin Braun <address@hidden>
> wrote:
>>
>> On 14.03.2014 19:27, Abhishek Bhowmick wrote:
>>>
>>> Hi,
>>> So, according to some suggestions, I looked into how I can potentially
>>> use better signal processing for the OFDM receiver. I was thinking of a
>>> LS estimator with higher order interpolation or an MMSE estimator for
>>> the channel estimator part. Also, a MMSE-DFE or Viterbi equalizer. These
>>> will need matrix operations and other computations, which can
>>> potentially be developed into new volk kernels.
>>> 1. Are the computational complexities involved feasible in the current
>>> framework ?
>>> 2. Though they can give better BER in adverse channel conditions, can
>>> they do deliver more in terms of throughput/performance?
>>> 3. Is it a good idea to include such implementations alongside doing new
>>> volk kernels in the same proposal ?
>>
>>
>> Abishek,
>>
>> at this point, please just put together a proposal and upload it so we can
>> make sure it gets into Melange in time.
>>
>> M
>>
>>>
>>> Abhishek
>>>
>>>
>>> On Wed, Mar 12, 2014 at 3:38 AM, Florian Kaltenberger
>>> <address@hidden
>>> <mailto:address@hidden>> wrote:
>>>
>>> Hi Nathan and Abhishek,
>>>
>>>
>>> On 10/03/2014 23:22, West, Nathan wrote:
>>>>
>>>> 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.
>>>
>>> I only joined this mailing list recently, so I probably missed a
>>> part of the discussion. Let me summarize briefly what
>>> OpenAirInterface can provide. We have optimized SIMD (SSE4)
>>> implementations of the LTE turbo encoder and decoder as well as the
>>> LTE tail-biting Viterbi encoder and decoder. We also have the 802.11
>>> Viterbi encoder and decoder. The only functions for which we have
>>> generic non-vectorized functional equivalents is the LTE turbo
>>> decoder.
>>> I am not sure I understand why it is necessary to write generic
>>> versions for the already optimized SIMD code. My idea was to port
>>> the optimized SIMD code from OpenAirInterface to VOLK, such that is
>>> can be used by GR applications. I am not familiar with VOLK (yet)
>>> but this might just be as easy as writing a wrapper function.
>>> As Nathan suggested, the more interesting part is probably to
>>> upgrade the code to AVX2 or similar.
>>>
>>> Cheers,
>>> Florian.
>>>
>>>
>>>
| [Prev in Thread] | Current Thread | [Next in Thread] |