Am 26.02.2012 17:34, schrieb so:
> On Sunday, 26 February 2012 at 15:58:41 UTC, H. S. Teoh wrote:
>
>> Would this even be an issue on multicore systems where the GC can run
>> concurrently? As long as the stop-the-world parts are below some given
>> threshold.
>
> If it is possible to guarantee that i don't think anyone would bother
> with manual MM.

Well, some game studios seem to be quite happy with XNA, which implies using a GC:

http://infinite-flight.com/if/index.html

Le 26/02/2012 17:34, so a écrit :
> On Sunday, 26 February 2012 at 15:58:41 UTC, H. S. Teoh wrote:
>
>> Would this even be an issue on multicore systems where the GC can run
>> concurrently? As long as the stop-the-world parts are below some given
>> threshold.
>
> If it is possible to guarantee that i don't think anyone would bother
> with manual MM.

It is possible on x86, but currently, OS don't provide the primitives required to do so.

On 2/26/2012 7:04 AM, Simon wrote:
> On 26/02/2012 03:22, Walter Bright wrote:
>> On 2/25/2012 4:01 PM, Simon wrote:
>>> On 25/02/2012 22:55, Walter Bright wrote:
>>>> Enter C++'s shared_ptr. But that works by, for each object, allocating a
>>>> *second* chunk of memory to hold the reference count. Right off the bat,
>>>> you've got twice as many allocations & frees with shared_ptr than a GC
>>>> would have.
>>>
>>> http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/make_shared.html
>>>
>>> so you don't have to have twice as many allocations.
>>
>> There are many ways to do shared pointers, including one where the
>> reference count is part of the object being allocated. But the C++11
>> standard share_ptr does an extra allocation.
>
> The stl one is based on boost, so it has make_shared as well:
>
> http://en.cppreference.com/w/cpp/memory/shared_ptr
>
> and it's in vs 2010
>
> http://msdn.microsoft.com/en-us/library/ee410595.aspx
>
> Not that I'm claiming shared pointers are superior to GC.

At the GoingNative C++ conference, the guy who is in charge of STL for VS said that it did an extra allocation for the reference count.

On Sunday, 26 February 2012 at 15:48:13 UTC, so wrote:
> On Sunday, 26 February 2012 at 15:22:09 UTC, deadalnix wrote:
>
>> True, but the problem of video game isn't how much computation you do to allocate, but to deliver a frame every few miliseconds. In most cases, it worth spending more in allocating but with a predictable result than let the GC does its job.
>
> Absolutely! It cracks me up when i see (in this forum or any other graphics related forums) things like "you can't allocate at runtime!!!" or "you shouldn't use standard libraries!!!". Thing is, you can do both just fine if you just RTFM :)

Of course you can do both just fine. It doesn't mean it's a good idea. There's also rarely ever any need to. It's not difficult to avoid allocating memory.

On Sun, 26 Feb 2012 20:26:41 +0100, Walter Bright <newshound2@digitalmars.com> wrote:

> On 2/26/2012 7:04 AM, Simon wrote:
>> On 26/02/2012 03:22, Walter Bright wrote:
>>> On 2/25/2012 4:01 PM, Simon wrote:
>>>> On 25/02/2012 22:55, Walter Bright wrote:
>>>>> Enter C++'s shared_ptr. But that works by, for each object, allocating a
>>>>> *second* chunk of memory to hold the reference count. Right off the bat,
>>>>> you've got twice as many allocations & frees with shared_ptr than a GC
>>>>> would have.
>>>>
>>>> http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/make_shared.html
>>>>
>>>> so you don't have to have twice as many allocations.
>>>
>>> There are many ways to do shared pointers, including one where the
>>> reference count is part of the object being allocated. But the C++11
>>> standard share_ptr does an extra allocation.
>>
>> The stl one is based on boost, so it has make_shared as well:
>>
>> http://en.cppreference.com/w/cpp/memory/shared_ptr
>>
>> and it's in vs 2010
>>
>> http://msdn.microsoft.com/en-us/library/ee410595.aspx
>>
>> Not that I'm claiming shared pointers are superior to GC.
>
> At the GoingNative C++ conference, the guy who is in charge of STL for VS said that it did an extra allocation for the reference count.

It's actually quite nice to combine unique_ptr and shared_ptr.
One can lazily create the refcount only when the pointers are shared.
Often one can get away with unique ownership.

https://gist.github.com/1920202

On Sun, Feb 26, 2012 at 11:05 AM, Paulo Pinto <pjmlp@progtools.org> wrote:
> Am 26.02.2012 17:34, schrieb so:
>
>> On Sunday, 26 February 2012 at 15:58:41 UTC, H. S. Teoh wrote:
>>
>>> Would this even be an issue on multicore systems where the GC can run concurrently? As long as the stop-the-world parts are below some given threshold.
>>
>>
>> If it is possible to guarantee that i don't think anyone would bother with manual MM.
>
>
> Well, some game studios seem to be quite happy with XNA, which implies using a GC:
>
> http://infinite-flight.com/if/index.html
>

I don't really see why you keep bringing up these examples. This is a
performance issue, which means you can certainly ignore it and things
will still work, just not as well. I've seen 3d games in Java, but
they always suffer from an awkward pause at fairly regular intervals.
This is why the AAA shops are still writing most of the engines in
C++.
You will always be able to find examples of developers that simply
chose to ignore the issue for one reason or another.

To make it clear, I'm not trying to antagonize you here. I agree that GC is in general a superior technical solution to manual memory management, and given the research going into GC technology, I'm sure that long term it's probably a good idea.

However, I disagree with your statement that "the main issue is that
the GC needs to be optimized, not that manual memory management is
required."
Making a GC that can run fast enough to make this sort of thing a
non-issue is currently so hard that it can only be used in certain
niche situations. That will probably change, but it will probably
change over the course of several years. Manual memory management,
however, is here now and dead simple to use so long as the programmer
understands the semantics. Programming in that model is harder, but
not nearly as bad as, say, thread-based concurrency with race
conditions and deadlock. Manual memory management is much simpler to
deal with than many other things programmers already take on
voluntarily.
When you want your realtime application to behave in a certain way,
would you rather spend months or years working on the GC and program
in a completely difficult style to deal with the issue, or use manual
memory management *now* and deal with the slightly more difficult
programming model? Cost/benefit wise, GC just doesn't make a lot of
sense in this sort of scenario unless you have a lot of resources to
burn or a specific reason to choose a GC-mandatory platform.

Again, I'm not saying GC is bad, I'm saying that in this area, the cost/benefit ratio doesn't say you should spend your time improving the GC to make things work. For everyone else, GC is great, and I applaud David Simcha's efforts to improve D's GC performance.

On Monday, 27 February 2012 at 04:17:24 UTC, Andrew Wiley wrote:
> On Sun, Feb 26, 2012 at 11:05 AM, Paulo Pinto <pjmlp@progtools.org> wrote:
>> Am 26.02.2012 17:34, schrieb so:
>>
>>> On Sunday, 26 February 2012 at 15:58:41 UTC, H. S. Teoh wrote:
>>>
>>>> Would this even be an issue on multicore systems where the GC can run
>>>> concurrently? As long as the stop-the-world parts are below some given
>>>> threshold.
>>>
>>>
>>> If it is possible to guarantee that i don't think anyone would bother
>>> with manual MM.
>>
>>
>> Well, some game studios seem to be quite happy with XNA, which implies using
>> a GC:
>>
>> http://infinite-flight.com/if/index.html
>>
>
> I don't really see why you keep bringing up these examples. This is a
> performance issue, which means you can certainly ignore it and things
> will still work, just not as well. I've seen 3d games in Java, but
> they always suffer from an awkward pause at fairly regular intervals.
> This is why the AAA shops are still writing most of the engines in
> C++.
> You will always be able to find examples of developers that simply
> chose to ignore the issue for one reason or another.
>
> To make it clear, I'm not trying to antagonize you here. I agree that
> GC is in general a superior technical solution to manual memory
> management, and given the research going into GC technology, I'm sure
> that long term it's probably a good idea.
>
> However, I disagree with your statement that "the main issue is that
> the GC needs to be optimized, not that manual memory management is
> required."
> Making a GC that can run fast enough to make this sort of thing a
> non-issue is currently so hard that it can only be used in certain
> niche situations. That will probably change, but it will probably
> change over the course of several years. Manual memory management,
> however, is here now and dead simple to use so long as the programmer
> understands the semantics. Programming in that model is harder, but
> not nearly as bad as, say, thread-based concurrency with race
> conditions and deadlock. Manual memory management is much simpler to
> deal with than many other things programmers already take on
> voluntarily.
> When you want your realtime application to behave in a certain way,
> would you rather spend months or years working on the GC and program
> in a completely difficult style to deal with the issue, or use manual
> memory management *now* and deal with the slightly more difficult
> programming model? Cost/benefit wise, GC just doesn't make a lot of
> sense in this sort of scenario unless you have a lot of resources to
> burn or a specific reason to choose a GC-mandatory platform.
>
> Again, I'm not saying GC is bad, I'm saying that in this area, the
> cost/benefit ratio doesn't say you should spend your time improving
> the GC to make things work. For everyone else, GC is great, and I
> applaud David Simcha's efforts to improve D's GC performance.

It does take years but please note that those referenced papers are already several years old. Some are from 2005-6.
It doesn't mean D shouldn't support manual memory management but claiming that GC doesn't work for real-time is a [religious] myth. Clearly the cost of research has already been spent years ago and the algorithms were already documented and tested.

OT: one of the papers was written at my university.

On 02/27/2012 02:29 AM, Martin Nowak wrote:
> On Sun, 26 Feb 2012 20:26:41 +0100, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 2/26/2012 7:04 AM, Simon wrote:
>>> On 26/02/2012 03:22, Walter Bright wrote:
>>>> On 2/25/2012 4:01 PM, Simon wrote:
>>>>> On 25/02/2012 22:55, Walter Bright wrote:
>>>>>> Enter C++'s shared_ptr. But that works by, for each object,
>>>>>> allocating a
>>>>>> *second* chunk of memory to hold the reference count. Right off
>>>>>> the bat,
>>>>>> you've got twice as many allocations & frees with shared_ptr than
>>>>>> a GC
>>>>>> would have.
>>>>>
>>>>> http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/make_shared.html
>>>>>
>>>>> so you don't have to have twice as many allocations.
>>>>
>>>> There are many ways to do shared pointers, including one where the
>>>> reference count is part of the object being allocated. But the C++11
>>>> standard share_ptr does an extra allocation.
>>>
>>> The stl one is based on boost, so it has make_shared as well:
>>>
>>> http://en.cppreference.com/w/cpp/memory/shared_ptr
>>>
>>> and it's in vs 2010
>>>
>>> http://msdn.microsoft.com/en-us/library/ee410595.aspx
>>>
>>> Not that I'm claiming shared pointers are superior to GC.
>>
>> At the GoingNative C++ conference, the guy who is in charge of STL for
>> VS said that it did an extra allocation for the reference count.
>
> It's actually quite nice to combine unique_ptr and shared_ptr.
> One can lazily create the refcount only when the pointers are shared.
> Often one can get away with unique ownership.

Ok. Btw, if the utility is in charge of allocation, then the refcount can be allocated together with the storage.

>
> https://gist.github.com/1920202

Neat. Possible improvement (if I understand your code correctly): Don't add the GC range if all possible aliasing is through Ptr.

I keep bringing this issues, because I am a firm believer that when
people that fight against a GC are just fighting a lost battle.

Like back in the 80's people were fighting against Pascal or C versus
Assembly. Or in the 90' were fighting against C++ versus C.

Now C++ is even used for operating systems, BeOS, Mac OS X drivers,
COM/WinRT.

Sure a systems programming language needs some form of manual memory
management for "exceptional situations", but 90% of the time you will
be allocating either referenced counted or GCed memory.

What will you do when the major OS use a systems programming language like forces GC or reference counting on you do? Which is already slowly happening with GC and ARC on Mac OS X, WinRT on Windows 8, mainstream OS, as well as the Oberon, Spin, Mirage, Home, Inferno and Singularity research OSs.

Create your own language to allow you to live in the past?

People that refuse to adapt to times stay behind, those who adapt, find ways to profit from the new reality.

But as I said before, that is my opinion and as a simple human is also prone to errors. Maybe my ideas regarding memory management in systems languages are plain wrong, the future will tell.

--
Paulo

On Monday, 27 February 2012 at 04:17:24 UTC, Andrew Wiley wrote:
> On Sun, Feb 26, 2012 at 11:05 AM, Paulo Pinto <pjmlp@progtools.org> wrote:
>> Am 26.02.2012 17:34, schrieb so:
>>
>>> On Sunday, 26 February 2012 at 15:58:41 UTC, H. S. Teoh wrote:
>>>
>>>> Would this even be an issue on multicore systems where the GC can run
>>>> concurrently? As long as the stop-the-world parts are below some given
>>>> threshold.
>>>
>>>
>>> If it is possible to guarantee that i don't think anyone would bother
>>> with manual MM.
>>
>>
>> Well, some game studios seem to be quite happy with XNA, which implies using
>> a GC:
>>
>> http://infinite-flight.com/if/index.html
>>
>
> I don't really see why you keep bringing up these examples. This is a
> performance issue, which means you can certainly ignore it and things
> will still work, just not as well. I've seen 3d games in Java, but
> they always suffer from an awkward pause at fairly regular intervals.
> This is why the AAA shops are still writing most of the engines in
> C++.
> You will always be able to find examples of developers that simply
> chose to ignore the issue for one reason or another.
>
> To make it clear, I'm not trying to antagonize you here. I agree that
> GC is in general a superior technical solution to manual memory
> management, and given the research going into GC technology, I'm sure
> that long term it's probably a good idea.
>
> However, I disagree with your statement that "the main issue is that
> the GC needs to be optimized, not that manual memory management is
> required."
> Making a GC that can run fast enough to make this sort of thing a
> non-issue is currently so hard that it can only be used in certain
> niche situations. That will probably change, but it will probably
> change over the course of several years. Manual memory management,
> however, is here now and dead simple to use so long as the programmer
> understands the semantics. Programming in that model is harder, but
> not nearly as bad as, say, thread-based concurrency with race
> conditions and deadlock. Manual memory management is much simpler to
> deal with than many other things programmers already take on
> voluntarily.
> When you want your realtime application to behave in a certain way,
> would you rather spend months or years working on the GC and program
> in a completely difficult style to deal with the issue, or use manual
> memory management *now* and deal with the slightly more difficult
> programming model? Cost/benefit wise, GC just doesn't make a lot of
> sense in this sort of scenario unless you have a lot of resources to
> burn or a specific reason to choose a GC-mandatory platform.
>
> Again, I'm not saying GC is bad, I'm saying that in this area, the
> cost/benefit ratio doesn't say you should spend your time improving
> the GC to make things work. For everyone else, GC is great, and I
> applaud David Simcha's efforts to improve D's GC performance.

On Monday, 27 February 2012 at 08:39:54 UTC, Paulo Pinto wrote:
> I keep bringing this issues, because I am a firm believer that when
> people that fight against a GC are just fighting a lost battle.
>
> Like back in the 80's people were fighting against Pascal or C versus
> Assembly. Or in the 90' were fighting against C++ versus C.
>
> Now C++ is even used for operating systems, BeOS, Mac OS X drivers,
> COM/WinRT.

It is not a fair analogy. Unlike MMM and GC, C++ can do everything C can do and has more sugar. What they are argue i think whether or not OO is a solution to everything and troubles with its implementation in C++.

> Sure a systems programming language needs some form of manual memory
> management for "exceptional situations", but 90% of the time you will
> be allocating either referenced counted or GCed memory.
>
> What will you do when the major OS use a systems programming language like forces GC or reference counting on you do? Which is already slowly happening with GC and ARC on Mac OS X, WinRT on Windows 8, mainstream OS, as well as the Oberon, Spin, Mirage, Home, Inferno and Singularity research OSs.
>
> Create your own language to allow you to live in the past?
>
> People that refuse to adapt to times stay behind, those who adapt, find ways to profit from the new reality.
>
> But as I said before, that is my opinion and as a simple human is also prone to errors. Maybe my ideas regarding memory management in systems languages are plain wrong, the future will tell.
>
> --
> Paulo

As i said in many threads regarding GC and MMM, it is not about this vs that.
There should be no religious stances. Both have their strengths and failures.
What every single discussion on this boils down to is some people downplay the failures of their religion :)

And that staying behind thing is something i never understand!
It is a hype, it is marketing! To sell you a product that doesn't deserve half its price!

Religion/Irrationality has no place in what we do. Show me a better tool, "convince me" it is better and i will be using that tool. I don't give a damn if it is D or vim i am leaving behind.