0x88 engines

[MattieShoes]

I updated TO_BOARD128 and TO_BOARD64 macros, thanks

[hgm]

Attacktables are far too slow to do this.

This was why I was looking for a fast way to update them. and I think the linked lists could do it. I also plan to save time by only keeping the attacks on occupied squares. Furthermore, in QS, (where you are basically 90% of the time) the update is less expensive because you cannot block any slider moves. Just unblock them. And I only have to do the update due to the previous move when I decide I really need to search moves.

Wasting system time on a call to qsearch is silly if standpat would already fail high in qsearch. You can detect that faster of course.

Yes, this is futility pruning. But I am worried about the the other type of leaves, where eval fails low. Those nodes eat most of the time now, Make / UnMake and calling are totally negligible compared to to generating moves. It basically generates all non-captures just to conclude thatthere are no captures, in low-failing end leaves.

The only problem to solve is fast generation of checks in qsearch.
It is there where bitboards are not extremely slow. However there is fast manners to do this in regular datastructures, which gives a better high level overview anyway on the program.

Also a problem that bitboarders have is that they first generate the captures and THEN the checks.

This is bad for mate threat extensions (so you use them), as it'll return a cutoff for a capture already instead of detecting the mate. It's better to order the best move first, that's better for your search tree.

Vincent

[Aleks Peshkov]

I think that important problem of quiesearch is stand pat when your king is in check after capture sequence.

Crafty is blind to the problem, Glauring and Fruit's family do not. So both decisions are working.

[diep]

Attacktables are far too slow to do this.

This was why I was looking for a fast way to update them. and I think the linked lists could do it. I also plan to save time by only keeping the attacks on occupied squares. Furthermore, in QS, (where you are basically 90% of the time) the update is less expensive because you cannot block any slider moves. Just unblock them. And I only have to do the update due to the previous move when I decide I really need to search moves.

The principle of incremental attacktables i'm using is that they're a lot faster than non-incremental attacktables and i need them especially for evaluation.

Even faster than that is not using them of course as for search there is way faster alternatives that work at local level.

Important information would be knowing how many nps your new engine gets. Most likely it is still in the phase that any random change or concept of another engine will improve it.

The question is whether you are happy with that nps, or guess you can invent algorithms that make it that much more efficient than todays beancounters that you can beat them.

Wasn't that hardware chess program you had in a match box getting a million or 2 nps in the 80s (thereby faster than deep thought at the time which got 500k nps in hardware) or was that someone else?

How did you do qsearch in that tiny chesscomputer?

Wasting system time on a call to qsearch is silly if standpat would already fail high in qsearch. You can detect that faster of course.

Yes, this is futility pruning. But I am worried about the the other type of leaves, where eval fails low. Those nodes eat most of the time now, Make / UnMake and calling are totally negligible compared to to generating moves. It basically generates all non-captures just to conclude thatthere are no captures, in low-failing end leaves.

Note I wasn't only referring to futility pruning.

Maybe the solution in your case is to find a manner to fail high more than to fail low. There is 2 manners to fail high more.

I) that's change your code and hope you visit less innernodes in qsearch
II) measure statistics and conclude you have nothing to worry about
as your initial guess of 50% is far off.

Did you ever generate statistics how many nodes you fail high in qsearch and how many fail low and generate a movelist?

I am interested in some statistics with subclasses

a) number of cutnodes in qsearch
a1) standpat cutnode
a2) cutoff by means of making a move that 'wins'.
b) number of all nodes in qsearch
c) number of firstcalls to qsearch as a percentage to all nodes visited in
qsearch.

As i already print those for 10+ years of diep, i do know them for diep. I'm interested in your statistics.

Maybe that gives a minority of us some new insights.

Vincent

[bob]

I think that important problem of quiesearch is stand pat when your king is in check after capture sequence.

Crafty is blind to the problem, Glauring and Fruit's family do not. So both decisions are working.

I think that is irrelevant. Standing pat after a capture that is a check is an error. So is standing pat in _most_ positions. Crafty does do q-search checks, but it does not do escape-from-check for any moves except when it intentionally generates checking moves in the q-search.

Fruit certainly is not that good an example as there is nothing I have seen that suggests it is better than crafty in any regard today.

[Robert Pope]

How about board variable types? Right now I am using int board[192]. Is that fastest because it is the register size, or is it better to use char board[192] because it is more compact?

[Bill Rogers]

No disrespect intended but why has no one referred him to Bruce Moreland's page. Bruce has detailed instructions on 0x88 programming.
I think both Ferret and Girbel were both programmed in type of coding.
Bill

[Aleks Peshkov]

How about board variable types? Right now I am using int board[192]. Is that fastest because it is the register size, or is it better to use char board[192] because it is more compact?

Using int variables compiler generate shorter code, because it can combine calculation instruction with load from memory assembler instruction in one command.

Speed difference may be or may be not noticeable.

[Robert Pope]

No disrespect intended but why has no one referred him to Bruce Moreland's page. Bruce has detailed instructions on 0x88 programming.
I think both Ferret and Girbel were both programmed in type of coding.
Bill

I've seen Bruce's page. It gives a great intro, but there are tons of implementation details that make the difference between a 2M nps engine and a 100K nps engine, which is about where I am now.

[Bill Rogers]

Well Robert the gentlemen who are helping you are both full of expert information. I just did not know how far along you were in the developement of your program.
Bill