Re: Re: Announce: scnim - Write SuperCollider UGens in Nim (Proof of Concept)

Nice work, Carlo! Do you know if Nim provides guarantees about realtime
properties (e.g. no malloc) in the generated C++ code?

Another cool project worth mentioning: UGens in Rust:
http://www.andrewchristophersmith.com/2015/01/01/implementing-a-supercollider-external-in-rust/

Tom


On Sat, Mar 10, 2018 at 11:38 AM, <[email protected]> wrote:

> This is cool Carlo, thanks for sharing! If you get it into a state where
> you feel it's polished we could add a link to the website.
>
> > Nim is a bit different than most contenders because it actually generates
> > (at your option) C or C++ code, and that code is fairly readable.
>
> In fact, the original C++ compiler implementation transpiled into C. :)
>
> -Brian
>
> On Sat, Mar 10, 2018 at 10:50 AM, <carlo-3+kk896uEWp9MqFnZXqmrwC/[email protected]> wrote:
>
>> >Hi Carlo,
>> >
>> >this is an exciting project, thanks for sharing. Nim seems to be an
>> >interesting language as well. A while ago, I thought about something
>> >like this with Scala Native (http://www.scala-native.org/en/latest/),
>> >although I had considered rather to see how to difficult it would be to
>> >implement part of the server API, rather than writing UGens that could
>> >then be linked back into scsynth. Your documentation will be very useful
>> >for similar attempts. Have you gathered any insight into the performance
>> >of using Nim for the UGens?
>> >
>> >best, .h.h.
>>
>> Pleasure!
>>
>> Nim is a bit different than most contenders because it actually generates
>> (at your option) C or C++ code, and that code is fairly readable. Below is
>> Nim's C++ result of the "next" procedure. The scary-looking stuff at the
>> bottom is just explicit type casts that Nim insist you do, and those have
>> zero impact. The rest is just a loop in C, and those have been tinkered
>> with
>> by compiler optimizers for 30 years. So I think we can safely say that if
>> you use the same rules to write UGens in Nim compared to C++ (don't
>> allocate
>> memory, use linear data structures like arrays), there is no (zero, none)
>> performance hit.
>>
>> float* input = (*(*unit).mInBuf);
>> float* output = (*(*unit).mOutBuf);
>>   NI32 i;
>>   i = (NI32)0;
>>   NI32 res = ((NI32) 0);
>>   {
>>     while (1) {
>>       if (!(res <= numSamples)) goto LA3;
>>       i = res;
>>       (*((float*) ((NI)((NU64)(((NI) (ptrdiff_t) (output))) +
>> (NU64)((NI)(((NI) (i)) * ((NI) 4))))))) = (*float*) ((NI)((NU64)(((NI)
>> (ptrdiff_t) (input))) + (NU64)((NI)(((NI) (i)) * ((NI) 4)))))));
>>       res += ((NI) 1);
>>     } LA3: ;
>>   }
>> }
>>
>> The same applies to sharing data- in this case, the input buffer is
>> created
>> in scsynth in C++, passed to Nim-generated C++ code, worked on, and
>> returned- nothing is copied anywhere or restructured or anything. You can
>> look at Nim as tool to help you write efficient C or C++ code. The price
>> you
>> pay is in build time and understanding how to write the interface- but
>> once
>> it's all compiled, you get the same CPU instructions and the same memory
>> layout, so you get the same performance.
>>
>>
>>
>>
>>
>> --
>> Sent from: http://new-supercollider-mailing-lists-forums-use-these.
>> 2681727.n2.nabble.com/SuperCollider-Developers-New-Use-this-f2681767.html
>>
>> _______________________________________________
>> sc-dev mailing list
>>
>> info (subscription, etc.): http://www.birmingham.ac.uk/fa
>> cilities/ea-studios/research/supercollider/mailinglist.aspx
>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
>>
>
>