> You can find the full article at:
>
> http://3d.benjamin-thaut.de/?p=20#more-20
>

You make some good points about what happen under the hood.

Especially:
- homogeneous variadic function call allocate
- comparison of const object allocate
- useless druntime invariant handlers calls

I removed some homogeneous variadic function calls from my own
code.

Benjamin Thaut wrote:
> I rewrote a 3d game I created during my studies with D 2.0 to manual memory mangement. If I'm not studying I'm working in the 3d Engine deparement of Havok. As I needed to pratice manual memory management and did want to get rid of the GC in D for quite some time, I did go through all this effort to create a GC free version of my game.
> 
> The results are:
> 
>     DMD GC Version: 71 FPS, 14.0 ms frametime
>     GDC GC Version: 128.6 FPS, 7.72 ms frametime
>     DMD MMM Version: 142.8 FPS, 7.02 ms frametime

Interesting.
What about measuring a GDC MMM version? Because I wonder what is the GC
overhead. With DMD it's two. Maybe that factor is lower with GDC.

I would be interested in some numbers regarding memory overhead. To get a more complete picture of the impact on resources when using the GC.

Jens

On 9/6/2012 11:47 PM, Iain Buclaw wrote:
> On a side note of that though, GDC has bt, btr, bts, etc, as
> intrinsics to its compiler front-end.  So it would be no problem
> switching to version = bitops for version GNU.

Would it be easy to give that a try, and see what happens?

On 7 September 2012 10:31, Walter Bright <newshound2@digitalmars.com> wrote:
> On 9/6/2012 11:47 PM, Iain Buclaw wrote:
>>
>> On a side note of that though, GDC has bt, btr, bts, etc, as intrinsics to its compiler front-end.  So it would be no problem switching to version = bitops for version GNU.
>
>
> Would it be easy to give that a try, and see what happens?
>
>

Sure, can do.  Give me something to work against, and I will be able to produce the difference.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 9/7/2012 2:52 AM, Iain Buclaw wrote:
> On 7 September 2012 10:31, Walter Bright <newshound2@digitalmars.com> wrote:
>> On 9/6/2012 11:47 PM, Iain Buclaw wrote:
>>>
>>> On a side note of that though, GDC has bt, btr, bts, etc, as
>>> intrinsics to its compiler front-end.  So it would be no problem
>>> switching to version = bitops for version GNU.
>>
>>
>> Would it be easy to give that a try, and see what happens?
>>
>>
>
> Sure, can do.  Give me something to work against, and I will be able
> to produce the difference.

Well, gdc with and without it!

On Sep 6, 2012, at 10:57 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2012-09-07 01:53, Sean Kelly wrote:
> 
>> What version flags are set by GDC vs. DMD in your target apps?  The way "stop the world" is done on Linux vs. Windows is different, for example.
> 
> He's using only Windows as far as I understand, GDC MinGW.

Well sure, but MinGW is weird. I'd expect the Windows flag to be set for MinGW and both the Windows and Posix flags set for Cygwin, but it seemed worth asking. If Windows and Posix are both set, the Windows method will be used for "stop the world".

Am 07.09.2012 01:53, schrieb Sean Kelly:
> On Sep 6, 2012, at 10:50 AM, Benjamin Thaut <code@benjamin-thaut.de> wrote:
>
>> Am 06.09.2012 15:30, schrieb ponce:
>>>> The problem with intstrumentation is, that I can not recompile
>>>> druntime for the MinGW GDC, as this is not possible with the binary
>>>> release of MinGW GDC and I did not go thorugh the effort to setup the
>>>> whole build.
>>>> I'm open to suggestions though how I could profile the GC without
>>>> recompiling druntime. If someone else wants to profile this, I can
>>>> also provide precompiled versions of both versions.
>>>
>>> You don't necessarily need to recompile anything with a sampling
>>> profiler like AMD Code Analyst or Very Sleepy
>>>
>>
>> I just tried profiling it with Very Sleepy but basically it only tells me for both versions that most of the time is spend in gcx.fullcollect.
>> Just that the GDC version spends less time in gcx.fullcollect then the DMD version.
>>
>> As I can not rebuild druntime with GDC it will be quite hard to get detailed profiling results.
>>
>> I'm open for suggestions.
>
> What version flags are set by GDC vs. DMD in your target apps?  The way "stop the world" is done on Linux vs. Windows is different, for example.
>

I did build druntime and phobos with -release -noboundscheck -inline -O for DMD.
For MinGW GDC I just used whatever version of druntime and phobos came precompiled with it, so I can't tell you which flags have been used to compile that. But I can tell you that cygwin is not required to run or compile, so I think its not using any posix stuff.


I'm going to upload a zip-package with the source for the GC version soon, but I have to deal with some licence stuff first.

Kind Regards
Benjamin Thaut

On 9/7/12 6:31 PM, Benjamin Thaut wrote:
> I did build druntime and phobos with -release -noboundscheck -inline -O
> for DMD.
> For MinGW GDC I just used whatever version of druntime and phobos came
> precompiled with it, so I can't tell you which flags have been used to
> compile that. But I can tell you that cygwin is not required to run or
> compile, so I think its not using any posix stuff.
>
>
> I'm going to upload a zip-package with the source for the GC version
> soon, but I have to deal with some licence stuff first.
>
> Kind Regards
> Benjamin Thaut

You mentioned some issues in Phobos with memory allocation, that you had to replace with your own code. It would be awesome if you could post more about that, and possibly post a few pull requests where directly applicable.

Thanks,

Andrei

Am 07.09.2012 18:36, schrieb Andrei Alexandrescu:
>
> You mentioned some issues in Phobos with memory allocation, that you had
> to replace with your own code. It would be awesome if you could post
> more about that, and possibly post a few pull requests where directly
> applicable.
>
> Thanks,
>
> Andrei

Let me give a bit more details about what I did and why.

Druntime:

I added a reference counting mechanism. core.refcounted in my druntime branch.
I created a reference counted array which is as close to the native D array as currently possible (compiler bugs, type system issues, etc). also in core.refcounted. It however does not replace the default string or array type in all cases because it would lead to reference counting in uneccessary places. The focus is to get only reference couting where absolutly neccessary. I'm still using the standard string type as a "only valid for current scope" kind of string.
I created a allocator base interface which is used by everything that allocates, also I created replacement templates for new and delete.
Located in core.allocator
I created a new hashmap container wich is cache friendly and does not leak memory. Located in core.hashmap
I created a memory tracking allocator in core.allocator which can be turned on and off with a version statement (as it has to run before and after module ctors dtors etc)

I changed all parts of druntime that do string processing to use the reference counted array, so it no longer leaks. I made the Thread class reference counted so it no longer leaks. I fixed the type info comparsion and numerous other issues. Of all these changes only the type info fix will be easily convertible into the default druntime because it does not depend on any of my other stuff. I will do a merge request for this fix as soon as I find some time.

Phobos:
I threw away most of phobos because it didn't match my requirements.
The only modules I kept are
std.traits, std.random, std.math, std.typetuple, std.uni

The parts of these modules that I use have been changed so they don't leak memory. Mostly this comes down to use reference counted strings for exception error message generation.

I did require the option to specify a allocator for any function that allocates. Either by template argument, by function parameter or both, depending on the case. As custom allocators can not be pure this is a major issue with phobos, because adding allocators to the functions would make them unpure instantly. I know about the C-Linkage pure hack but its really a hack and it does not work for templates.

So I think most of my changes are not directly applicable because:

- You most likely won't like the way I implemented reference counting
- You might won't like my allocator design
- My standard library goes more into the C++ direction and is not as easly usable as phobos (as performance comes first for me, and usability is second)
- All my changes heavily depend on some of the functionality I added to druntime.
- The neccessary changes to phobos would break a lot of code because some of the function properties like pure couldn't be used any more, as a result of language limitations.

Kind Regards
Benjamin Thaut

The full sourcecode for the non-GC version is now aviable on github. The GC version will follow soon.

https://github.com/Ingrater/Spacecraft

Kind Regards
Benjamin Thaut