[PD] sparse considerations about jit_expr (was: jit_expr 0.1: Just in time expr/expr~/fexpr~)

Marco Matteo Markidis mm.markidis at gmail.com
Sun Apr 1 02:28:11 CEST 2018


Dear list,

if this is stable, wouldn't it be a nice idea to propose it as an update to
> the expr~ family of objects? since it is basically an optimized clone?

basically it is an optimized clone, but we have to consider the
introduction of several (and heavy: llvm one for all) dependencies before
include it in the pd release.

> correct me if I'm wrong, but that means with this tool we now have
> something like gen~ in Max


i think that the introduction of a compiler could be usefull for the
introduction of a scripting language in pd that can work at the three
different time levels present in pd (control, audio and sample rate). for
example, in pic1 taken from [1] we can see a gen~ patch.  so i think that
jit_expr (and in general expr family) can read a text file, like the right
one in picture, and interpret it. in this case, one can avoid to write
externals and use jit_expr to compute the perform method. considering the
case of a noise generator, one in principle can have this pseudocode:
static int val;
$y1 = ((float)((val & 0x7fffffff) - 0x40000000)) *
            (float)(1.0 / 0x40000000);
val = val * 435898247 + 382842987;
the pseudocode i wrote is just a mix of usual expr syntax and usual C
syntax plus the problem of local variables where i use the static word.

> btw, I know there's Faust that works with Pd

the introduction of a jit compiler is usefull to faust-ize pd, in the sense
that optimizing [fexpr~] several filters that usually are done in faust can
be done in pd incrementing the possibility of using small block size.

> The name collision is unfortunate but "jit" very accurately describes what
> is happening.

honestly i do not like the namespace in pd, but i find this very usefull to
switch from expr family to jit_expr.

a final consideration about jit compilation: from my understanding of
multithreading in computer music, not so much apart [pd~] can be done
without breaking determinism. from one hand i see the possibility to
introduce a steal working scheduler that breaks the dsp graph in sub-graphs
and distribute them to threads (and divide some non-real time safe
computation between threads, like soundfiler object and in general array
operation); on other hand the possibility to jit-compile all the dsp graph
is very interesting because it should leave all the black magic to the
compiler and optimizing the patch reduces the need of parallelization.
finally a combination of jit-compilation plus automatic parallelization
would put this conversation on the heaven of computer music parallelization
:)

best,
marco

[1]: https://docs.cycling74.com/max7/vignettes/gen_overview

-- 
Ho cambiato l'indirizzo email in mm.markidis at autistici.org . Se non รจ un
problema, scrivimi a questo nuovo indirizzo email.

I changed my email address in mm.markidis at autistici.org . If it is ok for
you, please write me to this new email address.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180401/0c68395c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic1.png
Type: image/png
Size: 50661 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180401/0c68395c/attachment-0001.png>


More information about the Pd-list mailing list