[LAU] No batch processing on Linux?

[Joel Roth]

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