IPPDSP.jl: a wrapper for Intel's IPP DSP library

[Jay Kickliter]

TLDR: A package that that wraps IPP's signal processing library (which is very fast)

The long story is that Radio.jl needs some DSP functionality not yet provided by DSP.jl. For the last several months, in my spare time, I've been trying learn the basics of multirate signal processing. I'm mediocre at best when it comes to understand theory heavy books. So I eventually realized that before I could contribute to DSP.jl, I needed some sort of baseline to compare my Julia filtering code against.  The programmers at my company rely heavily on IPP, so that's how I came up with IPPDSP. I had never used IPP myself, and have been astonished at how fast it is.

Unfortunately it's not free. Intel does allow developers with paid licenses to redistribute the libraries. My gut tells me that it doesn't apply to something like this package, but haven't found anything that strictly prohibits it. Unless I get conformation that I can redistribute any of the libraries, users of this package will need to have their own copy. You can download a 30 day trial for free if you want to try it out.

My long term goal, if it is cool with DSP.jl's core-developers, it contribute some of the changes I need, primarily stateful single/multi-rate FIR filtering, in a way that would allow users to switch between IPPDSP.jl and DSP.jl with minimal changes to their code.

I'm open to comments and suggestions. I just wrote the documentation today, and had girlfriend edit it, but I'm sure there's still a bunch missing. I've only implemented a small fraction of libipps functionality, so if anyone needs the added speed of IPP, and wants to help, that would be awesome.

[João Felipe Santos]

It looks really good, I'll definitely check it out soon. I actually thought about writing a similar interface to Apple's vDSP functions in Accelerate (which is also not free). It will be really great if you manage to keep the APIs compatible with DSP.jl, so anyone can switch to IPPDSP if they feel so inclined. And contributions to DSP.jl coming from your work in IPPDSP will be welcome for sure!

Would you like us to add Radio.jl and IPPDSP.jl to the JuliaDSP organization, by the way?

--
João Felipe Santos

--
João Felipe Santos

--
You received this message because you are subscribed to the Google Groups "julia-dsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to julia-dsp+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jay Kickliter]

I always forget that in the software world there is more than one definite of free ( open source & 🍺). It might not be open, but the cool thing about vDSP is that it's installed on every Mac. It's funny that you mention writing a wrapper for it. I started off doing the same thing, but it doesn't have as many filtering functions as IPP. Are you still thinking about wrapping any of it? If so, let me know if want any help.

Radio is on hold for the moment, so lets not add it yet. It won't be ready until I at least add PSK demodulation. And by the time I strip all the DSP functions that DSP.jl already has, there won't be much left. It does a few things that are good candidates for transfer to DSP.jl:

• kaiserord: get the optimal length of kaiser windowed sinc filter
  
• firdes: design a filter of length n with a specified window
  
• wgn: generate white gaussian noise
• czt: chirp-z transform. It needs to be rewritten first, but I use it all the time for zooming in on radio signals.

Thanks for the encouragement, and let me know how I can help. I was at JuliaCon, and DSP was barely mentioned by anyone. I'd like to help change that.

[Jay Kickliter]

Here's some not very thorough filtering benchmarks. The notebook in the link doesn't show it, but the native Julia fir_filter seems be a bit faster than Base.filt that DSP.filt calls for small Ntap*Nsig.

[Simon Kornblith]

This is certainly interesting. It's good to see that firfilt() is faster than the naive approach, but it would be great to make it more competitive with IPP. I wonder what they do to get that performance.

Base.filt just uses time-domain convolution for FIR filters, and is defined here: https://github.com/JuliaLang/julia/blob/master/base/dsp.jl#L68. If your fir_filter is faster, it'd be great if you can submit a PR.

Simon

[Jay Kickliter]

Their policy is to not reveal implementation details, but I've seen a few slip-ups by their developers admitting to writing assembly routines and SIMD code. It also appears that they have different routines tuned for different processor generations.