March 19, 2009
Weed wrote:
> + 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)

So you are optimizing for the uncommon case?
March 20, 2009
Denis Koroskin пишет:
> 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!

Not leak - that may be a reference to non-existent object.

The design of "invariant{}" does not reveal all problems with the class in all cases which compiled to the release. So that they abandon invariant{}?

Yes, this language is the same danger as the C++.
March 20, 2009
BCS пишет:
> 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.

This is a philosophical dispute.

A good and frequently used code can be written once and then used 10 years in 50 applications in 10000 installations. Here, the costs of programming may be less than the cost of end-user's time and hardware.

>>> 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.

Once again I repeat: forget about reference counting - it is only for the debug purposes. I think this addition should be switchable by compiler option.

It did not included into the resulting code. Ref-counting needed for multithreaded programs, when there is a risk to get and use a reference to an object that another process has already been killed. This situation needs to be recognized and issued to a run-time error.

This is addition to synchronization of threads, which is realized in D.
March 20, 2009
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.

It is designed not so. There will be a hidden dereferencing:

const ref Obj object -> struct{ Obj* object;    -> Obj object;
		       	        int counter; };

For all objects will be created such structs. "this" inside the object returns ptr to struct. Any appeal by reference to an object would cause such dereferencing.

Creating reference to object in a code block will cause an increase in the counter. Destruction of reference will cause an automatic decrease in the counter.

By the way, upon arrival into the try{} it will save values of reference counters for the correct exit if exception will be generated.

> 
> 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.
March 20, 2009
Simen Kjaeraas пишет:
> 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).
> 

Then a memory overrun

> 
>> 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,

Then some part of the language will stop working (dynamic arrays, and
possibly delegates)

> and malloc/free used in its place. What more is it you ask for?

I need an optional GC and complete freedom to use the stack.
March 20, 2009
Christopher Wright пишет:
> Weed wrote:
>> + 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)
> 
> So you are optimizing for the uncommon case?

GC is an attempt of optimizing for the uncommon case )
March 20, 2009
Weed wrote:
> Christopher Wright пишет:
>> Weed wrote:
>>> + 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)
>> So you are optimizing for the uncommon case?
> 
> GC is an attempt of optimizing for the uncommon case )

I don't think so. Programmers have more important things to do than write memory management systems. My boss would not be happy if I produced an application that leaked memory at a prodigious rate, and he would not be happy if I spent much time at all on memory management.

With the application I develop at work, we cache some things. These would have to be reference counted or deleted and recomputed every time. Reference counting is a lot of tedious developer effort. Recomputing is rather expensive. Deleting requires tedious developer effort and determining ownership of everything. This costs time and solves no problems for the customers.

And the best manual memory management that I am likely to write would not be faster than a good garbage collector.

What sort of applications do you develop? Have you used a garbage collector in a large application?
March 20, 2009
Weed wrote:
> Christopher Wright пишет:
>> 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.
> 
> It is designed not so. There will be a hidden dereferencing:
> 
> const ref Obj object -> struct{ Obj* object;    -> Obj object;
> 		       	        int counter; };

Okay, a language level feature, or a wrapper struct. That would work. If it's a library level feature, there's a problem of usage.
March 20, 2009
Weed <resume755@mail.ru> wrote:

> Simen Kjaeraas пишет:
>> 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).
>>
> 	
> Then a memory overrun

If so, you have allocated a lot of things you shouldn't have, or otherwise
would have the same problem using manual allocation.

>>> 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,
>
> Then some part of the language will stop working (dynamic arrays, and
> possibly delegates)

Yes. So don't use those parts, or disable the GC and enable it
when you have the time.
March 20, 2009
Simen Kjaeraas пишет:
> Weed <resume755@mail.ru> wrote:
> 
>> Simen Kjaeraas пишет:
>>> 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).
>>>
>> 
>> Then a memory overrun
> 
> If so, you have allocated a lot of things you shouldn't have, or otherwise would have the same problem using manual allocation.

No, as far as I know that some pieces of language does not imply a
manual release memory. (See below)

>>>> 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,
>>
>> Then some part of the language will stop working (dynamic arrays, and
>> possibly delegates)
> 
> Yes. So don't use those parts,

It is not impossible without blocking at the compiler level (by CLI
option) in the real world.

> or disable the GC and enable it
> when you have the time.

Again, the memory will be overrun)