Smart pointers instead of GC? (page 19)

 please this GC handbook sound good, can u post it? A queue uses more memory than not a queue? Fuk I did not know, I so dumb. Live longer more memory used, what///.


 Tuesday, 4 February 2014 at 02:33:50 UTC, Adam Wilson wrote:
> On Mon, 03 Feb 2014 18:14:36 -0800, Ola Fosheim Grøstad <ola.fosheim.grostad+dlang@gmail.com> wrote:
>
>> On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
>>> 1. RC imposes a time overhead on mutators in order to manipulate the counter.
>>
>> Usually you just do a retain() when your thread attain ownership (at the root of the call tree). If you use embedded counters you most likely want the data in the cache anyway, but the cacheline is made dirty. So it cost you a write back. That affects reads of small objects more than writes.
>>
>> (The C++ implementation does not use embedded counters.)
>>
>
> There are many more ways to modify the count than a thread.
>
>>> 2. Both the counter manipulation and pointer load/store operations MUST be atomic to prevent races.
>>
>> Not with transactional memory. You revert to locking, and you probably want that kind of synchronization anyway if you run multi threaded.
>>
>
> Transactional memory incurs a massive perf penalty beyond even what a lock would. You might be able to do better than a lock with Intel's TSX, but that is brand new, available on Haswells only, and even then only the high-end models. I doubt you'll be able to sell TM-ARC to perf conscience users as the perf will most likely be much worse than a GC for the next decade.

February 04, 2014

Re: Smart pointers instead of GC?

Posted by Frustrated
in reply to Adam Wilson

Permalink

Frustrated

Posted in reply to Adam Wilson

Permalink

On Tuesday, 4 February 2014 at 02:15:21 UTC, Adam Wilson wrote:
> On Mon, 03 Feb 2014 17:54:22 -0800, Frustrated <c1514843@drdrb.com> wrote:
>
>> On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
>>> On Mon, 03 Feb 2014 17:04:08 -0800, Manu <turkeyman@gmail.com> wrote:
>>>
>>>> On 4 February 2014 06:21, Adam Wilson <flyboynw@gmail.com> wrote:
>>>>
>>>>> On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu <
>>>>> SeeWebsiteForEmail@erdani.org> wrote:
>>>>>
>>>>> On 2/3/14, 6:57 AM, Frank Bauer wrote:
>>>>>>
>>>>>>> Anyone asking for the addition of ARC or owning pointers to D, gets
>>>>>>> pretty much ignored. The topic is "Smart pointers instead of GC?",
>>>>>>> remember? People here seem to be more interested in diverting to
>>>>>>> nullable, scope and GC optimization. Telling, indeed.
>>>>>>>
>>>>>>
>>>>>> I thought I made it clear that GC avoidance (which includes considering
>>>>>> built-in reference counting) is a major focus of 2014.
>>>>>>
>>>>>> Andrei
>>>>>>
>>>>>>
>>>>> Andrei, I am sorry to report that anything other than complete removal of
>>>>> the GC and replacement with compiler generated ARC will be unacceptable to
>>>>> a certain, highly vocal, subset of D users. No arguments can be made to
>>>>> otherwise, regardless of validity. As far as they are concerned the
>>>>> discussion of ARC vs. GC is closed and decided. ARC is the only path
>>>>> forward to the bright and glorious future of D. ARC most efficiently solves
>>>>> all memory management problems ever encountered. Peer-Reviewed Research and
>>>>> the Scientific Method be damned! ALL HAIL ARC!
>>>>>
>>>>> Sadly, although written as hyperbole, I feel that the above is fairly
>>>>> close to the actual position of the ARC crowd.
>>>>
>>>>
>>>> Don't be a dick.
>>>> I get the impression you don't actually read my posts. And I also feel like
>>>> you're a lot more dogmatic about this than you think I am.
>>>>
>>>> I'm absolutely fine with GC in most applications, I really couldn't give
>>>> any shits if most people want a GC. I'm not dogmatic about it, and I've
>>>> **honestly** tried to love the GC for years now.
>>>> What I'm concerned about is that I have _no option_ to use D uninhibited
>>>> when I need to not have the GC.
>>>>
>>>> These are the problems:
>>>> * GC stalls for long periods time at completely un-predictable moments.
>>>> * GC stalls become longer *and* more frequent as memory becomes less
>>>> available, and the working pool becomes larger (what a coincidence).
>>>> * Memory footprint is unknowable, what if you don't have a virtual memory
>>>> manager? What if your total memory is measured in megabytes?
>>>> * It's not possible to know when destruction of an object will happen,
>>>> which has known workarounds (like in C#) but is also annoying in many
>>>> cases, and supports the prior point.
>>>>
>>>> Conclusion:
>>>> GC is unfit for embedded systems. One of the most significant remaining
>>>> and compelling uses for a native systems language.
>>>>
>>>> The only realistic path I am aware of is to use ARC, which IS a form of GC,
>>>> and allows a lot more flexibility in the front-end.
>>>> GC forces one very particular paradigm upon you.
>>>> ARC is a GC, but it has some complex properties __which can be addressed in
>>>> various ways__. Unlike a GC which is entirely inflexible.
>>>>
>>>> You're not happy with ARC's cleaning objects up on the spot? Something that
>>>> many people WANT, but I understand zero cleanup times in the running
>>>> context is in other occasions a strength of GC; fine, just stick the
>>>> pointer on a dead list, and free it either later during idle time, or on
>>>> another thread. On the contrary, I haven't heard any proposal for a GC that
>>>> would allow it to operate in carefully controlled time-slices, or strictly
>>>> during idle-time.
>>>> Cycles are a problem with ARC? True, how much effort are you willing to
>>>> spend to mitigate the problem? None: run a secondary GC in the background
>>>> to collect cycles (yes, there is still a GC, but it has much less work to
>>>> do). Some: Disable background GC, manually require user specified weak
>>>> references and stuff. Note: A user-preferred combination of the 2 could
>>>> severely mitigate the workload of the background GC if it is still desired
>>>> to handle some complex situations, or user errors.
>>>> Are there any other disadvantages to ARC? I don't know of them if there are.
>>>>
>>>> Is far as I can tell, an ARC collector could provide identical convenience
>>>> as the existing GC for anyone that simply doesn't care. It would also seem
>>>> that it could provide significantly more options and control for those that
>>>> do.
>>>>
>>>> I am _yet to hear anyone present a realistic path forwards using any form
>>>> of GC_, so what else do I have to go with? Until I know of any other path
>>>> forward, I'll stand behind the only one I can see.
>>>> You're just repeating "I don't care about something that a significant
>>>> subset of D developers do care about, and I don't think any changes should
>>>> be made to support them".
>>>> As far as I know, a switch to ARC could be done in a way that 'regular'
>>>> users don't lose anything, or even notice... why is that so offensive?
>>>
>>> I am not trying to be a dick. But I do feel like a small number of people are trying to gang up on me for daring to point out that the solution they've proposed solution might have bigger problems for other people than they care to admit.
>>>
>>
>> The problem is that you are selfish. You won't let anyone in the
>> sand box to play with their toys... it's your sand box, even
>> though it's not. It's your toys, even though it's not. You pitch
>> a fit when someone comes into the sand box because you don't want
>> them their. They might mess up the sand.
>>
>> Why can't you get it through your thick skull that just because
>> people are suggesting alternative methods does not mean that you
>> can't have your precious AGC? Also, why is it so difficult that
>> just because you have no need for real-time applications that
>> others don't either?
>>
>> Your method of thinking is very arrogant and I wish you the best
>> of luck at the center of the universe... I hear it's a very
>> unfriendly place.
>
> Funny how you conveniently cut the thread immediately prior to paragraph where I say I would be all for supporting ARC side-by-side with the GC. It was only two paragraphs down, I can't imagine that it would've been that hard to include. I can only imagine that you left it off because it makes your name-calling look silly.
>
> However I did point out that making ARC the DEFAULT is unlikely to ever happen. Walter has consistently refused to approve much smaller breaking changes in the past. Why would he all-of-a-sudden decide that now is the time for the biggest breaking change in the history of D? I am just pointing out that the creator of D is not likely to approve that pull request while he is still breathing. Please don't shoot the messenger.

It has nothing to do with side by side. Who in their right mind
would argue that the AGC is bad in all cases? No one. Who wants
to deal with manual memory management when writing programs that
do not have real-time requirements?

But the fact remains, "D is AGC dependent" and "Some programs
perform poorly when used with AGC" means that D is a bad choice
for those programs, correct? So, your logic is that we are forced
to use D's GC if we want to use D because you think if ARC or MMM
is implemented you'll be forced to use it... and, of course, you
don't write RT apps so it's not your problem.

All we are asking is that D not be GC dependent. This allows one
to write RT apps, embedded apps, etc.

THIS DOES NOT MEAN you can't use a GC to handle your MM. It just
means there are other options, and by your pretentious stance
against "us" tells us you don't want D to change.

Why not join our team? We want AGC, ARC, MMM, MRC, etc. To do
this though D and phobos have to be lifted from the grips of the
GC. IT DOESN'T MEAN you'll have to manage the memory of phobo's.
You can still use the GC just like you do now without any
changes. You'll never know the difference. BUT WE WILL.

It will be the perfect world. We get what we want and you get
what you want. As it stands you, since you have been arguing
points against us, you must not agree with us, which means you do
not want us to be happy. Yet we want both of us to be happy. So
you must be wrong, unless you know for a fact that we both can't
be happy, which is non-sense(cause we can have AGC and ARC side
by side).

So which is it? Are you with us or against us? Do you want to rid
D and Phobos of the hardcoded AGC and allow for other methods of
MM? (hopefully you are intelligent enough to understand that this
doesn't mean that the AGC will go away or be any different to use)

[I'm also not in favor of ridding D of the AGC all together... I
don't think anyone is, it's there, it works for the most part for
most applications... it is handy and useful in many cases... BUT
NOT ALL. So stop pretending it is, and lets solve the problem]

Forums