On 10 April 2013 18:07, Dicebot <m.strashun@gmail.com> wrote:

> On Wednesday, 10 April 2013 at 06:14:24 UTC, Rainer Schuetze wrote:
>
>> I'm not sure if these have been proposed already in this long thread, but 2 very small patches could help a lot for realtime applications:
>>
>> 1. a thread local flag to disallow and detect GC allocations
>> 2. a flag per thread to specify that the thread should not be paused by
>> the GC during collections.
>>
>> The latter would then put the responsibility on the programmer to ensure that no references are mutated in the non-pausing thread that don't exist anywhere else (to avoid the collection of objects used in the realtime thread). As anything in a realtime thread usually has to be pre-allocated anyway, that doesn't put a lot more constraints on it but to ensure having references to the pre-allocated data in other threads or global state.
>>
>
> One concept is abused quite nicely in Erlang VM/GC - there is one gc instance per process(fiber) and it gets own pre-allocated memory pool for all its needs. That memory is prohibited to escape to other processes. When process lifespan is short enough (and it is Erlang Way, spawning hell lot of small processes), true garbage collection is never called, whole memory block is just sent back to pool on process termination.
>
> I have tested it few times and such approach allowed to meet some soft real-time requirements. Don't know if something like that can be abused in D with its fibers and scope storage class.
>

That sounds horribly non-deterministic. What if you have 256mb of ram, and no pagefile, and you fill it up till you have 1mb headroom spare?

On 10 April 2013 18:07, Dicebot <m.strashun@gmail.com> wrote:

> On Wednesday, 10 April 2013 at 06:14:24 UTC, Rainer Schuetze wrote:
>
>> I'm not sure if these have been proposed already in this long thread, but 2 very small patches could help a lot for realtime applications:
>>
>> 1. a thread local flag to disallow and detect GC allocations
>> 2. a flag per thread to specify that the thread should not be paused by
>> the GC during collections.
>>
>> The latter would then put the responsibility on the programmer to ensure that no references are mutated in the non-pausing thread that don't exist anywhere else (to avoid the collection of objects used in the realtime thread). As anything in a realtime thread usually has to be pre-allocated anyway, that doesn't put a lot more constraints on it but to ensure having references to the pre-allocated data in other threads or global state.
>>
>
> One concept is abused quite nicely in Erlang VM/GC - there is one gc instance per process(fiber) and it gets own pre-allocated memory pool for all its needs. That memory is prohibited to escape to other processes. When process lifespan is short enough (and it is Erlang Way, spawning hell lot of small processes), true garbage collection is never called, whole memory block is just sent back to pool on process termination.
>
> I have tested it few times and such approach allowed to meet some soft real-time requirements. Don't know if something like that can be abused in D with its fibers and scope storage class.
>

Actally, now that I think about it though, I do something like this a lot
in games.
I have a block of memory that only lasts the life of a single frame, any
transient allocations go in there, and they are never released, the pointer
is just reset and it overwrites the buffer each frame.
Allocation is virtually instant: void* alloc(size_t bytes) { offset +=
bytes; return buffer[offset-bytes..offset]; }
and releasing: offset = 0;
This is a great realtime allocator! ;)
I usually have separate allocation functions to do this, but in D there is
the problem that all the implicit allocations (array
concatenation/strings/etc) can't have their alloc source controlled :/

On Wednesday, 10 April 2013 at 08:57:55 UTC, Manu wrote:
> That sounds horribly non-deterministic. What if you have 256mb of ram, and
> no pagefile, and you fill it up till you have 1mb headroom spare?

It is Erlang, it is not meant to be run on 256Mb RAM ;) It kind of solves the issue of response latency for GC-enabled software on powerful enterprise servers. Because with stop-the-world GC you can't do it, does not matter how powerful your hardware is.

Does not help game dev and small-scale embedded though, that for sure ;)

On Wednesday, 10 April 2013 at 09:06:40 UTC, Manu wrote:
> Actally, now that I think about it though, I do something like this a lot
> in games.
> I have a block of memory that only lasts the life of a single frame, any
> transient allocations go in there, and they are never released, the pointer
> is just reset and it overwrites the buffer each frame.
> Allocation is virtually instant: void* alloc(size_t bytes) { offset +=
> bytes; return buffer[offset-bytes..offset]; }
> and releasing: offset = 0;
> This is a great realtime allocator! ;)
> I usually have separate allocation functions to do this, but in D there is
> the problem that all the implicit allocations (array
> concatenation/strings/etc) can't have their alloc source controlled :/

Well, avoid all implicit allocations and you can do something like that already right now. My initial comment was inspired by recent uprising of "scope" discussion - it fits the concept allowing such implementation to be not only fast but also type-safe.

On 10 April 2013 18:11, Dicebot <m.strashun@gmail.com> wrote:

> On Wednesday, 10 April 2013 at 06:03:08 UTC, Manu wrote:
>
>> A base class typically offers a sort of template of something,
>> implementing
>> as much shared/common functionality as possible, but which you might
>> extend, or make more specific in some very controlled way.
>> Typically the base functionality and associated accessors deal with
>> variable data contained in the base-class.
>>
>
> I believe that template mixins + structs are much more natural way to express this concept. Basically, if you need inheritance only for code reuse, you don't need inheritance and all polymorphic overhead. D provides some good tools to shift away from that traditional approach. Those can and should be improved, but I think the whole concept "classes are polymorphic virtual reference types, structs are plain aggregates" is very solid and area of struct-only development needs to be explored a bit more.
>

... nar, I don't think so.
A class is a class, I'm not arguing for anything that's kinda-like-a-class,
I'm talking about classes. The fact that I (and sensible 3rd party
libraries I would choose to use) minimise the number of virtuals makes
perfect sense.
It's faster, it's easier to understand, you can see what functions you need
to override to use the object effectively at a glance, behaviour is more
predictable since there are fewer points of variation...
Nobody has yet showed me an example of a typical class where it would make
ANY sense that all (or even most) methods be virtual. (Again, not talking
about small/trivial or foundational/container classes, people don't write
these every day, they write them once, and use them for a decade, and they
probably like in the standard library)

On 10 April 2013 19:07, Dicebot <m.strashun@gmail.com> wrote:

> On Wednesday, 10 April 2013 at 08:57:55 UTC, Manu wrote:
>
>> That sounds horribly non-deterministic. What if you have 256mb of ram, and no pagefile, and you fill it up till you have 1mb headroom spare?
>>
>
> It is Erlang, it is not meant to be run on 256Mb RAM ;) It kind of solves the issue of response latency for GC-enabled software on powerful enterprise servers. Because with stop-the-world GC you can't do it, does not matter how powerful your hardware is.
>
> Does not help game dev and small-scale embedded though, that for sure ;)
>

Well there's always the standing question though, why is JVM and C# so much
faster than D?
They produce a squillion times more garbage than D, yet they're much much
faster. I have come to accept the C# GC in less-intensive realtime
software, it's not so bad.

On Wednesday, 10 April 2013 at 09:12:33 UTC, Manu wrote:
> ... nar, I don't think so.
> A class is a class, I'm not arguing for anything that's kinda-like-a-class,
> I'm talking about classes.

The question is then "what is class?". Because the very reason to have class is to have guaranteed polymorphic behavior, so that working with object via its base will always make sense without any fears about what behavior can be overriden. But that is mostly needed in OOP hell with few practical cases like plugins.

If essentially coupling data and methods is needed, that is what struct does. I am not arguing that everything should be virtual, I am arguing that you actually need classes. It is not C++ and, in my opinion, structs should be much more common entities than classes, especially in performance-hungry code.

On Wednesday, 10 April 2013 at 09:15:26 UTC, Manu wrote:
> Well there's always the standing question though, why is JVM and C# so much
> faster than D?
> They produce a squillion times more garbage than D, yet they're much much
> faster. I have come to accept the C# GC in less-intensive realtime
> software, it's not so bad.

Erm, because they are not faster? I have performance tested vibe.d recently vs some similar solutions, including Java and C#. Vibe.d compiled with dmd. Destroyed both JVM and C# in raw performance and had same roughly latency (GC collections cycles, gah!).

And Erlang won all of them in terms of latency on powerful machine.

On Wednesday, 10 April 2013 at 09:07:53 UTC, Dicebot wrote:
> On Wednesday, 10 April 2013 at 08:57:55 UTC, Manu wrote:
>> That sounds horribly non-deterministic. What if you have 256mb of ram, and
>> no pagefile, and you fill it up till you have 1mb headroom spare?
>
> It is Erlang, it is not meant to be run on 256Mb RAM ;) It kind of solves the issue of response latency for GC-enabled software on powerful enterprise servers. Because with stop-the-world GC you can't do it, does not matter how powerful your hardware is.
>
> Does not help game dev and small-scale embedded though, that for sure ;)

Actually there is a game studio in Germany, Wooga that uses Erlang for their game servers, they are quite happy to have left C++ land.

http://www.slideshare.net/wooga/from-0-to-1000000-daily-users-with-erlang

--
Paulo

On 10 April 2013 19:22, Dicebot <m.strashun@gmail.com> wrote:

> On Wednesday, 10 April 2013 at 09:15:26 UTC, Manu wrote:
>
>> Well there's always the standing question though, why is JVM and C# so
>> much
>> faster than D?
>> They produce a squillion times more garbage than D, yet they're much much
>> faster. I have come to accept the C# GC in less-intensive realtime
>> software, it's not so bad.
>>
>
> Erm, because they are not faster? I have performance tested vibe.d recently vs some similar solutions, including Java and C#. Vibe.d compiled with dmd. Destroyed both JVM and C# in raw performance and had same roughly latency (GC collections cycles, gah!).
>
> And Erlang won all of them in terms of latency on powerful machine.
>

How much garbage were you collecting? How long were the collect times? Did
you see the same relationship between the volume of garbage in JVM, C# and
D?
What was the performance relationship with respect to garbage volume? was
it linear?