On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
>
> If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. This can be mechanically checked by the compiler with the @nogc attribute.
>
> The point is even in C++ you should never ever do malloc/free in the audio thread, you might get away with it under low CPU load, but if you're running at high load it can barf the audio. So GC is just a variation on the same problem. Dont call malloc/free, dont use GC in anyway.
>
> You also have to make sure that the GC knows about your pointers, so if you have a pointer to something, make sure it's reachable from stuff the GC will scan. If it exists only on the stack in the audio thread the GC could collect it as it wont know it is still in use.
>
> Also see this...
>
> https://github.com/AuburnSounds/Dplug

I think you can make a callback thread to D work if you have a trampoline function and then call

thread_attachThis
rt_moduleTlsCtor

before calling the actual callback. Then the thread will be known to D runtime.

On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
> I'm working on virtual audio instruments and effect processors and they do their job in real-time. GC is luxury in this context. If I switched to D, I'd have to also switch from OOP to simple C-like structured programming and implement my own basic set of algorithms and data structures.

I work in audio effects, use no GC, and use OOP since TypeInfo is there.

You are right about basic set of algorithm and data structure.


> If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering.

That was how we did it for a while, the speed hit was immeasurable.

Generally, if a callback thread can own GC things, it needs to be registered and deregistered at exit.

The problem with the D runtime can be (depends on when):
- macOS compat in a shared lib
- D host hosting D client can be tricky



> The point is even in C++ you should never ever do malloc/free in the audio thread

Pet peeve, lot of practical audio applications do this (at startup) :)

You'll find mutexes in the audio thread in the most well known audio frameworks... all of them since spinlocks-style algorithms have worse worse-cases.

If the event is rare enough, it won't really matter and chasing it would be a lot of effort just to stay holier.

But it's a good talk topic so regularly people will berate other about how it's a bad thing.


> Also see this...
>
> https://github.com/AuburnSounds/Dplug

Note that we disabled the runtime (and GC) for reasons I cannot entirely collected, we've tried to enable it back several times and it's hard.

D is very fitting for audio.

On Tuesday, 30 June 2020 at 11:12:22 UTC, aberba wrote:
>
> It requires someone with C++ knowledge to start, then we'll take care of driving in more idioms. Like a GitHub wiki or something. The D wiki more appropriately for centralization.
>
> Anyone up for it?

D and C++ are VERY different languages:

- D objects have different construction sequences and teardown sequences. In C++ when you can name an object you are guaranteed it is constructed. Not in D.

- the meta-game of C++ meta-programming was template specialization for a long time, and is considered hard and something to avoid.

  For D it has been CTFE + string mixins for a long time, and is considered only moderately difficult.

- D uses DUB, modern dependency management that can make you maintain a lot more programs that you thought possible ^^. C++ culture is pretty much again this convenience.

- T.init is a valid D object, D destructors must handle T.init.

- destructor of heap objects is a big trap in D, perhaps the biggest surprise when coming from C++

- D collections do not necessarily own their elements, and are generally less complete than C++ collecions.

- D always has RTTI and Exceptions

- the C++ culture is much more conservative since regular people that wanted some modicum of sanity have fled to Java/C#/Python/anything else for _two decades_.

- mixed ownership (GC + manual) is more complicated than just scoped ownership; but ultimately liberating, and fast.

- ...so you have to actually know how the GC work.

On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu wrote:
> How to answer "why will yours succeed, when X, Y, and Z have failed?"
>
> https://www.youtube.com/watch?v=wIHfaH9Kffs
>
> Very insightful talk.

Herb Sutter is a national treasure, C++ has become bearable, nay even useful, under his stewardship and that is really saying something....

On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu wrote:
> How to answer "why will yours succeed, when X, Y, and Z have failed?"
>
> https://www.youtube.com/watch?v=wIHfaH9Kffs
>
> Very insightful talk.


Great talk. Similar to what I was trying to say in my DConf19 talk but in many ways better.

On Thursday, 2 July 2020 at 12:36:09 UTC, IGotD- wrote:
> On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
>>
>> If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. This can be mechanically checked by the compiler with the @nogc attribute.
>>
>> The point is even in C++ you should never ever do malloc/free in the audio thread, you might get away with it under low CPU load, but if you're running at high load it can barf the audio. So GC is just a variation on the same problem. Dont call malloc/free, dont use GC in anyway.
>>
>> You also have to make sure that the GC knows about your pointers, so if you have a pointer to something, make sure it's reachable from stuff the GC will scan. If it exists only on the stack in the audio thread the GC could collect it as it wont know it is still in use.
>>
>> Also see this...
>>
>> https://github.com/AuburnSounds/Dplug
>
> I think you can make a callback thread to D work if you have a trampoline function and then call
>
> thread_attachThis
> rt_moduleTlsCtor
>
> before calling the actual callback. Then the thread will be known to D runtime.

Sorry maybe I was unclear, I'm saying keep the real time thread hidden from D runtime & GC. Just make sure any GC memory referenced by the real time thread is also referenced in the threads/data that is known about by the runtime / GC. Or only pass the real time threa malloced memory.

On Thursday, 2 July 2020 at 13:03:12 UTC, Guillaume Piolat wrote:
> On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
>>
>> If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering.
>
> That was how we did it for a while, the speed hit was immeasurable.
>
> Generally, if a callback thread can own GC things, it needs to be registered and deregistered at exit.

I think my post was unclear, I'm saying keep the realtime thread hidden, just make sure any references are either duplicated somewhere reachable by the GC, or only give the real time thread malloced memory.

Chances are almost all the memory the audio thread has references to will be referenced elsewhere anyway. And those that arnt, say a message object passed through a queue, just use malloced memory.

On Thursday, 2 July 2020 at 10:21:19 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 28 June 2020 at 21:00:09 UTC, Dibyendu Majumdar wrote:
>> To be honest the analysis doesn't quite stack up. Because compatibility is not the reason for the success of Go, or Rust.
>
> I think that's a misinterpretation of what was said.  Compatibility is not a reason for success -- but the _absence_ of sufficient compatibility will always lead to failure.
>

So why was Java successful? It was not compatible with an existing language.
Neither Rust nor Go are compatible with C++.
Rust, D and Go are all compatible with C in some sense.

Basically Herb is claiming to succeed a language must be able to be a drop in replacement for C++ in a mix-match way. I think it is a fallacy.

There is no single recipe that will make a language successful.

On Thursday, 2 July 2020 at 18:22:54 UTC, Dibyendu Majumdar wrote:
>
> So why was Java successful? It was not compatible with an existing language.
> Neither Rust nor Go are compatible with C++.
> Rust, D and Go are all compatible with C in some sense.
>
> Basically Herb is claiming to succeed a language must be able to be a drop in replacement for C++ in a mix-match way. I think it is a fallacy.
>
> There is no single recipe that will make a language successful.

It's funny nobody has mentioned ease of use. Why is Java so popular? I'd say it's easy to use among other things. Why is Python so popular? Because it is easy to use and many can quickly learn it. Why is C++ so popular? It is or at least has been easy to use in its domain, at least if you use it conservatively and do not dig too deep into its language features.

Ease of use is a big factor.

On Mon, 2020-06-29 at 15:45 +0000, Dagmar via Digitalmars-d-announce wrote:
> On Monday, 29 June 2020 at 12:17:57 UTC, Russel Winder wrote:
> > Of course C++ is now really a niche language used by those who still use it and do not move on to more modern languages!
> 
> I am a C++ developer. I do want to move to a modern language, but there is no one that fits my needs.

So stick with C++? Changing language is not always the right choice. But it is a very context dependent decision.

> Rust has a very promising ownership-borrowing concept but the lack of OOP and its awful syntax (mostly because of lifetimes) make it a no go for me.

In the classic terminology, Rust is object based not object oriented. The question is whether inheritance is crucial for the application. Clearly inheritance is crucial to GTK, so the gtk-rs folk have created an inheritance system in Rust.

In my experience, unless you are writing a library type, if your code has lifetime variables then "you are doing it wrong". As soon as I stopped trying to use any lifetime variables in my Rust applications it all got a lot easier. Of course for library code that has to worry about lifetimes, they are needed.

> Go is just an oversimplified language. No generics/teplates in 2020, seriously?

Actually the Go core team are very serious about not having generics in Go. Despite the plethora of proposals, none have really made it. I do wonder if often the objections to a proposal are more along the lines of "we didn't think of that so it is not going in".

I think there will eventually be generics in Go, but I have no idea when. To be open, I have stopped using Go. Not so much because of the language, but because the GTK and GStreamer bindings are somewhat second rate.

> D has a GC. If you turn it off you lose dynamic/associative arrays, classes, probably something else. Why would I even want to use such language at all? It's much easier to stay with C++ this way, since it has lots of C/C++ libraries, IDEs, tools, broad community, support of big companies.

Or use Rust. ;-)

[…]
> C++20 is a big improvement at least because of concepts, coroutines, and ranges.

I can't say I will be tempted back to C++, the GTK and GStreamer bindings are a bit second rate. Having got into D and Rust for doing my desktop applications, I am not going back.

[…]
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk