[PD] Re: pure == slow, impure == fast ? was purepd

Mathieu Bouchard matju at artengine.ca
Wed Nov 23 03:56:23 CET 2005


On Sun, 20 Nov 2005, carmen wrote:

> its a nice ideal, but i cant help but think we'd end up with something
> performing more like ruby than a realtime media system if 'everything is
> an abstraction' and the core just defined syntax.

Funny, one of my early ideas when coding in Ruby has been that way too
much of the interpreter is coded in C and so that its builtin classes like
Array and Hash and String should be almost completely recoded in Ruby.  
I've rewritten those and yes, they were much slower, but then they could
also be hacked in ways that the C version couldn't easily be. E.g. imagine
if, from Pd, you could create a variant of Pd's [table] class such that it
supports methods "undo" and "redo" ! Well, I've done exactly the
equivalent of that in the Ruby world.

> maybe theres a way to byte-compile them down to get some of the
> performance back, a la .pyc or .elc...but that sounds more like a PhD
> project...

You don't need to make compilations to files. Those can remain in memory
and recompiled at each load (or each modification of a patch). Examples of
those are Perl, Tcl, YARV (Ruby2), and of course, the DSP in Pd/Max/jMax.

However, in PureData, the DSP is more readily optimisable than the message
system. In particular, the DSP system has been designed to be so: that was
rather natural, as it is a synchronous system with fixed bandwidth, so you
preallocate all the RAM you need for object-to-object communication, and
you need not do that again. Also, DSP does not have a prescribed order of
execution, so it's potentially reorderable if the compiler thinks it's
better to. DSP has many less runtime lookups because perform-funcs don't
send their DSP blocks explicitly, so that can be planned in advance (short
of Pd decompiling its externals at runtime...).

> awfully reminiscent of 'libtool'.. i guess instead of libtoolize you
> could have libtoolsize, or PurePdIze,

I suggest that we trick the authors of libtool into renaming it to
libstool. That's what should happen to a program that mostly just double 
the amount of diskspace required to compile a program. Sorry, I'm just 
feeling vengeful about my days of trying to use Linux on a 1.7 GB disk.

____________________________________________________________________
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
Freelance Digital Arts Engineer, Montréal QC Canada




More information about the Pd-list mailing list