View mode: basic / threaded / horizontal-split · Log in · Help
February 25, 2012
Re: John Carmack applauds D's pure attribute
On Saturday, 25 February 2012 at 18:47:12 UTC, Nick Sabalausky 
wrote:

> Interesting. I wish he'd elaborate on why it's not an option 
> for his daily
> work.

Not the design but the implementation, memory management would be 
the first.
February 25, 2012
Re: John Carmack applauds D's pure attribute
On Saturday, 25 February 2012 at 16:04:57 UTC, Trass3r wrote:
> http://twitter.com/#!/ID_AA_Carmack/status/173111220092682240

I think I could be to blame for that.

https://twitter.com/#!/Poita_/status/173106149669875712

Obviously he can't use D for his day to day work because they 
already have a massive codebase written in C++. Also, they need 
to generate PowerPC code and use lots of platforms specific tools 
and APIs that are all based around C++. It would simply be 
impractical to change over to D.
February 25, 2012
Re: John Carmack applauds D's pure attribute
On Saturday, 25 February 2012 at 20:13:42 UTC, so wrote:
> On Saturday, 25 February 2012 at 18:47:12 UTC, Nick Sabalausky 
> wrote:
>
>> Interesting. I wish he'd elaborate on why it's not an option 
>> for his daily
>> work.
>
> Not the design but the implementation, memory management would 
> be the first.

Memory management is not a problem. You can manage memory just as 
easily in D as you can in C or C++. Just don't use global new, 
which they'll already be doing.
February 25, 2012
Re: John Carmack applauds D's pure attribute
On Saturday, 25 February 2012 at 20:26:11 UTC, Peter Alexander 
wrote:

> Memory management is not a problem. You can manage memory just 
> as easily in D as you can in C or C++. Just don't use global 
> new, which they'll already be doing.

C++ standard library is not based around a GC.
D promises both MM possibilities yet its standard library as of 
now based around GC.

You are talking about design. When it comes to implementation, 
last time i checked, not using standard memory manager also means 
not using standard library.

A big codebase on another language is a problem shared by most of 
us and that is by far the most significant. Yet i thought we were 
talking about "why not switch to D" rather than "why not switch 
to another language".
February 25, 2012
Re: John Carmack applauds D's pure attribute
Am 25.02.2012 21:26, schrieb Peter Alexander:
> On Saturday, 25 February 2012 at 20:13:42 UTC, so wrote:
>> On Saturday, 25 February 2012 at 18:47:12 UTC, Nick Sabalausky wrote:
>>
>>> Interesting. I wish he'd elaborate on why it's not an option for his
>>> daily
>>> work.
>>
>> Not the design but the implementation, memory management would be the
>> first.
>
> Memory management is not a problem. You can manage memory just as easily
> in D as you can in C or C++. Just don't use global new, which they'll
> already be doing.

I couldn't agree more.

The GC issue comes around often, but I personally think that the main
issue is that the GC needs to be optimized, not that manual memory 
management is required.

Most standard compiler malloc()/free() implementations are actually 
slower than most advanced GC algorithms.

--
Paulo
February 25, 2012
Re: John Carmack applauds D's pure attribute
On Saturday, 25 February 2012 at 20:50:53 UTC, so wrote:
> On Saturday, 25 February 2012 at 20:26:11 UTC, Peter Alexander 
> wrote:
>
>> Memory management is not a problem. You can manage memory just 
>> as easily in D as you can in C or C++. Just don't use global 
>> new, which they'll already be doing.
>
> C++ standard library is not based around a GC.
> D promises both MM possibilities yet its standard library as of 
> now based around GC.
>
> You are talking about design. When it comes to implementation, 
> last time i checked, not using standard memory manager also 
> means not using standard library.
>
> A big codebase on another language is a problem shared by most 
> of us and that is by far the most significant. Yet i thought we 
> were talking about "why not switch to D" rather than "why not 
> switch to another language".

id, like most games developers, do not use the C++ standard 
library and they certainly wouldn't use the D standard library, 
so it's not an issue here. You're right in general, though.
February 25, 2012
Re: John Carmack applauds D's pure attribute
On Saturday, 25 February 2012 at 22:08:31 UTC, Paulo Pinto wrote:
> Am 25.02.2012 21:26, schrieb Peter Alexander:
>> On Saturday, 25 February 2012 at 20:13:42 UTC, so wrote:
>>> On Saturday, 25 February 2012 at 18:47:12 UTC, Nick 
>>> Sabalausky wrote:
>>>
>>>> Interesting. I wish he'd elaborate on why it's not an option 
>>>> for his
>>>> daily
>>>> work.
>>>
>>> Not the design but the implementation, memory management 
>>> would be the
>>> first.
>>
>> Memory management is not a problem. You can manage memory just 
>> as easily
>> in D as you can in C or C++. Just don't use global new, which 
>> they'll
>> already be doing.
>
> I couldn't agree more.
>
> The GC issue comes around often, but I personally think that 
> the main
> issue is that the GC needs to be optimized, not that manual 
> memory management is required.
>
> Most standard compiler malloc()/free() implementations are 
> actually slower than most advanced GC algorithms.

If you require realtime performance then you don't use either the 
GC or malloc/free. You allocate blocks up front and use those 
when you need consistent high performance.

It doesn't matter how optimised the GC is. The eventual 
collection is inevitable and if it takes anything more than a 
small fraction of a second then it will be too slow for realtime 
use.
February 25, 2012
Re: John Carmack applauds D's pure attribute
On Saturday, 25 February 2012 at 22:08:31 UTC, Paulo Pinto wrote:

> Most standard compiler malloc()/free() implementations are 
> actually slower than most advanced GC algorithms.

Explicit allocation/deallocation performance is not that 
significant, main problem is they are unreliable at runtime.
February 25, 2012
Re: John Carmack applauds D's pure attribute
Am 25.02.2012 23:17, schrieb Peter Alexander:
> On Saturday, 25 February 2012 at 22:08:31 UTC, Paulo Pinto wrote:
>> Am 25.02.2012 21:26, schrieb Peter Alexander:
>>> On Saturday, 25 February 2012 at 20:13:42 UTC, so wrote:
>>>> On Saturday, 25 February 2012 at 18:47:12 UTC, Nick Sabalausky wrote:
>>>>
>>>>> Interesting. I wish he'd elaborate on why it's not an option for his
>>>>> daily
>>>>> work.
>>>>
>>>> Not the design but the implementation, memory management would be the
>>>> first.
>>>
>>> Memory management is not a problem. You can manage memory just as easily
>>> in D as you can in C or C++. Just don't use global new, which they'll
>>> already be doing.
>>
>> I couldn't agree more.
>>
>> The GC issue comes around often, but I personally think that the main
>> issue is that the GC needs to be optimized, not that manual memory
>> management is required.
>>
>> Most standard compiler malloc()/free() implementations are actually
>> slower than most advanced GC algorithms.
>
> If you require realtime performance then you don't use either the GC or
> malloc/free. You allocate blocks up front and use those when you need
> consistent high performance.
>
> It doesn't matter how optimised the GC is. The eventual collection is
> inevitable and if it takes anything more than a small fraction of a
> second then it will be too slow for realtime use.
>

There are GC realtime algorithms, which are actually in use, in systems
like the French Ground Master 400 missile radar system.

There is no more realtime than that. I surely would not like that such
systems had a pause the world GC.

--
Paulo
February 25, 2012
Re: John Carmack applauds D's pure attribute
Am 25.02.2012 23:17, schrieb so:
> On Saturday, 25 February 2012 at 22:08:31 UTC, Paulo Pinto wrote:
>
>> Most standard compiler malloc()/free() implementations are actually
>> slower than most advanced GC algorithms.
>
> Explicit allocation/deallocation performance is not that significant,
> main problem is they are unreliable at runtime.
>
>

They seem to be reliable enough to control missile radar systems.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home