March 19, 2009
Hello Weed,

> BCS ?????:
> 
>> Reply to Weed,
>> 
>>> If you know the
>>> best way for language *without GC* guaranteeing the existence of an
>>> object without overhead - I have to listen!
>> Never delete anything?
>> 
>> One of the arguments for GC is that it might well have /less/
>> overhead than any other practical way of managing dynamic memory.
>> 
> Mmm
> When I say "overhead" I mean the cost of executions, and not cost of
> programming

So do I.

I figure unless it save me more times than it costs /all/ the users, run time cost trumps. 

>> Yes you can be
>> very careful in keeping track of pointers (not practical) or use
>> smart
>> pointers and such (might end up costing more than GC)
> I am do not agree: GC overexpenditure CPU or memory. Typically, both.

ditto naryl on CPU

As for memory, unless the thing overspends into swap and does so very quickly (many pages per second) I don't think that matters. This is because most of the extra will not be part of the resident set so the OS will start paging it out to keep some free pages. This is basically free until you have the CPU or HDD locked hard at 100%. The other half is that the overhead of reference counting and/or the like will cost in memory (you have to store the count somewhere) and might also have bad effects regarding cache misses.

> 
>> but neither is
>> particularly nice.


March 19, 2009
naryl пишет:
> Weed Wrote:
>> BCS яПНяПНяПНяПНяПН:
>>> Yes you can be
>>> very careful in keeping track of pointers (not practical) or use smart
>>> pointers and such (might end up costing more than GC)
>> I am do not agree: GC overexpenditure CPU or memory. Typically, both.
> 
> I wouldn't be so sure about CPU: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gdc&lang2=gpp&box=1

You should not compare benchmarks - they depend on the quality of the testing code.

But it is important to provide an opportunity to write a program efficiently.
March 19, 2009
Weed Wrote:
> naryl �����:
> > Weed Wrote:
> >> BCS ���������������:
> >>> Yes you can be
> >>> very careful in keeping track of pointers (not practical) or use smart
> >>> pointers and such (might end up costing more than GC)
> >> I am do not agree: GC overexpenditure CPU or memory. Typically, both.
> > 
> > I wouldn't be so sure about CPU: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gdc&lang2=gpp&box=1
> 
> You should not compare benchmarks - they depend on the quality of the testing code.

Then find a way to prove that GC costs more CPU time than explicit memory management and/or reference counting.
March 19, 2009
Robert Jacques пишет:

> *sigh* All memory allocation must make some kernel calls. D's GC makes fewer calls than a traditional malloc. Actually,  modern malloc replacements imitate the way GCs allocate memory since it's a lot faster. (Intel's threading building blocks mentions this as part of its marketing and performance numbers, so modern mallocs are probably not that common)
> 
>>
>>> and 2) requires a
>>> global lock on access.
>>
>> Who?
> 
> Traditional malloc requires taking global lock (and as point 1, often a kernel lock. Again, fixing this issue is one of Intel's TBB's marketing/performance points)
> 
>>> Yes, there are several alternatives available
>>> now, but the same techniques work for enabling multi-threaded GCs. D's
>>> shared/local model should support thread local heaps, which would
>>> improve all of the above.
>>
>> It does not prevent pre-create the objects, or to reserve memory for them in advance. (This is what makes the GC, but a programmer would do it better)
> 
> I think the point you're trying to make is that a GC is more memory intensive.

+ Sometimes allocation and freeing of memory in an arbitrary unpredictable time  unacceptable. (in game development or realtime software, for example. One hundred million times discussed about it there, I guess)

> Actually, since fast modern mallocs and GC share the same
> underlying allocation techniques, they have about the same memory usage,
> etc. Of course, a traditional malloc with aggressive manual control can
> often return memory to the kernel in a timely manner, so a program's
> memory allocation better tracks actual usage as opposed to the maximum.
> Doing so is very performance intensive and GCs can return memory to the
> system too (Tango's does if I remember correctly).
> 

I think so: during the performance of malloc is controlled by the OS. And it is so does the optimization of memory allocation for programs. And OS has more facilities to do this. GC there will be just extra layer.

A need language that does not contain a GC (or contains optional). Many C++ programmers do not affect the D only because of this.
March 19, 2009
naryl пишет:
> Weed Wrote:
>> naryl яПНяПНяПНяПНяПН:
>>> Weed Wrote:
>>>> BCS яПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПН:
>>>>> Yes you can be
>>>>> very careful in keeping track of pointers (not practical) or use smart
>>>>> pointers and such (might end up costing more than GC)
>>>> I am do not agree: GC overexpenditure CPU or memory. Typically, both.
>>> I wouldn't be so sure about CPU: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gdc&lang2=gpp&box=1
>> You should not compare benchmarks - they depend on the quality of the testing code.
> 
> Then find a way to prove that GC costs more CPU time than explicit memory management and/or reference counting.

I suggest that reference counting for -debug.
Yes, it slows down a bit. As invariant{}, in{}, out(){}, assert()
March 19, 2009
On Thu, 19 Mar 2009 19:54:10 +0300, Weed <resume755@mail.ru> wrote:

> naryl пишет:
>> Weed Wrote:
>>> naryl яПНяПНяПНяПНяПН:
>>>> Weed Wrote:
>>>>> BCS яПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПНяПН:
>>>>>> Yes you can be
>>>>>> very careful in keeping track of pointers (not practical) or use smart
>>>>>> pointers and such (might end up costing more than GC)
>>>>> I am do not agree: GC overexpenditure CPU or memory. Typically, both.
>>>> I wouldn't be so sure about CPU:
>>>> http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=gdc&lang2=gpp&box=1
>>> You should not compare benchmarks - they depend on the quality of the
>>> testing code.
>>
>> Then find a way to prove that GC costs more CPU time than explicit memory management and/or reference counting.
>
> I suggest that reference counting for -debug.
> Yes, it slows down a bit. As invariant{}, in{}, out(){}, assert()

Yeah, ref-count your objects in debug and let the memory leak in release!
March 19, 2009
Reply to Weed,

> I think so: during the performance of malloc is controlled by the OS.
> And it is so does the optimization of memory allocation for programs.
> And OS has more facilities to do this. GC there will be just extra
> layer.

malloc is not a system call. malloc make systems calls (IIRC mmap) once in a while to ask for more memory to be mapped in but I think that D's GC also works that way.


March 19, 2009
Weed <resume755@mail.ru> wrote:

>> I think the point you're trying to make is that a GC is more memory
>> intensive.
>
> + Sometimes allocation and freeing of memory in an arbitrary
> unpredictable time  unacceptable. (in game development or realtime
> software, for example. One hundred million times discussed about it
> there, I guess)

Then use the stub GC or disable the GC, then re-enable it when
you have the time to run a sweep (yes, you can).


> A need language that does not contain a GC (or contains optional). Many
> C++ programmers do not affect the D only because of this.

While GC in D is not optional, it can be stubbed out or disabled,
and malloc/free used in its place. What more is it you ask for?
March 19, 2009
Reply to Weed,

> + Sometimes allocation and freeing of memory in an arbitrary
> unpredictable time  unacceptable. (in game development or realtime
> software, for example. One hundred million times discussed about it
> there, I guess)

This issue is in no way special to GC systems, IIRC malloc has no upper limit on it's run time.

Yes GC has some down sides, yes non GC has some down sides. Take your pick or use a language that lets you do both (like D).


March 19, 2009
Weed wrote:
> Christopher Wright пишет:
> 
> 
>>>>>> And regarding performance, eventually it will come a lot from a good
>>>>>> usage of multiprocessing,
>>>>> The proposal will be able support multiprocessing - for it provided a
>>>>> references counting in the debug version of binaries. If you know the
>>>>> best way for language *without GC* guaranteeing the existence of an
>>>>> object without overhead - I have to listen!
>>>> You cannot alter the reference count of an immutable variable.
>>> Why?
>> Because it's immutable!
>>
>> Unless you're storing a dictionary of objects to reference counts
>> somewhere, that is. Which would be hideously slow and a pain to use. Not
>> that reference counting is fun.
> 
> 
> Precisely. I wrote the cost for that: 1 dereferencing + inc/dec of counter.

It's more expensive than dereferencing. If your const object points to its reference count, then the reference count is also const, so you can't alter it.

So the best you can possibly do is one hashtable lookup for every time you alter the reference count for a non-mutable variable. That is a huge overhead, much more so than garbage collection.