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

Reply via email to