Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Design choices in Crafty

Author: Gerd Isenberg

Date: 13:25:20 06/25/04

Go up one level in this thread


On June 25, 2004 at 15:18:53, Russell Reagan wrote:

>On June 25, 2004 at 15:03:21, Gerd Isenberg wrote:
>
>>http://chessprogramming.org/cccsearch/ccc.php?art_id=357556
>>http://chessprogramming.org/cccsearch/ccc.php?art_id=357568
>>
>>So it really seems negligible for "huge" search functions.
>>
>>Maybe my "bad" expirience has other sources by sideeffect or whatever.
>>But nowadays i often use [ply-1] or [ply-2] and more a lot and prefere external
>>arrays of nodes. One may simply use threadsafe preallocated external stacks too,
>>eg. as member of a search thread object.
>>
>>Gerd
>
>Does Eugene mean that the entire program should not put more than 4K on the
>stack at any time, or a single function should not put more than 4K on the
>stack?

One single function that "allocates" stack space by saving stackpointer to
basepointer and decrementing rsp. Stack grows still from top to bottom, such
push and call (post)decrement rsp, while pop and ret pre increment it. Plus the
actual pushed parameters and return address. One process has 1MByte by default
from the win64 os.

As Eugene mentioned the call stackcheck overhead is negligible and it may even
pay off in total due to less pressure on TLB ressources and physical memory
ressources.

>For example, if function a() puts 3K on the stack, and function b() puts
>3K on the stack. If a() calls b(), that is 6K on the stack. Should that be
>avoided (if possible)?

A routine with less or equal 4K hits guard page in worst case, causing an
interrupt and forcing some actions to map virtual to physical addresses and to
introduce a new guard page.

Greater than 4K may skip that guard page which may at least waste some cycles if
not worse. Therefore the call stackcheck.

Gerd




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.