[PD] disable cores on linux to use as dedicated dsp

[Simon Iten]

interesting, bela uses this approach!

http://bela.io/#about


so it should not be that hard to adapt it for desktops and laptops


On 09/07/2016 08:01 PM, Giulio Moro wrote:
> I believe the solution to these things lies in using Xenomai or other 
> RT extensions for Linux. With Xenomai you take control of the 
> scheduler and you can have one process taking up an entire CPU, while 
> the Linux kernel waits ( or uses other CPUs).
>
> Giulio
>
>     ------------------------------------------------------------------------
>     *From:* Jonathan Wilkes via Pd-list <pd-list at lists.iem.at>
>     *To:* Simon Iten <itensimon at gmail.com>; Pd-List
>     <pd-list at lists.iem.at>
>     *Sent:* Wednesday, 7 September 2016, 18:50
>     *Subject:* Re: [PD] disable cores on linux to use as dedicated dsp
>
>     > On Wednesday, September 7, 2016 12:51 PM, Simon Iten
>     <itensimon at gmail.com <mailto:itensimon at gmail.com>> wrote:
>
>     > hi list,
>
>     > i recorded 3 times in a studio last year that uses a daw/pc
>     > interconnection by pyramix, basically it is a hacked windows
>     system,
>     > where one or two cores of a multicore cpu are completely hidden
>     from the
>     > system. these cores are then acessed directly by the daw and
>     used as a
>     > very powerful dsp. the system is incredible! lowest latencies, high
>     > trackcount, and the breakout to the adc/dac is a simple network
>     cable.
>
>     > see here for additional info:
>
>     > http://www.merging.ch/products/pyramix/masscore
>
>     > i since wondered if this would be a way to go for puredata? at
>     least on
>     > linux it seems very easy to deactivate a core (but i don't know
>     if it
>     > than can be used directly by a process) : echo 0 >
>     > /sys/devices/system/cpu/cpu1/online for core2 for example.
>
>
>     > is this a completely stupid idea? note that i have no idea how
>     hard it
>     > would be to implement something like this
>
>
>     > thanks for any insight
>
>
>     Hi Simon,
>     That quite an intriguing design.
>
>     It hurts my brain too much to try to assess the difficulty of such
>     an undertaking to
>     refactor Pure Data to this design.
>     So let me try a shortcut:
>
>     Inside d_ugen.c (which is essentially just dsp algos, so there
>     should be few if any
>     system calls) I see a t_getbytes call.  t_getbytes calls calloc.
>
>     With the design you linked to, do Pd devs have to reimplement
>     malloc?  If the answer
>     is yes, then I'd call this a massively difficult undertaking.  If
>     d_* relies on the
>     system calls, then you can bet x_*, m_*, s_*, and g_* do, too, and
>     to a much greater
>     extent.
>
>     If the answer is no, I'd like to learn more about the design.
>
>     -Jonathan
>
>     _______________________________________________
>     Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>     UNSUBSCRIBE and account-management ->
>     https://lists.puredata.info/listinfo/pd-list
>
>
>     _______________________________________________
>     Pd-list at lists.iem.at <mailto:Pd-list at lists.iem.at> mailing list
>     UNSUBSCRIBE and account-management ->
>     https://lists.puredata.info/listinfo/pd-list
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160907/2513c531/attachment.html>