size of free source code chess programs

[Uri Blass]

I wonder if somebody cared to calculate the following numbers for free source code programs:

1)number of bytes in the source.
2)number of bytes in the source not including comments and unused functions or unused variables or debugging code(like assert commands)
3)number of bytes if you also replace the variable names to be as small as possible(because I do not like program to be considered as longer because of having longer names for variables).

4)number of lines in the code
5)number of lines in the code not including empty lines

6)number of files in the code

I think that knowing the information can help programmers to decide about the sources that they prefer to read.

Uri

[Roman Hartmann]

Hi Uri,
counting lines is tricky as some people (including me) prefer to have several statements on a line. At least as long as the code remains somehow readable.

Code: Select all

    if (p->board_piece[i]==1){p->board_adress[i]=j;p->pieces[j]=i;j++;continue;}

Code: Select all

if (p->board_piece[i]==1)
{
   p->board_adress[i]=j;
   p->pieces[j]=i;
   j++;
   continue;
}

maybe the sources should be formatted with indent before counting lines.

best regards
Roman

[Tord Romstad]

Hi Uri,
counting lines is tricky as some people (including me) prefer to have several statements on a line. At least as long as the code remains somehow readable.

Code: Select all

    if (p->board_piece[i]==1){p->board_adress[i]=j;p->pieces[j]=i;j++;continue;}

Code: Select all

if (p->board_piece[i]==1)
{
   p->board_adress[i]=j;
   p->pieces[j]=i;
   j++;
   continue;
}

maybe the sources should be formatted with indent before counting lines.

I think it would be even better to measure the size of the compressed source code, because this doesn't penalize newlines and long identifier names very much.

However, all simple ways of measuring code length are misleading, because it also depends on other aspects of your coding style. For instance, the source code of Glaurung 2 is much bigger than it could be, because I have to write an awful lot of ugly and verbose boilerplate code in order to force the C++ language (which I really, really hate) to behave a tiny bit more like I would expect from a decent modern programming language.

For instance, I prefer to use enums rather than plain ints for things like pieces, squares, files, ranks, and so on, because this helps me to detect a much bigger number of silly bugs at compile-time (it means that I can't assign a rank to a variable of type "Square", and that I can't pass a piece as an argument to a function which expects a color as input). When I do this, C++ doesn't allow me to use basic arithmetic operators on the different types, and I have to manually overload +, -, ++, --, * and so on for every single type where I want to use these operators. This greatly inflates my source code.

As another example, I don't like to access constant and pseudo-constant arrays (by "pseudo-constant" I mean that the array is never written to after the program has finished initializing) directly in the high-level parts of my program. I write small inline functions to access them instead, like this:

Code: Select all

int Foo[64];

inline int foo(Square s) {
  return Foo[s];
}


This style makes it easier to replace the array Foo with a simple computation without changing many different parts of the program, and also helps to ensure that I always send a square (and not a rank, a piece type, a value, a search depth, etc.) as input. It improves debuggability and flexibility, it costs nothing in terms of performance or readability, but it inflates the code size.

Glaurung 2 currently has 16888 lines of code, while Glaurung 1.2.1 has 7021 lines. I am quite sure Glaurung 2 is still a lot bigger if you look at characters, tokens, non-comment lines, compressed source code, or any other simple and precisely defined way of measuring code size. Nevertheless, on a conceptual level, I think Glaurung 2 is a simpler and more compact program.

Tord

[Tord Romstad]

As another example, Glaurung 1 and Glaurung 2 both use a bitbase for the endgame KP vs K. In Glaurung 1, this bitbase is read from binary file on disk. In Glaurung 2, the bitbase is computed from scratch during program initialization (in a very inefficient and stupid way). This tiny difference alone adds more than 300 lines of code to Glaurung 2 compared to Glaurung 1, but I don't think it makes Glaurung 2 "bigger" in any meaningful sense of the word.

Tord

[Zach Wegner]

Glaurung 2 currently has 16888 lines of code, while Glaurung 1.2.1 has 7021 lines. I am quite sure Glaurung 2 is still a lot bigger if you look at characters, tokens, non-comment lines, compressed source code, or any other simple and precisely defined way of measuring code size. Nevertheless, on a conceptual level, I think Glaurung 2 is a simpler and more compact program.

Interesting. You seem to write code at a much faster pace than I. I remember that we both started our new engines (Glaurung 1 in your case) around the same time a couple of years ago. Right now I have 10,177 lines of code, and I think that is rather big. I have at least 5 lines of comments before any function. I have opening curly braces on their own lines. These I do for readability. I think my search() function is too big, almost 600 lines. But it all needs to be in one function. I'd say my code is rather complete in terms of features.

What I'm getting at is that I'm surprised you have so many lines. If hadn't ever seen your coding style, I would think you would have a very small program. But somehow you have managed in the same time frame to write two very strong engines, far above my level. Maybe I just wasted too much time on move generation and DTS search?

Zach

P.S. How big was Gothmog?

[Uri Blass]

I can say that movei is bigger (did not count the number of lines but I am sure about it ) but there are many unused functions in the code
and I think to rewrite it in the future.

I guess that I have more than 20,000 lines in the code of movei.
I also learned from fruit and increased the number of files relative to the number of files that I had in the first versions but I think that it was a bad thing to learn from fruit and strelka has only 11 c or h files.

Uri

[Tord Romstad]

What I'm getting at is that I'm surprised you have so many lines.

I'm quite surprised myself every time I check the number of lines. It doesn't feel like I have typed all that much. But of course, a large percentage of the source code in Glaurung 2 is just cut and pasted from elsewhere in the program with a few tiny changes. There are also a million little single-line inline functions which require zero intellectual effort to write. The program would be a lot shorter if I removed these functions and inlined them by hand at all relevant places in the code instead.

If hadn't ever seen your coding style, I would think you would have a very small program.

Why? If you hadn't ever seen my coding style, I don't see how you could have a well-informed guess about the size of my program.

But somehow you have managed in the same time frame to write two very strong engines, far above my level. Maybe I just wasted too much time on move generation and DTS search?

It's never a waste of time. We are both amateurs and do this just for fun, and we should just enjoy what we are doing without worrying if other approaches could have led to faster progress.

P.S. How big was Gothmog?

About 12000 lines, IIRC (I don't have the code on this machine) -- but this number is somewhat misleading, because the program was written in a very compact style. I frequently used multiple statements on a single line, and I always used multiple closing braces on a single line, like this:

Code: Select all

void foo(void) {
  while(bar()) {
    if(baz()) {
      for(int i = 0; i < 10; i++) {
        gazonk(i); }}}}


Actually I still prefer this coding style, but I stopped using it because it seems to drive all serious C and C++ programmers mad.

Tord

[Zach Wegner]

Why? If you hadn't ever seen my coding style, I don't see how you could have a well-informed guess about the size of my program.

Who said it would be well informed? I just guessed that based on some of the things you have said. It seems easier to me to conceptualize small programs, and you have always been a proponent of clear, readable code. I suppose my view was also influenced by looking at Glaurung 1. The code you posted was more to my thinking.

It's never a waste of time. We are both amateurs and do this just for fun, and we should just enjoy what we are doing without worrying if other approaches could have led to faster progress.

Of course. I have had a lot of fun with the bitboard approaches. DTS, I don't know. However, I have always wanted a strong program, but for some reason it is hard for me.

I do hope that my code will be a great tool for others like Fruit and Glaurung have been, especially its parallel search. My code is the most readable I have seen (minus the search function), but then again I suppose everyone thinks that about their code. (BTW the code has been cleaned up and commented a lot recently)

[Uri Blass]

code of Strelka after some modifications to replace part of the array by functions include 7271 lines including comments.

Uri

[Roman Hartmann]

I just counted the lines (including the comments) and was a bit surprised. My latest version of Roce contains 18111 lines of code. The reason for this rather high number is mainly due the use of several move generators in the engine which are all rather longwinded. Furthermore I do have some console stuff and some testing stuff in there as well.

But anyway I'm in the process of rewriting Roce completely as I have currently a bad mix of global and local data which makes changing the data structure a nightmare. A rewrite seemed the better choice and actually chess programming is fun again

Roman

[Uri Blass]

It may be interesting to know also size in bytes

Strelka after some more small changes that do not change the output of the program is now
7268 lines that include 366989 bytes

More than half of these bytes are constants inside arrays or structs.

[bob]

As another example, Glaurung 1 and Glaurung 2 both use a bitbase for the endgame KP vs K. In Glaurung 1, this bitbase is read from binary file on disk. In Glaurung 2, the bitbase is computed from scratch during program initialization (in a very inefficient and stupid way). This tiny difference alone adds more than 300 lines of code to Glaurung 2 compared to Glaurung 1, but I don't think it makes Glaurung 2 "bigger" in any meaningful sense of the word.

Tord

Why a bitbase for KPK? The rules for that ending are trivial to implement as per Reuben Fine's book...

[Harald Johnsen]

Why a bitbase for KPK? The rules for that ending are trivial to implement as per Reuben Fine's book...

Really ? What are this rules anyway, how to do evaluate a position where the kings are not on the key squares ?
Anyway accessing a bitbase is 4 lines of code so it will allways be simpler than any coded rules.

HJ.

[YvesLejeail]

maybe simpler to code bitbase, but nevertheless possibly much slower due to memory access. Just a guess...
Yves

[Tord Romstad]

As another example, Glaurung 1 and Glaurung 2 both use a bitbase for the endgame KP vs K. In Glaurung 1, this bitbase is read from binary file on disk. In Glaurung 2, the bitbase is computed from scratch during program initialization (in a very inefficient and stupid way). This tiny difference alone adds more than 300 lines of code to Glaurung 2 compared to Glaurung 1, but I don't think it makes Glaurung 2 "bigger" in any meaningful sense of the word.

Tord

Why a bitbase for KPK? The rules for that ending are trivial to implement as per Reuben Fine's book...

Looking up the position in a small lookup table is far more trivial. But the most important reason for me was to learn. It is possible that I will want to add bitbases for more complex endgames later, and in order to do this, I obviously need to know how to generate them. Generating a KPK bitbase was a nice little exercise to learn the basics.

Tord

[Vladimir Medvedev]

Why not just count keywords + identifiers + operators + function calls instead of lines, characters, files etc.

[bob]

Why a bitbase for KPK? The rules for that ending are trivial to implement as per Reuben Fine's book...

Really ? What are this rules anyway, how to do evaluate a position where the kings are not on the key squares ?
Anyway accessing a bitbase is 4 lines of code so it will allways be simpler than any coded rules.

HJ.

1. If the winning king is exactly one square in front of the passed pawn, and it has the opposition (in any form, direct opposition, distant opposition, etc) then it wins, else it is a draw.

2. if the winning king is two or more squares in front of the pawn, then it wins regardless.

The exceptions include rook pawns, and positions where the pawn is quickly lost...

Bitbases are certainly easier, and eliminating the special-case code for kpk is a plus as well. We are currently working on eliminating all the black/white code in crafty, and all that is left is the evaluation. We may well decide to use a kpk bitbase rather than have special case eveluation knowledge since this particular one is so small...

[Sven Schüle]

Hi Bob,

[diag]1k6/8/8/8/8/8/1P6/K7 w - - 0 1[/diag]
1k6/8/8/8/8/8/1P6/K7 w - - 0 1

would be a draw according to your rule. Is it?

[diag]1k6/8/8/8/8/8/1P6/K7 b - - 0 1[/diag]
1k6/8/8/8/8/8/1P6/K7 b - - 0 1

same position with black to move, draw in this case.

Your rule does not consider positions where the stronger king is not in front of his pawn, nor does it consider the side to move appropriately. Of course you find the correct result with a very shallow search (5 ply in this case), but a bitbase would require 0 ply here.

Just as a note.

Sven

[H.G.Muller]

Cases like
[diag]1k6/8/8/8/8/8/7P/K7 w - - 0 1[/diag]
1k6/8/8/8/8/8/7P/K7 w - - 0 1

or

[diag]8/8/8/8/8/k1K2P2/8/8 w - - 0 1[/diag]
8/8/8/8/8/k1K2P2/8/8 w - - 0 1

seem also not covered by the given rules.

[jdart]

It is not easy to do this programmatically (which is one reason I now use a KPK bitbase).

By the way, Arasan is about 40,000 lines of code (including headers + comments - and counting 6750 or so that is tablebase access code from Nalimov). It is one of the bigger programs out there. It has more features than many programs (tablebases, book, learning, UCI + Winboard) and also my programming style is maybe a bit wordy.