On Monday, 14 September 2015 at 13:56:16 UTC, Laeeth Isharc wrote:
> An associate who sold a decent sized marketing group

Should read marketmaking.  Making prices in listed equity options.

On Monday, 14 September 2015 at 00:53:58 UTC, Jonathan M Davis wrote:
> Only the stack and the GC heap get scanned unless you tell the GC about memory that was allocated by malloc or some other mechanism. malloced memory won't be scanned by default. So, if you're using the GC minimally and coding in a way that doesn't involve needing to tell the GC about a bunch of malloced memory, then the GC won't have all that much to scan. And while the amount of memory that the GC has to scan does affect the speed of a collection, in general, the less memory that's been allocated by the GC, the faster a collection is.
>
> Idiomatic D code uses the stack heavily and allocates very little on the GC heap.
...
> So, while the fact that D's GC is less than stellar is certainly a problem, and we would definitely like to improve that, the idioms that D code typically uses seriously reduce the number of performance problems that we get.
>
> - Jonathan M Davis

Thank you for your posts on this (and the others), Jonathan.  I appreciate your taking the time to write so carefully and thoroughly, and I learn a lot from reading your work.

On Monday, 14 September 2015 at 13:56:16 UTC, Laeeth Isharc wrote:
> Personally, when I make a strong claim about something and find that I am wrong (the claim that D needs to scan every pointer), I take a step back and consider my view rather than pressing harder.  It's beautiful to be wrong because through recognition of error, growth.  If recognition.

The claim is correct: you need to follow every pointer that through some indirection may lead to a pointer that may point into the GC heap. Not doing so will lead to unverified memory unsafety.

> Given one was written by one (very smart) student for his PhD thesis, and that as I understand it that formed the basis of Sociomantic's concurrent garbage collector (correct me if I am wrong), and that this is being ported to D2, and whether or not it is released, success will spur others to follow - it strikes

As it has been described, it is fork() based and unsuitable for the typical use case.

> provided one understands the situation.  Poking holes at things without taking any positive steps to fix them is understandable for people that haven't a choice about their situation, but in my experience is rarely effective in making the world better.

Glossing over issues that needs attention is not a good idea. It wastes other people's time.

I am building my own libraries, also for memory management with move semantics etc.

On Monday, September 14, 2015 14:19:30 Ola Fosheim Grøstad via Digitalmars-d-learn wrote:
> On Monday, 14 September 2015 at 13:56:16 UTC, Laeeth Isharc wrote: The claim is correct: you need to follow every pointer that through some indirection may lead to a pointer that may point into the GC heap. Not doing so will lead to unverified memory unsafety.
>
> > Given one was written by one (very smart) student for his PhD thesis, and that as I understand it that formed the basis of Sociomantic's concurrent garbage collector (correct me if I am wrong), and that this is being ported to D2, and whether or not it is released, success will spur others to follow - it strikes
>
> As it has been described, it is fork() based and unsuitable for
> the typical use case.

I'm not sure why it wouldn't be suitable for the typical use case. It's quite performant. It would still not be suitable for many games and environments that can't afford to stop the world for more than a few milliseconds, but it brings the stop the world time down considerably, making the GC more suitable for more environments than it would be now, and I'm not aware of any serious downsides to it on a *nix system.

Its achilles heel is Windows. On *nix, forking is cheap, but on Windows, it definitely isn't. So, a different mechanism would be needed to make the concurrent GC work on Windows, and I don't know if Windows really provides the necessarily tools to do that, though I know that some folks were looking into it at least at the time of Leandro's talk. So, we're either going to need to figure out how to get the concurrent GC working on Windows via some mechanism other than fork, or Windows is going to need a different solution to get that kind of improvement out of the GC.

- Jonathan M Davis

On Monday, September 14, 2015 01:12:02 Ola Fosheim Grostad via Digitalmars-d-learn wrote:
> On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis wrote:
> > Regardless, idiomatic D involves a lot more stack allocations than you often get even in C++, so GC usage tends to be low in
>
> Really? I use VLAs in my C++ (a C extension) and use very few mallocs after init. In C++ even exceptions can be put outside the heap. Just avoid STL after init and you're good.

>From what I've seen of C++ and understand of typical use cases from other
folks, that's not at all typical of C++ usage (though there's enough people using C++ across a wide enough spectrum of environments and situations that there's obviously going to be quite a wide spread of what folks do with it). A lot of C++ folks use classes heavily, frequently allocating them on the heap. Major C++ libraries such as Qt certainly are designed with the idea that you're going to be allocating as the program runs. And C++ historically has been tooted fairly heavily by many folks as an OO language, in which case, inheritance (and therefore heap allocation) are used heavily by many programs. And with C++11/14, more mechanisms for safely handling memory have been added, thereby further encouraging the use of certain types of heap allocations in your typical C++ program - e.g. make_shared has become the recommended way to allocate memory in most cases. And while folks who are trying to get the bare metal performance that some stuff like games require, most folks are going to use the STL quite a bit. And if they aren't, they're probably using similar classes from a 3rd party library such as Qt. It's the folks who are in embedded environments or who have much more restrictive performance requirements who are more likely to avoid the STL or do stuff like avoid heap allocations after the program has been initialized.

So, a _lot_ of C++ code uses the heap quite heavily, and I expect that very little of it tries to allocate everything up front. I, for one, have never worked on an application where that even made sense aside from something very small. I know that applications like that definitely exist, but from everything I've seen, I'd expect them to be the exception to the rule rather than the norm.

Regardless, idiomatic D promotes ranges, which naturally help reduce heap allocation. It also means using structs heavily and classes sparingly (though there are plenty of cases where inheritance is required and thus classes get used). And while arrays/strings get allocated on the heap, slicing seriously reduces how often they need to be copied in memory, which reduces heap allocations. So, idiomatic D encourages programs to be written in a way that keeps heap allocation to a minimum. The big place that it happens in most D programs is probably strings, but slicing helps consderably with that, and even some of the string stuff can be made to live on the stack rather than the heap (which is what a lot of Walter's recent work in Phobos has been for - making string-based stuff work as lazy ranges), reducing heap allocations for strings ever further.

C++ on the other hand does not have such idioms as the norm or as promoted in any serious way. So, programmers are much more likely to use idioms that involve a lot of heap allocations, and the language and standard library don't really have much to promote idioms that avoid heap allocations (and std::string definitely isn't designed to avoid copying). You can certainly do it - and many do - but since it's not really what's promoted by the language or standard library, it's less likely to happen in your average program. It's much more likely to be done by folks who avoid the STL.

So, you _can_ have low heap allocation in a C++ program, and many people do, but from what I've seen, that really isn't the norm across the C++ community in general.

- Jonathan M Davis

On Monday, 14 September 2015 at 20:54:55 UTC, Jonathan M Davis wrote:
>
> So, you _can_ have low heap allocation in a C++ program, and many people do, but from what I've seen, that really isn't the norm across the C++ community in general.
>
> - Jonathan M Davis

Fully agreed, C++ in the wild often make lots of copies of data structure, sometimes by mistake (like std::vector passed by value instead of ref).
When you copy an aggregate by mistake, every field itself gets copied etc.
Copies copies copies everywhere.

On Monday, 14 September 2015 at 20:34:03 UTC, Jonathan M Davis wrote:
> I'm not sure why it wouldn't be suitable for the typical use case. It's quite performant. It would still not be suitable for many games and environments that can't afford to stop the world for more than a few milliseconds, but it brings the stop the world time down considerably, making the GC more suitable for more environments than it would be now, and I'm not aware of any serious downsides to it on a *nix system.

For me concurrent gc implies interactive applications or webservices that are memory constrained/diskless. You cannot prevent triggering actions that writes all over memory during collection without taking special care, like avoiding RC. A fork kan potentially double memory consumption. Gc by itself uses ~2x memory, with fork you have to plan for 3-4x.

In the cloud you pay for extra RAM. So configuring the app to a fixed sized memory heap that matches the instance RAM capacity is useful. With fork you just have to play it safe and halve the heap size. So more collections and less utilized RAM per dollar with fork.

Only testing will show the effect, but it does not sound promising for my use cases.

On Monday, 14 September 2015 at 20:54:55 UTC, Jonathan M Davis wrote:
> On Monday, September 14, 2015 01:12:02 Ola Fosheim Grostad via Digitalmars-d-learn wrote:
>> On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis wrote:
>> > Regardless, idiomatic D involves a lot more stack allocations than you often get even in C++, so GC usage tends to be low in
>>
>> Really? I use VLAs in my C++ (a C extension) and use very few mallocs after init. In C++ even exceptions can be put outside the heap. Just avoid STL after init and you're good.
>
>>From what I've seen of C++ and understand of typical use cases from other
> folks, that's not at all typical of C++ usage (though there's enough people using C++ across a wide enough spectrum of environments and situations that there's obviously going to be quite a wide spread of what folks do with it). A lot of C++ folks use classes heavily, frequently allocating them on the heap.

Dude, my c++ programs are all static ringbuffers and stack allocations. :)

It varies a lot. Some c++ programmers turn off everything runtime related and use it as a better c.

When targetting mobile you have to be careful about wasting memory...

> types of heap allocations in your typical C++ program - e.g. make_shared has become the recommended way to allocate memory in most cases

I use unique_ptr with custom deallocator (custom freelist), so it can be done outside the heap. :)

> And while folks who are trying to get the bare metal performance that some stuff like games require, most folks are going to use the STL quite a bit.

I use std::array. And my own array view type to reference it. Array_view us coming to c++17 I think. Kinda like D slices.

STL/string/iostream is for me primarily useful for init and testing...

> such as Qt. It's the folks who are in embedded environments or who have much more restrictive performance requirements who are more likely to avoid the STL or do stuff like avoid heap allocations after the program has been initialized.

Mobile audio/graphics...

> So, you _can_ have low heap allocation in a C++ program, and many people do, but from what I've seen, that really isn't the norm across the C++ community in general.

I dont think there is a C++ community ;-) I think c++ programmers are quite different based on what they do and when they started using it. I only use it where performance/latency matters. C++ is too annoying  (time consuming) for full blown apps IMHO.

Classes are easy to stack allocate though, no need to heap allocate most of the time. Lambdas in c++ are often just stack allocated objects, so not so different from D's "ranges" (iterators) anyhow. I don't see my own programs suffer from c++isms anyway...