On 04/07/2013 12:59 PM, Paulo Pinto wrote:
> ...
>
> The current compilers just don't have the amount of investment in more
> than 20 years of code optimization like C++ has. You cannot expect to
> achieve that from one moment to the other.
> ...

GDC certainly has. Parts of the runtime could use some investment.

>
> Nowadays the only place I do manual memory management is when writing
> Assembly code.
>

I do not buy that. Maintaining mutable state is a form of manual memory management.

08-Apr-2013 00:28, Timon Gehr пишет:
> On 04/07/2013 12:59 PM, Paulo Pinto wrote:
>> ...
>>
>> The current compilers just don't have the amount of investment in more
>> than 20 years of code optimization like C++ has. You cannot expect to
>> achieve that from one moment to the other.
>> ...
>
> GDC certainly has. Parts of the runtime could use some investment.
>

Similar understanding here. There is not a single thing D on GDC couldn't have that GCC has.

-- 
Dmitry Olshansky

I agree that language support for disabling the GC should exist. D, as I understand, is targeting C++ programmers (primarily). Those people are concerned about performance. If D as a systems programming language, can't deliver that, they aren't going to use it just because it has better templates (to name something).

Am 07.04.2013 22:28, schrieb Timon Gehr:
> On 04/07/2013 12:59 PM, Paulo Pinto wrote:
>> ...
>>
>> The current compilers just don't have the amount of investment in more
>> than 20 years of code optimization like C++ has. You cannot expect to
>> achieve that from one moment to the other.
>> ...
>
> GDC certainly has. Parts of the runtime could use some investment.
>
>>
>> Nowadays the only place I do manual memory management is when writing
>> Assembly code.
>>
>
> I do not buy that. Maintaining mutable state is a form of manual memory
> management.
>

I don't follow that.

Since 2002 I don't write any C code, only C++, JVM and .NET languages.

While at CERN, my team (Atlas HLT) had a golden rule, new and delete were only allowed in library code. Application code had to rely in stl, boost or CERN libraries own allocation mechanisms.

Nowadays 100% of the C++ code I write makes use of reference counting.

In the last month I started to port a toy compiler done in '99 on my last university year from Java 1.1 to Java 7, while updating the generated Assembly code and C based run time library.

It is the first time since 2002, I care to write manual memory management.

Why should maintaining mutable state be like manual memory management, if you have in place the required GC/reference counter helpers?

--
Paulo

Am 07.04.2013 22:49, schrieb Dmitry Olshansky:
> 08-Apr-2013 00:28, Timon Gehr пишет:
>> On 04/07/2013 12:59 PM, Paulo Pinto wrote:
>>> ...
>>>
>>> The current compilers just don't have the amount of investment in more
>>> than 20 years of code optimization like C++ has. You cannot expect to
>>> achieve that from one moment to the other.
>>> ...
>>
>> GDC certainly has. Parts of the runtime could use some investment.
>>
>
> Similar understanding here. There is not a single thing D on GDC
> couldn't have that GCC has.
>

Faire enough. I tend to only use dmd to play around with the language.

--
Paulo

Am 07.04.2013 23:07, schrieb Minas Mina:
> I agree that language support for disabling the GC should exist. D, as I
> understand, is targeting C++ programmers (primarily). Those people are
> concerned about performance. If D as a systems programming language,
> can't deliver that, they aren't going to use it just because it has
> better templates (to name something).

Just as an example.

This startup sells Oberon compilers for embedded boards (Cortex-M3 and NXP LPC2000)

http://www.astrobe.com/default.htm

You get a normal GC systems programming language running on bare metal on these systems.

Surely it also allows for manual memory management in modules that import the pseudo module SYSTEM, similar to system code in D.

The company exists since 1997, so they must be doing something right.

On my modest opinion this and improving the GC's current performance would be enough.

Or maybe have the option to use reference counting instead of GC, but not disabling automatic memory management altogether.

--
Paulo

On 04/07/2013 11:11 PM, Paulo Pinto wrote:
> ...
>
> Why should maintaining mutable state be like manual memory management,
> if you have in place the required GC/reference counter helpers?
>
> ...

Every time a variable is reassigned, its old value is destroyed.

Am 08.04.2013 00:27, schrieb Timon Gehr:
> On 04/07/2013 11:11 PM, Paulo Pinto wrote:
>> ...
>>
>> Why should maintaining mutable state be like manual memory management,
>> if you have in place the required GC/reference counter helpers?
>>
>> ...
>
> Every time a variable is reassigned, its old value is destroyed.

I do have functional and logic programming background and still fail to see how that is manual memory management.


--
Paulo

On Sunday, 7 April 2013 at 20:20:52 UTC, Martin Nowak wrote:
>> I also use a modified druntime that prints callstacks when a GC allocation occurs, so I know if it happens by accident.
>
> I'd happily welcome any patches that get rid of GC usage in druntime.

I meant that it prints a callstack whenever *anything* uses the GC, not just druntime.

On 04/08/2013 12:33 AM, Paulo Pinto wrote:
> Am 08.04.2013 00:27, schrieb Timon Gehr:
>> On 04/07/2013 11:11 PM, Paulo Pinto wrote:
>>> ...
>>>
>>> Why should maintaining mutable state be like manual memory management,
>>> if you have in place the required GC/reference counter helpers?
>>>
>>> ...
>>
>> Every time a variable is reassigned, its old value is destroyed.
>
> I do have functional and logic programming background and still fail to
> see how that is manual memory management.
>
>
> --
> Paulo

What would be a feature that clearly distinguishes the two?