Oh, and a quick note, these have no relation to the max/msp jitter objects. The name collision is unfortunate but "jit" very accurately describes what is happening. If someone has a better namespace prefix to recommend I am open to it. Though maybe the pd community is fine with this collision?
-Alex On Sun, Mar 18, 2018 at 9:34 AM, Alex <x37v.a...@gmail.com> wrote: > Alexandre, > > I don't think it has had enough usage to be called "stable" yet, but I > could see that happening down the line. In fact, I could see eventually JIT > compiling the entire DSP graph.. but of course that would be significant > work. At this point I just need more people to try it out and make sure it > would be up to it. > > -Alex > > > On Sun, Mar 18, 2018 at 9:23 AM, Alexandre Torres Porres <por...@gmail.com > > wrote: > >> 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? >> >> cheers >> >> 2018-03-18 13:08 GMT-03:00 Alex <x37v.a...@gmail.com>: >> >>> jit_expr is a clone of the pure data expr/expr~/fexpr~ objects. It >>> just-in-time compiles its expressions so they should be much more optimized >>> than the original. If all works as designed, they should use less CPU than >>> the equivalent vanilla, non-expr, patching and have a significant CPU >>> advantage over the original expr objects. >>> >>> I've put the external, compiled for 64-bit Mac-OS and 64-bit Linux, up >>> on deken: in pd, go to help menu, find externals, search for "jit_expr". >>> >>> After installing the external you should be able to change any of your >>> expr family of objects to just in time compile by loading the library, >>> [declare -lib jit_expr], and then prefixing the object name with "jit/", >>> for example [jit/fexpr~ $x1[0] + $y1[-1]]. >>> >>> I believe they are feature complete with the originals but I'd love to >>> know if there is anything that I'm missing or any bugs that you discover. >>> I'm not exactly sure how to profile pure data patches. If anyone has a >>> good approach or original expr~/fexpr~ patches that use a lot of CPU you >>> can share, let me know. >>> >>> Compiling in the object takes a little bit of time, so the initial >>> instantiation of the object/expression will be a bit slower than the >>> original, FYI. >>> >>> Please report any issues here: >>> https://github.com/x37v/jit-expr/issues >>> >>> >>> BTW, if you're curious to see the llvm assembly produced by your >>> expression, send the |print( message into the left most inlet of your >>> object then check out the pd console. >>> >>> >>> I would love help building Windows and 32-bit Linux versions of the >>> externals. I'm guessing we could also do raspi/arm builds but we'd need >>> some changes to the source code as it uses llvm and explicitly generates >>> code for x86 right now. >>> >>> The source code can be found in the git repo: >>> https://github.com/x37v/jit-expr >>> >>> -Alex Norman >>> >>> _______________________________________________ >>> Pd-announce mailing list >>> pd-annou...@lists.iem.at >>> https://lists.puredata.info/listinfo/pd-announce >>> >>> _______________________________________________ >>> Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >>> stinfo/pd-list >>> >>> >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >> stinfo/pd-list >> >> >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
