[PD] [PD-announce] jit_expr 0.1: Just in time compiled expr/expr~/fexpr~

[Alex]

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.alex at 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 <porres at 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.alex at 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-announce at lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-announce
>>>
>>> _______________________________________________
>>> Pd-list at lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>>> stinfo/pd-list
>>>
>>>
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li
>> stinfo/pd-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20180318/a9328753/attachment.html>