David (or anyone else capable of doing it), are you planning on releasing an updated GDC anytime soon?  My program uses features introduced in 0.99, so it don't work too well with GDC.

Thanks
John

teqDruid wrote:
> David (or anyone else capable of doing it), are you planning on releasing
> an updated GDC anytime soon?  My program uses features introduced in 0.99,
> so it don't work too well with GDC.
> 
> Thanks
> John

GDC is synched up to DMD 0.102 and am I now regression testing.  If there are no serious setbacks, I will release a new version this weekend.

David

David Friedman wrote:
> GDC is synched up to DMD 0.102 and am I now regression testing.  If there are no serious setbacks, I will release a new version this weekend.
> 
> David
> 

I am looking forward to this weekend for yet one more reason then :)
I would appreciate if you provided your test suite so I could do some amd64 tests, once I manage to build gdc.

Also, if I can help you without challenging my less than awesome coding skills, I would like to assist.

-ben

Awesome! You da man David!

John

On Tue, 28 Sep 2004 08:05:26 -0500, David Friedman wrote:

> teqDruid wrote:
>> David (or anyone else capable of doing it), are you planning on releasing an updated GDC anytime soon?  My program uses features introduced in 0.99, so it don't work too well with GDC.
>> 
>> Thanks
>> John
> 
> GDC is synched up to DMD 0.102 and am I now regression testing.  If there are no serious setbacks, I will release a new version this weekend.
> 
> David

Benjamin Herr wrote:
> David Friedman wrote:
> 
>> GDC is synched up to DMD 0.102 and am I now regression testing.  If there are no serious setbacks, I will release a new version this weekend.
>>
>> David
>>
> 
> I am looking forward to this weekend for yet one more reason then :)
> I would appreciate if you provided your test suite so I could do some amd64 tests, once I manage to build gdc.
> 
> Also, if I can help you without challenging my less than awesome coding skills, I would like to assist.
> 
> -ben

I'll try to put something toghether that is usable ;-)

Although the compiler can generate 64-bit code, the RTTI pieces and Phobos assume 32-bit in a lot places. Still, please do try it out to the extent that it is possible.

David

David Friedman wrote:

> teqDruid wrote:
>> David (or anyone else capable of doing it), are you planning on releasing an updated GDC anytime soon?  My program uses features introduced in 0.99, so it don't work too well with GDC.
>> 
>> Thanks
>> John
> 
> GDC is synched up to DMD 0.102 and am I now regression testing.  If there are no serious setbacks, I will release a new version this weekend.
> 
> David

excellent news! Thanks for not letting GDC drop.

<posted & mailed>

David Friedman wrote:

> teqDruid wrote:
>> David (or anyone else capable of doing it), are you planning on releasing an updated GDC anytime soon?  My program uses features introduced in 0.99, so it don't work too well with GDC.
>> 
>> Thanks
>> John
> 
> GDC is synched up to DMD 0.102 and am I now regression testing.  If there are no serious setbacks, I will release a new version this weekend.
> 
> David

David - thanks for all of your work on this!!

I would like to suggest a couple of changes to the default D -> GCC compiler option mappings:

(In decending order of importance)

-O implies -fno-bounds-check by default
-O implies -fomit-frame-pointer
-O implies -fweb and -fgcse-after-reload
-O implies -mcpu=pentium4 (>= 3.4.x: -mtune=pentium4)
Also add the -funroll-loops option.

Rationale (sorry, this gets a bit long):

The DMD 'reference compiler' turns off bounds checking with -0 and of course this can really make a large difference. From my understanding in following the NG threads it's pretty well accepted and understood by D users that -O will do this.

-fomit-frame-pointer is something that (I've read) the GCC group has been discussing making implied for x86 with any -O option in coming versions of GCC (The docs. for <= 3.4.x said it was implied by -O[n] for x86 but it turns out it actually isn't currently..). D code should not have the legacy debugging issues to deal with and from what I've seen this switch can make a big difference in code speed where a lot of functions are being called.

-fweb and -fgcse-after-reload.. Along with the -inline switch, this will bring the optimization up to '-O3' levels. I've used -O3 to good effect for a couple of production executables and seen it make a big difference in benchmarks as well - I've also never seen it degrade performance. I'm seeing a number of make files starting to use this option.

-mtune=pentium4 - Can make a sizeable difference for P4 while not really effecting < P4 machines. Of course, the most performance intensive applications will be run on P4 class machines.

Unroll loops - GCC seems to be getting pretty good at this and I've seen it make a difference in production code with GCC >= 3.3.x.

The overall rationale for these changes is simply to make sure the GCC implementation of D puts its 'best foot' forward so D doesn't get needlessly/unfairly tagged with performance issues that can be avoided with default -O swtiches.

I've noticed that many of the 'GCC vs X' benchmarks out there for which GCC does poorly are often due to /not/ applying the (perfectly legimate) -O3 and -fomit-frame-pointer switches. Besides, the 'competition' from Intel, MS, etc.. generally optimize with levels comparable to -O3 with any of their default 'for speed' switches.

If there is some regression testing or something that I could help with if/when these changes are made, I'd be glad to do what I can..

Thanks,

- Dave

Dave wrote:
> <posted & mailed>
> 
> David Friedman wrote:
> 
> 
>>teqDruid wrote:
>>
>>>David (or anyone else capable of doing it), are you planning on releasing
>>>an updated GDC anytime soon?  My program uses features introduced in
>>>0.99, so it don't work too well with GDC.
>>>
>>>Thanks
>>>John
>>
>>GDC is synched up to DMD 0.102 and am I now regression testing.  If
>>there are no serious setbacks, I will release a new version this weekend.
>>
>>David
> 
> 
> David - thanks for all of your work on this!!
> 
> I would like to suggest a couple of changes to the default D -> GCC compiler
> option mappings:
> 
> (In decending order of importance)
> 
> -O implies -fno-bounds-check by default
> -O implies -fomit-frame-pointer
> -O implies -fweb and -fgcse-after-reload
> -O implies -mcpu=pentium4 (>= 3.4.x: -mtune=pentium4)
> Also add the -funroll-loops option.
> 
> Rationale (sorry, this gets a bit long):
> 
> The DMD 'reference compiler' turns off bounds checking with -0 and of course
> this can really make a large difference. From my understanding in following
> the NG threads it's pretty well accepted and understood by D users that -O
> will do this.
> 
> -fomit-frame-pointer is something that (I've read) the GCC group has been
> discussing making implied for x86 with any -O option in coming versions of
> GCC (The docs. for <= 3.4.x said it was implied by -O[n] for x86 but it
> turns out it actually isn't currently..). D code should not have the legacy
> debugging issues to deal with and from what I've seen this switch can make
> a big difference in code speed where a lot of functions are being called.
> 
> -fweb and -fgcse-after-reload.. Along with the -inline switch, this will
> bring the optimization up to '-O3' levels. I've used -O3 to good effect for
> a couple of production executables and seen it make a big difference in
> benchmarks as well - I've also never seen it degrade performance. I'm
> seeing a number of make files starting to use this option.
> 
> -mtune=pentium4 - Can make a sizeable difference for P4 while not really
> effecting < P4 machines. Of course, the most performance intensive
> applications will be run on P4 class machines.
> 
> Unroll loops - GCC seems to be getting pretty good at this and I've seen it
> make a difference in production code with GCC >= 3.3.x.
> 
> The overall rationale for these changes is simply to make sure the GCC
> implementation of D puts its 'best foot' forward so D doesn't get
> needlessly/unfairly tagged with performance issues that can be avoided with
> default -O swtiches.
> 
> I've noticed that many of the 'GCC vs X' benchmarks out there for which GCC
> does poorly are often due to /not/ applying the (perfectly legimate) -O3
> and -fomit-frame-pointer switches. Besides, the 'competition' from Intel,
> MS, etc.. generally optimize with levels comparable to -O3 with any of
> their default 'for speed' switches.
> 
> If there is some regression testing or something that I could help with
> if/when these changes are made, I'd be glad to do what I can..
> 
> Thanks,
> 
> - Dave
> 

Dave,

-fweb and -fomit-frame-pointer: I'll add these (along with -frename-registers).
-fgcse-after-reload: does not seem to be in recent GCC versions.
-mtune and -funroll-loops: I need to do some checking on these...

What was the reference for -O turning off bounds checking?  I made a quick test of bounds checking with -O and I still got an ArrayBoundsError.

FYI, anyone comparing GCC to DMD is going to see GCC lagging behind a bit as there are some x86 optimizations that require extra coding.  I still need to make D linkage functions use the same calling conventions as DMD (effectively, -mregparm=1 and -freg-struct-return.)

David

David Friedman wrote:

> Dave wrote:
>> <posted & mailed>
[snip]
>> 
> 
> Dave,
> 
> -fweb and -fomit-frame-pointer: I'll add these (along with
> -frename-registers).
> -fgcse-after-reload: does not seem to be in recent GCC versions.
> -mtune and -funroll-loops: I need to do some checking on these...
> 
> What was the reference for -O turning off bounds checking?  I made a quick test of bounds checking with -O and I still got an ArrayBoundsError.
>

Oops, sorry - for DMD, ArrayBoundsChecking is removed with '-release', not '-O'.

Since GDC offers -f[no-]bounds-check seperately, I guess I assumed that bounds checking is controlled independently of other switch(es).

I don't have a machine available right now to install GDC and give this a shot myself.. If '-release' already implies -fno-bounds-check please disregard.

Thanks again,

- Dave

> 
> FYI, anyone comparing GCC to DMD is going to see GCC lagging behind a bit as there are some x86 optimizations that require extra coding.  I still need to make D linkage functions use the same calling conventions as DMD (effectively, -mregparm=1 and -freg-struct-return.)
> 
> David

Dave wrote:
> David Friedman wrote:
> 
> 
>>Dave wrote:
>>
>>><posted & mailed>
> 
> [snip]
> 
>>Dave,
>>
>>-fweb and -fomit-frame-pointer: I'll add these (along with
>>-frename-registers).
>>-fgcse-after-reload: does not seem to be in recent GCC versions.
>>-mtune and -funroll-loops: I need to do some checking on these...
>>
>>What was the reference for -O turning off bounds checking?  I made a
>>quick test of bounds checking with -O and I still got an ArrayBoundsError.
>>
> 
> 
> Oops, sorry - for DMD, ArrayBoundsChecking is removed with '-release', not
> '-O'.
> 
> Since GDC offers -f[no-]bounds-check seperately, I guess I assumed that
> bounds checking is controlled independently of other switch(es).
> 
> I don't have a machine available right now to install GDC and give this a
> shot myself.. If '-release' already implies -fno-bounds-check please
> disregard.

It does.  I implemented -fbounds-check because it is actually defined as  a common option across all GCC compilers.  It's interesting considering that the most popular languages don't use it!

David

> 
> Thanks again,
> 
> - Dave
> 
> 
>>FYI, anyone comparing GCC to DMD is going to see GCC lagging behind a
>>bit as there are some x86 optimizations that require extra coding.  I
>>still need to make D linkage functions use the same calling conventions
>>as DMD (effectively, -mregparm=1 and -freg-struct-return.)
>>
>>David
> 
>