November 27, 2015
On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:
> On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat
>> I don't really have a point to prove, but I'm really tired with people arguing that a language with GC can't possibly do real-time. It's not like you are unallowed to optimize.
>
> What if someone wants to use your plugin live? You think it is acceptable to have latency and jitter? What about glitches because your GC decides to run at the same time as all the other GC's?

I quoted both things because I think you missed the important part that he did, in fact, optimize the real time parts to avoid latency.
November 27, 2015
On Friday, 27 November 2015 at 16:54:11 UTC, Guillaume Piolat wrote:
> Exactly, that's like all the talk about "scaling" or "big data" on the Internet. Problems we wish we had.

All commercial websites can benefit from automatic scaling, load balancing and fully managed systems:

1. You get rid of the maintenance cost.

2. You can survive a DoS attack, or diminish impact of it.

3. You don't have to redesign the entire infrastructure as an emergency operation when you cross what you can run on a single server/database.

4. Solutions for scaling usually also includes reliability and data replication.

"big data" is often about being able to do things you could not do before.  Like log analysis. Which is relevant in some trivial domains, like multi-user games, where a single participant can generate a lot of data... I.e. try to figure out what game mechanics/levels works/don't work quantitatively. But yes, "big data" is probably overrated, although it can allow new ways of figuring out how to improve a system.

Your application looks cool, but I don't quite understand what kind of dynamic allocations you need after init?

Seems like you can afford to run all the audio on a OS-level real time thread. That is way different than a very computationally expensive application where you stream from a regular thread to a hard real time thread.

November 27, 2015
On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:
> On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat wrote:
>> [...]
>
> You have no idea what you are talking about! It is mentalities like yours that cause headaches for musicians and engineers who work with RT audio.
>
> [...]

Dude, you missed the point completely. He did all RT stuff without a GC, he said that the GC can be made irelevant by using some clever optimizations and using the tools the language provides.

I also suspect you don't really know how D's GC works.
November 28, 2015
On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:
>
> You have no idea what you are talking about! It is mentalities like yours that cause headaches for musicians and engineers who work with RT audio.
>
> Do you realize that even 5 ms of jitter can be felt by the listener and musician as being off? 5 ms of latency can be felt and 20ms is unacceptable.

"jitter" is not "latency", you don't have "5 ms" of jitter.

> What if someone wants to use your plugin live? You think it is acceptable to have latency and jitter?

https://yourlogicalfallacyis.com/strawman

Besides, noone reported anything like that, because there is no reason for it to happen (see below).


> What about glitches because your GC decides to run at the same time as all the other GC's?

Actually the GC never triggers, and if it triggers:
- the heap size is so small it would get scanned super fast
- the audio thread isn't blocked since unregistered

Tell me more how I can bring harm to this world.


> If you spend 10 hrs a day working in a DAW with thousands of VST's you'd have more of an appreciation of RT audio and design.

But you have that understanding, I guess?





November 28, 2015
We can probably agree that we don't know about the impact on a large multimedia application written in D. What you can communicate is: Create a @nogc thread routine and don't register it with the GC to write real-time VSTs.

Guillaume did a good job, taking the GC out of the real-time
thread. It's D, it is a bit of a hack, it's the correct way to
do it and works. But I don't see it debunking any myths about
GC and real time...
A) It doesn't mix them to begin with.
B) "Realtime GCs" are a thing. D's GC is not optimized for
   such a use case.
C) With a small heap it doesn't matter. (We need more complex
   multimedia projects.)

What I've seen is a program, a non-linear video editor, called PowerDirector that pauses for seconds every now and then. These pauses reminded me a lot of GC pauses, but I can't be sure. Although memory use is less after the pause, it could also be a cleaning of caches. In any case quite a few of these applications try to make "good use" of available RAM, causing constant memory pressure.

Now there has been so much talk about the GC that I don't even know what the filter does!

-- 
Marco

November 28, 2015
On Saturday, 28 November 2015 at 02:37:40 UTC, Marco Leise wrote:
> We can probably agree that we don't know about the impact on a large multimedia application written in D. What you can communicate is: Create a @nogc thread routine and don't register it with the GC to write real-time VSTs.
>
> Guillaume did a good job, taking the GC out of the real-time
> thread. It's D, it is a bit of a hack, it's the correct way to
> do it and works. But I don't see it debunking any myths about
> GC and real time...
> A) It doesn't mix them to begin with.
> B) "Realtime GCs" are a thing. D's GC is not optimized for
>    such a use case.
> C) With a small heap it doesn't matter. (We need more complex
>    multimedia projects.)
>

But the claim we hear on Internet forums is:

- "can't do realtime with a GC language" (wat)
- "GC leads to GC pauses" (only if you let them happen)

Which is imho a shortcut.


> What I've seen is a program, a non-linear video editor, called PowerDirector that pauses for seconds every now and then. These pauses reminded me a lot of GC pauses, but I can't be sure. Although memory use is less after the pause, it could also be a cleaning of caches. In any case quite a few of these applications try to make "good use" of available RAM, causing constant memory pressure.

I've seen my share of GC pauses and they did annoy me.
In some language like Javascript they are very hard to avoid.

However here I'd say it's a PowerDirector problem, not a GC problem.

> Now there has been so much talk about the GC that I don't even know what the filter does!

Reason enough not to write a blog post for me :). I'm not in a crusade.

November 28, 2015
On 2015-11-27 17:52, Guillaume Piolat wrote:

> Not sure what do you mean.

Personally I would only support 10.7+.

> Past 10.7, you can use any (provided you avoid TLS).
> Currently I use LDC for 64-bit, DMD for 32-bit, also because LDC used to
> have a bug in 32-bit codegen (fixed since then).

Ok.

-- 
/Jacob Carlborg
November 28, 2015
On Saturday, 28 November 2015 at 11:35:56 UTC, Guillaume Piolat wrote:
> On Saturday, 28 November 2015 at 02:37:40 UTC, Marco Leise wrote:
>> We can probably agree that we don't know about the impact on a large multimedia application written in D. What you can communicate is: Create a @nogc thread routine and don't register it with the GC to write real-time VSTs.
>>
>> Guillaume did a good job, taking the GC out of the real-time
>> thread. It's D, it is a bit of a hack, it's the correct way to
>> do it and works. But I don't see it debunking any myths about
>> GC and real time...
>> A) It doesn't mix them to begin with.
>> B) "Realtime GCs" are a thing. D's GC is not optimized for
>>    such a use case.
>> C) With a small heap it doesn't matter. (We need more complex
>>    multimedia projects.)
>>
>
> But the claim we hear on Internet forums is:
>
> - "can't do realtime with a GC language" (wat)
> - "GC leads to GC pauses" (only if you let them happen)
>
> Which is imho a shortcut.

Just to play devils advocate... you haven't proved GC can do real time if you achieve it by quarantining the real time code from the GC.

It's kind of like saying you can climb a mountain on a bycicle if you get of an carry it on the bits that are too steep.

That said, the basic idea is that you shouldn't do anything that might take too long or use any mutex / locks. That is the same whether you use C++, Pascal, or D.

The real story is how easy D makes it to achieve that.




November 28, 2015
On Saturday, 28 November 2015 at 20:27:02 UTC, Warwick wrote:
> Just to play devils advocate... you haven't proved GC can do real time if you achieve it by quarantining the real time code from the GC.
>

Well I think it is a fair thing to do. GC is a tradeoff, and while not usable in all situations, makes thing way simpler when it is usable. The usual story is my ho so important real time thing can't possibly tolerate a GC, while, really, most of the code is going to do mundane tasks like UI and only a small portion of it really needs not to have the GC in its way.

It just good engineering to use the tools available when appropriate.

> It's kind of like saying you can climb a mountain on a bycicle if you get of an carry it on the bits that are too steep.
>

As opposed to "you can't climb a mountain with a bike, so you must not go to the shop buying climbing equipment with a bike either".

November 28, 2015
On Friday, 27 November 2015 at 18:09:08 UTC, Adam D. Ruppe wrote:
> On Friday, 27 November 2015 at 17:12:05 UTC, Jonny wrote:
>> On Thursday, 26 November 2015 at 15:48:48 UTC, Guillaume Piolat
>>> I don't really have a point to prove, but I'm really tired with people arguing that a language with GC can't possibly do real-time. It's not like you are unallowed to optimize.
>>
>> What if someone wants to use your plugin live? You think it is acceptable to have latency and jitter? What about glitches because your GC decides to run at the same time as all the other GC's?
>
> I quoted both things because I think you missed the important part that he did, in fact, optimize the real time parts to avoid latency.

He did not miss it. He simply wanted to do the internet equivalent of putting his balls on the table to show how much of a dominant male he is.

1 2 3 4 5 6