Re: [LAU] No batch processing on Linux?

On Sat, Sep 25, 2010 at 11:24:26PM +0200, Arnold Krille wrote:
> On Saturday 25 September 2010 20:21:22 Joel Roth wrote:
> > On Sat, Sep 25, 2010 at 01:00:29PM +0200, Arnold Krille wrote:
> > > Porting parts of your python project to C/C++ is easy (think prototyping
> > > in python and port to compiled-language once the interface is finished
> > > and the optimizations begin).
> >
> > For optimizing perl, we have Devel::NYTProf, which
> > profiles the time spent in each subroutine. (As the name
> > suggests, the New York Times underwrote the development
> > costs.)
>
> Hm. The idea I mainly have in mind is not to optimize your python code, but
> prototype your app with its functionality in python and when all works as
> expected (more or less), port the time-critical parts to c/C++. Not because
> python is slow (it is compared to native asm) in general, but because it is
> definitely to slow for various tasks like audio.

That seems like a great way to develop applications.

I mention perl's profiler, because in developing Nama,
it was quite convenient.

I developed functions naively, without caching
provisions. When I noticed it was running slow for
hundreds of tracks, Devel::NYTProf showed me
exactly how many subroutine calls were taking
how much time.

Porting time-critical functions to c/C++ hasn't been
much issue for me, since I already use a speed
optimized engine for audio processing (Ecasound :-)

> And because python afaik still
> has the big interpreter lock, effectively suppressing any python multi-
> threading. Which you work around by re-implementing your heavy-math parts in C
> and run them outside the interpreter lock (but still from within threads
> created and managed from python)...

What, no native threads. Mock horror!

Best,

Joel
 
> Have fun,
>
> Arnold

-- 
Joel Roth
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user