It appears still to be a general meme that performance required no GC and GC mean poor performance. The debate has been restarted on the Go mailing list under the banner "go without garbage collector". The response to will Go remove the garbage collector was somewhat unequivocal: nope.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via Digitalmars-d wrote:
> It appears still to be a general meme that performance required no GC
> and GC mean poor performance. The debate has been restarted on the Go
> mailing list under the banner "go without garbage collector". The
> response to will Go remove the garbage collector was somewhat
> unequivocal: nope.

That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).

On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
> On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via Digitalmars-d wrote:

> That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).

The same (ie: big companies with GC) holds for C# and Java. They do not aim for the "systems programming language" mantra.

If D is another competitor for Java and C#...

(BTW, there are/will be .NET native and gcj).

More, in embedded systems (and, generally, in system programming), having or no a GC is not only about speed. It is also about the amount of memory that is used and about predictability.

And let's not even talk about the finalizers/destructors and so on.

Go went for servers, not for systems. Rename D to Vibe.D and everything will fall in place.

On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
> On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via Digitalmars-d wrote:
>> It appears still to be a general meme that performance required no GC
>> and GC mean poor performance. The debate has been restarted on the Go
>> mailing list under the banner "go without garbage collector". The
>> response to will Go remove the garbage collector was somewhat
>> unequivocal: nope.
>
> That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).

It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.

Just from watching a few of the DConf 2014 talks, if you want performance you avoid the GC at all costs (even if that means allocating into huge predefined buffers). Once you're going to these lengths to avoid garbage collection it begs the question, why are you even using this language? Within this community the question is rhetorical but to outsiders I feel it's a major concern.

"currysoup"  wrote in message news:iustbzgyagrlbtnfcton@forum.dlang.org... 

> Once you're going to these lengths to avoid garbage collection it begs the question, why are you even using this language?

Because D has plenty of other things to offer.

On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
> On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
>> On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via Digitalmars-d wrote:
>>> It appears still to be a general meme that performance required no GC
>>> and GC mean poor performance. The debate has been restarted on the Go
>>> mailing list under the banner "go without garbage collector". The
>>> response to will Go remove the garbage collector was somewhat
>>> unequivocal: nope.
>>
>> That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).
>
> It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.

Point taken. But as has been said before 90-95% of all apps can live happily with GC, and if you want, you can still go bare metal with D. The security GC offers should not be underestimated either. With "acceptance" I meant that people see "it cannot be that bad after all for *most* applications". The GC issue is often cited as a D-eal breaker. I understand that there are applications that need total control over the memory. But those apps have always been programmed in C or any other close-to-the-machine language, and even then programmers (in gaming for example) have to use additional tricks and hacks to squeeze out every little bit of performance. What D has to do is to facilitate control over the memory, but I still consider it a systems programming language due to the fact that it has many things to offer as regard the direct interaction with the machine that Java and C# don't. Can you write a device drive in Java, if yes, tell me how, I'm interested.

> Just from watching a few of the DConf 2014 talks, if you want performance you avoid the GC at all costs (even if that means allocating into huge predefined buffers). Once you're going to these lengths to avoid garbage collection it begs the question, why are you even using this language? Within this community the question is rhetorical but to outsiders I feel it's a major concern.

Don't know if it's really a "major concern" or the favorite weak spot that C++ et. al guys like to flog to death in order to distract from the many strengths that D has (in comparison with C++ et al.) The answer is always "D has GC, it's the Devil, don't touch it!" Also, let's put a little faith in the brilliant developers behind D, I'm sure there's a huge performance boost for D around the corner.

On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
> On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
>> On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
>>> On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via Digitalmars-d wrote:
>>>> It appears still to be a general meme that performance required no GC
>>>> and GC mean poor performance. The debate has been restarted on the Go
>>>> mailing list under the banner "go without garbage collector". The
>>>> response to will Go remove the garbage collector was somewhat
>>>> unequivocal: nope.
>>>
>>> That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).
>>
>> It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.
>
> Point taken. But as has been said before 90-95% of all apps can live happily with GC, and if you want, you can still go bare metal with D. The security GC offers should not be underestimated either. With "acceptance" I meant that people see "it cannot be that bad after all for *most* applications". The GC issue is often cited as a D-eal breaker. I understand that there are applications that need total control over the memory. But those apps have always been programmed in C or any other close-to-the-machine language, and even then programmers (in gaming for example) have to use additional tricks and hacks to squeeze out every little bit of performance. What D has to do is to facilitate control over the memory, but I still consider it a systems programming language due to the fact that it has many things to offer as regard the direct interaction with the machine that Java and C# don't. Can you write a device drive in Java, if yes, tell me how, I'm interested.
>
>> Just from watching a few of the DConf 2014 talks, if you want performance you avoid the GC at all costs (even if that means allocating into huge predefined buffers). Once you're going to these lengths to avoid garbage collection it begs the question, why are you even using this language? Within this community the question is rhetorical but to outsiders I feel it's a major concern.
>
> Don't know if it's really a "major concern" or the favorite weak spot that C++ et. al guys like to flog to death in order to distract from the many strengths that D has (in comparison with C++ et al.) The answer is always "D has GC, it's the Devil, don't touch it!" Also, let's put a little faith in the brilliant developers behind D, I'm sure there's a huge performance boost for D around the corner.

Ah, and there's inline asm too!

On Thursday, 17 July 2014 at 11:15:10 UTC, Chris wrote:
> On Thursday, 17 July 2014 at 09:57:09 UTC, currysoup wrote:
>> On Thursday, 17 July 2014 at 09:26:38 UTC, Chris wrote:
>>> On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via Digitalmars-d wrote:
>>>> It appears still to be a general meme that performance required no GC
>>>> and GC mean poor performance. The debate has been restarted on the Go
>>>> mailing list under the banner "go without garbage collector". The
>>>> response to will Go remove the garbage collector was somewhat
>>>> unequivocal: nope.
>>>
>>> That's good news in a way. If a big company accepts GC and the Go crowd go with it (pardon the pun), then it will find more acceptance (as Paulo pointed out in a different thread).
>>
>> It's not about "acceptance", it's about the reality that a GC is not a universal solution to memory management.
>
> Point taken. But as has been said before 90-95% of all apps can live happily with GC, and if you want, you can still go bare metal with D. The security GC offers should not be underestimated either. With "acceptance" I meant that people see "it cannot be that bad after all for *most* applications". The GC issue is often cited as a D-eal breaker. I understand that there are applications that need total control over the memory. But those apps have always been programmed in C or any other close-to-the-machine language, and even then programmers (in gaming for example) have to use additional tricks and hacks to squeeze out every little bit of performance. What D has to do is to facilitate control over the memory, but I still consider it a systems programming language due to the fact that it has many things to offer as regard the direct interaction with the machine that Java and C# don't. Can you write a device drive in Java, if yes, tell me how, I'm interested.

Easy, like in any language that offers FFI.

Expose a Driver class with native method declarations, whose implementation is written in Assembly.

The SquakVM used to drive SunSPOT devices had the device drivers written in Java.

There are quite a few other examples in the embedded market, like the MicroEJ platform.

That is no different from writing drivers in ANSI C, which provides zero features for hardware interaction.

--
Paulo

The key to making D's GC acceptable lies in two factors I believe.

1. Improve the implementation enough so that you will only be impacted by GC in extermely low memory or real time environments.
2. Defer allocation more and more by using ranges and algorithms more, and trust that compiler optimisations will make these fast.

The big, big offender I believe for extra allocations is functions which return objects, rather than functions which write to output ranges. The single most common occurence of this is something like this is toString. Instead of writing this...

string toString() {
    // Allocations the user of the library has no control over.
    return foo.toString() ~ bar.toString() ~ " something else";
}

I believe you should always, always instead write this.

// I left out the part with different character types.
void writeString(OutputRange)(OutputRange outputRange)
if (isOutputRange!(OutputRange, char)) {
    // Allocations controlle by the user of the library,
    // this template could appear in a @nogc function.
    foo.writeString(outputRange);
    bar.writeString(outputRange);

    "something else".copy(outputRange);
}

It's perhaps strange at first because you're pre-programmed from other languages, except maybe C++ which uses output streams, to always be allocating temporary objects everywhere, even if all you are doing is writing them to an object.

For improving the GC to an acceptable level, I believe collection only needs to execute fast enough such that it will fit within a frame comfortably. So for something rendering at 60FPS you have 1 second / 60 frames ~= 16.6 milliseconds of computation you can do without resulting in a single dropped frame. That means you need to get collection down to something in the 1ms to 2ms region. At which point collection time will only impact something which is really pushing the hardware, which would exclude most mobile video games, which are about the complexity of Angry Birds.

I firmly believe there's no silver bullet for automatic memory management. Reference counting solutions, including automatic reference counting, will consume less memory than a garbage collector and offer more predictable collection times, but do so at the expense of memory safety and simplicity. You need fatter pointers to manage the reference counts, and you need to carefully deal with reference cycles.

In addition, you cannot easily share slices of memory with reference counting, which is an advantage of garbage collection. With GC, you can allocate a string, slice a part of it, hand over the slice to some other object, and you know that the slice will stay around for as long as it's needed. With reference counting, you have to either retain the slice and the whole segment in the same way and allow for the possibility of hidden cycles, or disallow slicing and create copies instead. Slicing in GC is important, because you can create much more efficient programs which take slices based on regex, which we do right now.

For the environments which cannot tolerate collection whatsoever, like Sociomantic's real time bidding operations, then control of allocation will have to be left to the user. This is where the zero allocation idea behind ranges and algorithms comes into play, because then the code which doesn't allocate, which could potentially be all of std.algorithm, can still be used in those environments, rather than being rendered unusable.

There's my thoughts on it anyway. I probably rambled on too long.

On Thursday, 17 July 2014 at 09:20:36 UTC, Russel Winder via Digitalmars-d wrote:
> It appears still to be a general meme that performance required no GC
> and GC mean poor performance. The debate has been restarted on the Go
> mailing list under the banner "go without garbage collector". The
> response to will Go remove the garbage collector was somewhat
> unequivocal: nope.

GC or no GC is that the right question ?

The quality of GC implementation is probably more important.

"Simpler and faster GC for Go"
https://docs.google.com/document/d/1v4Oqa0WwHunqlb8C3ObL_uNQw3DfSY-ztoA-4wWbKcg/pub

Another point that will be ignored in such debates is that GC gives solution for only one problem, memory management.
How about other resources, how to manage them ?