And one way (with DigitalMars C/C++)

[Paul Hunter]

Geschrieben von:/Posted by: Paul Hunter at 15 April 2004 02:27:58:

Crafty built with this free compiler surprised me. It is definitely faster than that built with Mingw.
http://www.geocities.com/alternativecra ... lmars.html
If inline assembly is done for this compiler, it might approach the binary speeds of the MS-VC build, but this one, for free!
Raw nodes per second: 971025
Total elapsed time: 97
SMP time-to-ply measurement: 6.597938
There is however a problem with displays. So, for now, the only way to get it to work in Winboard is not to enable "post" - that is, do not turn-on the WB option for thinking lines (PV display).
The issue is that the compiler does not properly interpret strings of the format "..." "..." "..." as just one string.
In the crafty code, this is used a lot to encapsulate the format string for 64-bit integers (see macros BMF, BMF6, etc., and their use in printf's).
The DigitalMars build is usable and fast. Just don't turn-on PV display.
I'll see what I can do to make the PV output work with minimal code change.

[Dann Corbit]

Geschrieben von:/Posted by: Dann Corbit at 15 April 2004 02:44:11:
Als Antwort auf:/In reply to: And one way (with DigitalMars C/C++) geschrieben von:/posted by: Paul Hunter at 15 April 2004 02:27:58:

Crafty built with this free compiler surprised me. It is definitely faster than that built with Mingw.
http://www.geocities.com/alternativecra ... lmars.html
If inline assembly is done for this compiler, it might approach the binary speeds of the MS-VC build, but this one, for free!
Raw nodes per second: 971025
Total elapsed time: 97
SMP time-to-ply measurement: 6.597938
There is however a problem with displays. So, for now, the only way to get it to work in Winboard is not to enable "post" - that is, do not turn-on the WB option for thinking lines (PV display).
The issue is that the compiler does not properly interpret strings of the format "..." "..." "..." as just one string.
In the crafty code, this is used a lot to encapsulate the format string for 64-bit integers (see macros BMF, BMF6, etc., and their use in printf's).
The DigitalMars build is usable and fast. Just don't turn-on PV display.
I'll see what I can do to make the PV output work with minimal code change.

The compiler is broken then. That is part of the ANSI/ISO standard.
Send a bug report to the author. It's a serious defect.



my ftp site {remove http:// unless you like error messages}

[Dann Corbit]

Geschrieben von:/Posted by: Dann Corbit at 15 April 2004 02:45:15:
Als Antwort auf:/In reply to: And one way (with DigitalMars C/C++) geschrieben von:/posted by: Paul Hunter at 15 April 2004 02:27:58:

http://www.cs.virginia.edu/~lcc-win32/


my ftp site {remove http:// unless you like error messages}

[Paul Hunter]

Geschrieben von:/Posted by: Paul Hunter at 15 April 2004 02:53:06:
Als Antwort auf:/In reply to: Re: And one way (with DigitalMars C/C++) geschrieben von:/posted by: Dann Corbit at 15 April 2004 02:44:11:

Crafty built with this free compiler surprised me. It is definitely faster than that built with Mingw.
http://www.geocities.com/alternativecra ... lmars.html
If inline assembly is done for this compiler, it might approach the binary speeds of the MS-VC build, but this one, for free!
Raw nodes per second: 971025
Total elapsed time: 97
SMP time-to-ply measurement: 6.597938
There is however a problem with displays. So, for now, the only way to get it to work in Winboard is not to enable "post" - that is, do not turn-on the WB option for thinking lines (PV display).
The issue is that the compiler does not properly interpret strings of the format "..." "..." "..." as just one string.
In the crafty code, this is used a lot to encapsulate the format string for 64-bit integers (see macros BMF, BMF6, etc., and their use in printf's).
The DigitalMars build is usable and fast. Just don't turn-on PV display.
I'll see what I can do to make the PV output work with minimal code change.

The compiler is broken then. That is part of the ANSI/ISO standard.
Send a bug report to the author. It's a serious defect.

Oops. Actually it is not the compiler's fault. The crafty source code uses I64 as the 64-bit int format when the NT_i386 macro is defined, otherwise, it uses LL. In the case of DigitalMars C/C++, we have to define the NT_i386 macro, but it uses LL as the 64-bit int format.
This is an easy sorce code fix. Just replace:
#if defined(NT_i386)
# define BMF "%I64u"
# define BMF6 "%6I64u"
# define BMF10 "%10I64u"
#else
# define BMF "%llu"
# define BMF6 "%6llu"
# define BMF10 "%10llu"
#endif
with:
#if defined(NT_i386)&&!defined(__DMC__)
# define BMF "%I64u"
# define BMF6 "%6I64u"
# define BMF10 "%10I64u"
#else
# define BMF "%llu"
# define BMF6 "%6llu"
# define BMF10 "%10llu"
#endif
I'm updating my page now with this information.

[Paul Hunter]

Geschrieben von:/Posted by: Paul Hunter at 15 April 2004 02:56:52:
Als Antwort auf:/In reply to: How about LCC geschrieben von:/posted by: Dann Corbit at 15 April 2004 02:45:15:

http://www.cs.virginia.edu/~lcc-win32/

I have tried LCC. But the resulting binary just crashes. I've had this kind of issue with LCC before. I don't think it generates correct code.

[Paul Hunter]

Geschrieben von:/Posted by: Paul Hunter at 15 April 2004 03:40:34:
Als Antwort auf:/In reply to: And one way (with DigitalMars C/C++) geschrieben von:/posted by: Paul Hunter at 15 April 2004 02:27:58:

Now we're serious. Two lines of code change, and inline-assembly builds. We're now close to the MS-VC teritory!!! Again, for free.
Total nodes: 94189491
Raw nodes per second: 1012790
Total elapsed time: 93
SMP time-to-ply measurement: 6.881720
I'm updating my page to have this new instructions:
Edit the file boolean.c.
Replaced "all" the lines:
# if !defined(INLINE_ASM)
with:
# if !defined(INLINE_ASM)&&!defined(VC_INLINE_ASM)
Compile with:
dmc -o -w -DVC_INLINE_ASM -DNT_i386 -DNOEGTB crafty.c

[Dann Corbit]

Geschrieben von:/Posted by: Dann Corbit at 15 April 2004 19:41:03:
Als Antwort auf:/In reply to: With inline-assembly geschrieben von:/posted by: Paul Hunter at 15 April 2004 03:40:34:

Now we're serious. Two lines of code change, and inline-assembly builds. We're now close to the MS-VC teritory!!! Again, for free.
Total nodes: 94189491
Raw nodes per second: 1012790
Total elapsed time: 93
SMP time-to-ply measurement: 6.881720
I'm updating my page to have this new instructions:
Edit the file boolean.c.
Replaced "all" the lines:
# if !defined(INLINE_ASM)
with:
# if !defined(INLINE_ASM)&&!defined(VC_INLINE_ASM)
Compile with:
dmc -o -w -DVC_INLINE_ASM -DNT_i386 -DNOEGTB crafty.c

Why compile without EGTB support? Doesn't the compiler support templates?



my ftp site {remove http:// unless you like error messages}

[Paul Hunter]

Geschrieben von:/Posted by: Paul Hunter at 15 April 2004 21:09:09:
Als Antwort auf:/In reply to: Re: With inline-assembly geschrieben von:/posted by: Dann Corbit at 15 April 2004 19:41:03:

Now we're serious. Two lines of code change, and inline-assembly builds. We're now close to the MS-VC teritory!!! Again, for free.
Total nodes: 94189491
Raw nodes per second: 1012790
Total elapsed time: 93
SMP time-to-ply measurement: 6.881720
I'm updating my page to have this new instructions:
Edit the file boolean.c.
Replaced "all" the lines:
# if !defined(INLINE_ASM)
with:
# if !defined(INLINE_ASM)&&!defined(VC_INLINE_ASM)
Compile with:
dmc -o -w -DVC_INLINE_ASM -DNT_i386 -DNOEGTB crafty.c

Why compile without EGTB support? Doesn't the compiler support templates?

These compilers cannot handle the huge cpp file. Compiling egtb.cpp gives you:
"Fatal error: out of memory"
Even VC6 complains, and you need to use the /Zm option.