Author: Robert Hyatt
Date: 17:49:56 09/17/04
Go up one level in this thread
On September 17, 2004 at 17:40:51, Dann Corbit wrote: >On September 17, 2004 at 17:09:04, Robert Hyatt wrote: > >>On September 17, 2004 at 14:05:10, Dann Corbit wrote: >> >>>There is a memory leak somewhere (maybe in the tablebase code?) >>>After letting Crafty run all night analyzing WAC at 3 minutes per position with >>>494 megs ram allocated (14M tablebase, 384M hash, 96 pawn hash) Windows task >>>manager indicated a peak physical memory usage of 800MB and a virtual memory >>>size of 2,090,964K = 2GB. >>> >>>Crafty solved 299/300 on WAC, but some strange things surfaced. The one problem >>>not solved was NOT one of the few difficult ones like WAC.230, WAC.141 but was >>>instead WAC.274. Also, in the log file, we see a couple "captured a king" >>>messages. >> >>This indicates a serious problem. Often caused by bugs as I am testing, but for >>released versions, most commonly they are caused by compiler optimizer bugs >>instead. >> >>19.17 has been running and has played several hundred games, plus a lot of long >>testing on the 4-way opteron before AMD zapped it to use for another project. >>In looking at all the log files, I _never_ see that error message... >> >>I tried wac274 and get Rg2 from ply 2 on, with the score climbing each >>iteration. Something looks broken there... IE what compiler version, options, >>etc?? > >It's a beta compiler, so quite likely, that is where the problem is coming from. >Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40607.16 for 80x86 >Copyright (C) Microsoft Corporation. All rights reserved. > >These are the exact compiler flags: >/Ox /Og /Ob2 /Oi /Ot /Oy /GT /GL /I "c:\program files\Microsoft SDK\Include" /D >"NDEBUG" /D "WIN32" /D "_CONSOLE" /D "WINDOWS" /D "EGTB6" /D "NT_i386" /D "FAST" >/D "VC_INLINE_ASM" /D "DETECTDRAW" /D "EPD" /D "USE_ASSEMBLY" /D "_MBCS" /GF >/FD /MT /Zp16 /Gy /fp:fast /Fp"Release/crafty.pch" /Fo".\Release/" >/Fd".\Release/" /W4 /nologo /c /Gr > >In debug mode, the position solves correctly, so it may be related to a bad >optimization. > >The other positions all analyze fine (debug or release). With one going bad, I would not trust the executable in _any_ position. I've seen old gcc versions that Crafty broke horribly with the bitmap stuff. I've seen old gcc versions that appeared to work correctly except for one or two positions. But play games and "boom". That's part of software validation. :) One failure is enough to can the thing until it is fixed...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.