April 23, 2014
23-Apr-2014 12:12, Walter Bright пишет:
> On 4/23/2014 12:20 AM, Kagamin wrote:
>> On Wednesday, 23 April 2014 at 06:39:04 UTC, Walter Bright wrote:
>>> I made a build of dmd with a collector in it. It destroyed the speed.
>>> Took it
>>> out.
>>
>> Is it because of garbage collections? Then allow people configure
>> collection
>> threshold, say, collect garbage only when the heap is bigger than 16GB.
>
> It's more than that. I invite you to read the article I wrote on DrDobbs
> a while back about changes to the allocator to improve speed.
>
> tl;dr: allocation is a critical speed issue with dmd. Using the
> bump-pointer method is very fast, and it matters.

This stinks it's not even half-serious. A x2 speed increase was due to scraping the old allocator on Win32 altogether and using plain HeapAPI.

If the prime reason compilation is fast is because we just throw away memory, we must be doing something wrong, very wrong.

-- 
Dmitry Olshansky
April 23, 2014
On Wed, 23 Apr 2014 02:39:05 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 4/22/2014 11:33 PM, Dmitry Olshansky wrote:
>> At a times I really don't know why can't we just drop in a Boehm GC (the stock
>> one, not homebrew stuff) and be done with it. Speed? There is no point in speed
>> if it leaks that much.
>
> I made a build of dmd with a collector in it. It destroyed the speed. Took it out.

The time it takes to compile a program where the compiler consumes 2G of ram on a 2G machine is infinite ;)

There must be some compromise between slow-but-perfect memory management and invoking the OOM killer.

-Steve
April 23, 2014
"Dmitry Olshansky"  wrote in message news:lj7mrr$1p5s$1@digitalmars.com... 

> At a times I really don't know why can't we just drop in a Boehm GC (the stock one, not homebrew stuff) and be done with it. Speed? There is no point in speed if it leaks that much.

Or you know, switch to D and use druntime's GC.
April 23, 2014
On 4/23/2014 2:00 AM, Dmitry Olshansky wrote:
> If the prime reason compilation is fast is because we just throw away memory, we
> must be doing something wrong, very wrong.

I've tried adding a collector to DMD with poor results. If you'd like to give it a try as well, please do so.

The thing is, I work all day every day on D. I cannot do more. If people want more things done, like redesigning memory allocation in the compiler, redesigning D to do ARC, etc., they'll need to pitch in.

April 23, 2014
23-Apr-2014 20:56, Daniel Murphy пишет:
> "Dmitry Olshansky"  wrote in message news:lj7mrr$1p5s$1@digitalmars.com...
>> At a times I really don't know why can't we just drop in a Boehm GC
>> (the stock one, not homebrew stuff) and be done with it. Speed? There
>> is no point in speed if it leaks that much.
>
> Or you know, switch to D and use druntime's GC.

Good point. Can't wait to see D-only codebase.

-- 
Dmitry Olshansky
April 23, 2014
On 4/23/14, 1:56 PM, Daniel Murphy wrote:
> "Dmitry Olshansky"  wrote in message news:lj7mrr$1p5s$1@digitalmars.com...
>> At a times I really don't know why can't we just drop in a Boehm GC
>> (the stock one, not homebrew stuff) and be done with it. Speed? There
>> is no point in speed if it leaks that much.
>
> Or you know, switch to D and use druntime's GC.

But that will be slow.

Walter's point is that if you introduce a GC it will be slower.

Of course, you won't be able to compile big stuff. But developers usually have good machines, so it's not that a big deal.
April 23, 2014
23-Apr-2014 21:16, Walter Bright пишет:
> On 4/23/2014 2:00 AM, Dmitry Olshansky wrote:
>> If the prime reason compilation is fast is because we just throw away
>> memory, we
>> must be doing something wrong, very wrong.
>
> I've tried adding a collector to DMD with poor results. If you'd like to
> give it a try as well, please do so.
>

I'll give it a spin then.

> The thing is, I work all day every day on D. I cannot do more.

That is understood, thanks for honesty.

> If people
> want more things done, like redesigning memory allocation in the
> compiler, redesigning D to do ARC, etc., they'll need to pitch in.
>
True.

-- 
Dmitry Olshansky
April 23, 2014
On Wednesday, 23 April 2014 at 17:16:40 UTC, Walter Bright wrote:
> On 4/23/2014 2:00 AM, Dmitry Olshansky wrote:
>> If the prime reason compilation is fast is because we just throw away memory, we
>> must be doing something wrong, very wrong.
>
> I've tried adding a collector to DMD with poor results. If you'd like to give it a try as well, please do so.
>
> The thing is, I work all day every day on D. I cannot do more. If people want more things done, like redesigning memory allocation in the compiler, redesigning D to do ARC, etc., they'll need to pitch in.

Well said Walter!

April 23, 2014
On Wednesday, 23 April 2014 at 15:46:00 UTC, Steven Schveighoffer wrote:
> The time it takes to compile a program where the compiler consumes 2G of ram on a 2G machine is infinite ;)

(nitpick: not necessarily given good swap behaviour!)
April 23, 2014
> tl;dr: allocation is a critical speed issue with dmd. Using the bump-pointer method is very fast, and it matters.

What about packing DMD structure members such as integers and enums more efficiently?

We could start with making enums __attribute__((packed)). Is there any free static/dynamic tool to check for unexercized bits?

How does Clang do to save so much space compared to GCC? Do they pack gentlier or use deallocation?

A much higher-hanging fruit is to switch from using pointers to 32-bit handles on 64-bit CPUs to reference tokens, sub-expressions etc. But I guess that is a big undertaking getting type-safe and may give performance hits.