View mode: basic / threaded / horizontal-split · Log in · Help
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
My mistake, this will only work if each is addRange()'d instead of 
searched by pool.

-[Unknown]


> Yes.
> 
> std.gc.removeRange(myArray);
> 
> As far as I recall.
> 
> But, iirc you do have to do this on a full range (e.g., not a sliced 
> array but the whole allocated array.)
> 
> -[Unknown]
> 
> 
>> Mars wrote:
>>> http://www.osnews.com/comment.php?news_id=16526
>>
>> RE[2]: Not much of an update
>>  > By luzr (2.10) on 2006-11-19 19:44:17 UTC in reply to "RE: Not much of
>>  > an update"
>>  >>I second that. D is a very nice language with a clear focus. My 
>> first  >>impression was that it has the best of Java, the best of C++ 
>> and none  >>of they're major weaknesses.
>>  >
>>  >Adds one major weekness - its memory model is based on conservative 
>> GC, >which makes it unpredictable and in reality unusable for some 
>> important >applications (like cryptography or any other software that 
>> deals with >noise-like data).
>>
>> This is one thing that bothers me with the current GC. If you store 
>> data with a lot of entropy in an array (Sound, encrypted data, sensor 
>> data, etc...) you start to experience memory leaks because the GC 
>> starts to see the data as references to other objects.
>>
>> Is there a way to tell the garbage collector "don't look for 
>> references here" without using malloc and friends?
>>
>> This would be for a standard sliceable garbage collected array with 
>> any kind of data except references. Something like 
>> gc.doNotLookForReferences(myArray) would be nice.
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
Georg Wrede wrote:
> BCS wrote:
>> One issue brought up is that of D "requiring" the use of a GC.
>> What would it take to prove that wrong by making a full blown standard 
>> lib that doesn't use a GC, and in fact doesn't have a GC?
>>
>> It would be painful to work with but no more so than in C++. OTOH with 
>> scope() and such, it might be easy.
>>
>> Anyway, just a thought.
> 
> Having such a library would make a huge difference in every C++ vs D 
> discussion! The opposition would have a lot less ammunition against us.

The ones who don't want to use D will find the first excuse, valid or 
not. Fix the excuse, and they'll just move on to the next excuse, valid 
or not. It's a fool's game. I've been around that circle before. The 
people we should listen to are the people who actually *use* D, not the 
ones who just glanced at a chart looking for fault.

The poster who claimed that conservative gc is somehow incompatible with 
cryptographic software is misinformed. Even if he were correct, the 
cryptographic buffers could be allocated with malloc() and would then 
have no effect whatsoever on the gc.
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
Bill Baxter wrote:
> Indeed.  The people who really need to be GC-free are a tiny minority. 
> Wasting a lot of manpower creating a non-GC library just people who 
> don't want to convert from C++ will have one less justification for not 
> using D sees like a huge waste of effort to me.

I translated Empire from C to D. It worked fine, and did not use the gc 
at all. It didn't require a new runtime library.
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
Dave wrote:
> But the whole concern centers around two canards: a) GC is really slow 
> and b) malloc/free offer deterministic performance for real-time 
> appplications.
> 
> I actually think that the best defense is dispelling those two myths. a) 
> for D will come in time and b) is just plain not true for general 
> purpose malloc/free implementations on modern operating systems.

If you talk to the people who actually do real time software, they don't 
use malloc/free precisely because they are not deterministic. They 
preallocate all data.
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
Walter Bright wrote:
> Dave wrote:
>> But the whole concern centers around two canards: a) GC is really slow 
>> and b) malloc/free offer deterministic performance for real-time 
>> appplications.
>>
>> I actually think that the best defense is dispelling those two myths. 
>> a) for D will come in time and b) is just plain not true for general 
>> purpose malloc/free implementations on modern operating systems.
> 
> If you talk to the people who actually do real time software, they don't 
> use malloc/free precisely because they are not deterministic. They 
> preallocate all data.

I'd like to see a standard response on the website along these lines.
Something like:

FAQ:
Q.Isn't GC slow and non-deterministic?
A. Yes, but *all* dynamic memory management is slow and 
non-deterministic. If you talk to the people who actually do real time 
software, they don't use malloc/free precisely because they are not 
deterministic. They preallocate all data.
However, the use of GC instead of malloc enables advanced language 
constructs (especially, more powerful array syntax), which greatly 
reduce the number of memory allocations which need to be made.
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
Don Clugston wrote:
> I'd like to see a standard response on the website along these lines.

Done.
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
On Sun, 19 Nov 2006 22:38:46 -0800, Walter Bright  
<newshound@digitalmars.com> wrote:

> The ones who don't want to use D will find the first excuse, valid or  
> not. Fix the excuse, and they'll just move on to the next excuse, valid  
> or not. It's a fool's game. I've been around that circle before. The  
> people we should listen to are the people who actually *use* D, not the  
> ones who just glanced at a chart looking for fault.
>


You're so right. :(

-JJR
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
> Indeed.  The people who really need to be GC-free are a tiny minority. 
> Wasting a lot of manpower creating a non-GC library just people who 
> don't want to convert from C++ will have one less justification for not 
> using D sees like a huge waste of effort to me.

What about game developers? At least with the current GC, although use 
of malloc/free isn't strictly deterministic, aren't you far less likely 
to end up with huge (by game standards, and hence unacceptable) pauses 
to execution? Preallocation of everything isn't always possible.
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
== Quote from Walter Bright (newshound@digitalmars.com)'s article
> If you talk to the people who actually do real time software, they don't
> use malloc/free precisely because they are not deterministic. They
> preallocate all data.

Preallocating all data is a lot of pain. Please consider adding something
to the language that would solve the problem. Some suggestion involve
opAssign and/or implicit casts. Also take a look at my suggestion for value
classes:
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=44163

Performance reason: I actually did some benchmarking, comparing
C++ stack allocated classes versus Java classes - C++ was ~30x faster
than Java and Java was ~20x faster than D.

I don't understand why a good RIAA is not already a part of D. C++ has it, so
it obviously can be done. The new 'scoped' keyword is insufficient for me,
because I'd like to make all my classes scoped. I can usually develop
99% of my C++ code without a single 'new' or 'malloc'. Most of my classes
are small (average ~2 fields and ~4 methods) and only used locally, so I'm
really angry when I think about negative performance impact they will have
in D simply because a decent RIAA is missing.
November 20, 2006
Re: OSNews article about C++09 degenerates into C++ vs. D discussion
Boris Kolar wrote:
> I don't understand why a good RIAA is not already a part of D. C++ has it, so
> it obviously can be done. The new 'scoped' keyword is insufficient for me,
> because I'd like to make all my classes scoped. I can usually develop
> 99% of my C++ code without a single 'new' or 'malloc'. Most of my classes
> are small (average ~2 fields and ~4 methods) and only used locally, so I'm
> really angry when I think about negative performance impact they will have
> in D simply because a decent RIAA is missing.

Have you considered using structs instead of classes? They are allocated 
on the stack.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home