On 02/19/2011 09:56 PM, Steven wrote: Hi,
> Joost't wrote: > >> Yes, I posted about these stockfish anomalies before. >> And have some ideas in handling this; although I also hope that next sf >> releases will somehow start to behave... > Stockfish 191 was very bad. I just upgraded to 2.0.1 and it seems better > behaved. Hm, not just in all aspects. You read the release notes of 2.0.1? They do not bear confidence that this is indeed the case. > The way it loads up the CPU makes me wonder it's not hindering it's > opponents in some sly manner when playing computer tournaments > running on the one host. It is. Even the playchess client needed several updates to accommodate SF :-) >>> Do you know which is the bottleneck? >>> formatPV maybe? >> But: The fact that the receiving scid-end of the communication channel >> with the engine is implemented in tcl is certainly a big issue. > Yah... you're right. But moving all the pipe handling and input parsing from > tcl > to C > > is a big issue and not worth the effort imho considering the super-powered > nature of modern CPUs. I do not necessarily agree here, since (absolute) speed is not the issue. The faster the CPU, the faster tcl will run, true, but also the more garbage the engine will be able produce. It is the relative speed that matters. Moving the input handling into the C layer is not an issue at all. Just do so. It is the width of the interface to tcl (lots of observer functions needed) that discouraged me from already having done this. I need some additional thoughts on where to direct my axe and an appropriate API to manage the wounds it will cause :-) Cheers, Joost. > Steve > > > > > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users