kranium wrote:i see, i assumed he was using Intel, considering the request for SSE...
although it is my understanding that most (or many) AMD processors support the SSE instruction sets.
for a custom compile, maybe Denis M., or another specialist is a better choice...
Norm
The AMD Opteron does indeed support SSE2. But if these builds are built using Profile Guided Optimisatation on an Intel, then presumably the result could be unpredictable on an AMD? I'm not an expert in this area. Maybe what he needs is some sort of slightly slower generic compile with wide compatibility ? For example, when Denis M did some Micromax compiles, the fastest one both on my Opteron and Intel boxes was in fact the PII compile. H.G. found the same as well
you said it right Ray.This is an issue of user preference, performance and/or compatibilities. New compilers nowadays increase their standards over time, just the same as hardware. That is why we released all-purpose compiles fit for a vast majority of users. It has some advantages and disadvantages, just the same with customized builds. The question is, "What standard compile does most users want?".
I'll try a generic all-purpose Cyclone build (still w/ pgo) and see how it performs on either AMD or Intel. the all-purpose builds were set to be compatible from Intel and non-Intel hardware.
Denis
Hi Dennis,
Stockfish 1.2 and Glaurung 2.2 also have these problems on this particular machine.
Pls. check which ones fit your hardware. I'll try Stockfish later.
Though my Athlon64 with XP x64 setup didn't have problems with Jim's builds, I'm interested to know the difference. Speed-wise, mine may be a bit slower. I hope this helps.
Pls. check which ones fit your hardware. I'll try Stockfish later.
Though my Athlon64 with XP x64 setup didn't have problems with Jim's builds, I'm interested to know the difference. Speed-wise, mine may be a bit slower. I hope this helps.
Thanks.
Denis
Thanks Dennis. I'll try it out soon. I hope your package might be of use to others also.
Denis P. Mendoza wrote:
Though my Athlon64 with XP x64 setup didn't have problems with Jim's builds, I'm interested to know the difference. Speed-wise, mine may be a bit slower. I hope this helps.
Thanks.
Denis
Thought I should mention that I'm using 32-bit engines, even though it's on an AMD64x2.
Graham, thanks for reminding. I did 2 sets as I don't know which 'integer' you are using. But with regards to Stockfish and Glaurung released versions by JA, there were always 3 builds accompanied for Win98 (all-purpose), 32-bit and 64-bit speed compiles (std). Have you tried the win98 versions (as they're the safest to use).
M. Constalba even gave tips to fix Stockfish' source during compiling:
4. Compiling it yourself
------------------------
On Unix-like systems, it should usually be possible to compile
Stockfish directly from the source code with the included Makefile.
The exception is computer with big-endian CPUs, like PowerPC
Macintoshes. Some of the bitboard routines in the current version of
Stockfish are endianness-sensitive, and won't work on a big-endian CPU.
Ensuring that the line with #define USE_32BIT_ATTACKS" near the top
of bitboard.h is commented out should solve this problem.
Commenting out the line with "#define USE_32BIT_ATTACKS" near the
There is also a problem with compiling Stockfish on certain 64-bit
systems, regardless of the endianness. If Stockfish segfaults
immediately after startup, try to comment out the line with
"#define USE_FOLDED_BITSCAN" near the beginning of bitboard.h and
recompile.
Finally, even if Stockfish does work without any changes on your
computer, it might be possible to improve the performance by changing
some of the #define directives in bitboard.h. The default settings
are optimized for 64-bit CPUs. On 32-bit CPUs, it is probably better
to switch on USE_32BIT_ATTACKS, and to use BITCOUNT_SWAR_32 instead of
BITCOUNT_SWAR_64. For computers with very little memory (like
handheld devices), it is possible to conserve memory by defining
USE_COMPACT_ROOK_ATTACKS.
I'm attaching your 32-bit Stockfish1.2 ( ap=all-purpose, def=default, opt=optimized):
Thanks again Dennis. I'll let the tourney run for a few days and let you know whether everything is going okay.
Cheers, Graham.
No joy. It's a Fritz 11 GUI problem on this particular computer.
As these engines run perfectly fine under ChessGUI, I will run the complete 11th Amateur series under this GUI.
Graham Banks wrote:
No joy. It's a Fritz 11 GUI problem on this particular computer.
As these engines run perfectly fine under ChessGUI, I will run the complete 11th Amateur series under this GUI.
Well, that is a good thing anyway. Running the Amateur series under a free GUI rather than a commercial one just seems to make sense And just think, you can run the winboard engines natively rather than through the wb2uci adaptor
Graham Banks wrote:
No joy. It's a Fritz 11 GUI problem on this particular computer.
As these engines run perfectly fine under ChessGUI, I will run the complete 11th Amateur series under this GUI.
Don't forget to run the tournament at bullet time control and using the test games feature of ChessGUI, no simulation.
100 games played
Level: Blitz 3 mins + 1 sec/move
Hardware: Intel(R) Pentium(R) M processor 2.00GHz with 1 016 MB Memory
Operating system: Microsoft Windows XP Professional Service Pack 3 (Build 2600)
8 of the above games are actually garbage for various reasons.
Here is bayeselo output on the 92 valid games:
you said it right Ray.This is an issue of user preference, performance and/or compatibilities. New compilers nowadays increase their standards over time, just the same as hardware. That is why we released all-purpose compiles fit for a vast majority of users. It has some advantages and disadvantages, just the same with customized builds. The question is, "What standard compile does most users want?".
And just think, you can run the winboard engines natively rather than through the wb2uci adaptor 