I'm not very happy with the do {} while() statement in C

[Ras]

The "Pascal way" is to use boolean variables.

Yeah, that's one of the many broken aspects in Pascal, these cluttering helper flags.

[lucasart]

In other words if one is good at what they do stick to it. And if one is not good at it then modify one's approach to get better.

What I'm saying is that there are no rules when it comes to programming. There are only guidelines for beginners.

Every time you do something that violates the "guidelines for beginners" (such as using goto, or global variables, etc.), just think of it as tradeoff. What is the harm ? What is the benefit ? Is it worth it ? And think of it only in the specific context of the piece of code in front of you, not in general (ie. dogmatic) terms.

[sedicla]

C++ vs. C; OOP vs. Procedural; Global vs. Local. These are different and unrelated things.

You can use C and write OOP. You can use C++ and use Procedural. You can use lots of globals or none, in C or C++.

Whatever you do, never be religious about it. Writing code that has 0 global variable for the sake of it is plain stupidity. Same as writing code without break, continue, goto, only 1 return per function, etc. Dogmatic rules are stupid.

Of course you need global variables. I don't know any engine that has zero global. At the very least you need things like the Hash Table to be global.

Just think of it this way: does this variable really need to be a global ? Imagine if it wasn't: how much would it complicate the code, carrying it through function parameters all over the place ? Of course using "struct" (or "class" which is exactly the same modulo C++ syntactic sugar) reduces the mess of adding function parameters, by structuring them into single arguments.

But, generally, good code is good code. Doesn't matter if it's C or C++ (or Python or Go or D or whatever you like). Doesn't matter if it's OOP or Procedural. You can write clean and well organized code in plain old C. For example: https://github.com/lucasart/demolito. You can also write incredibly bad code in C++, and there's no lack of that around. But that's not C++'s fault...

+1.

I like the saying that code should be correct, clear, and fast. In that order. I started my engine with that in mind, but backwards
But at each release, I always try to re-engineer some parts. I like the code more afterwards.

[mcostalba]

In other words if one is good at what they do stick to it. And if one is not good at it then modify one's approach to get better.

In other word use your brain. Usually it is better than the handbook.

If, given 2 pieces of code you are able to tell which is the best one, then this is already a good achievement.

If, given your code, you are able to rewrite it and make it better then this is an even better achievement.

If, after, you rewrite it, you feel satisfied and you want to rewrite it even one more time, well, in that case you don't need handbooks

[Rebel]

I don't mean to be a pain but to me it sounds like you are describing the C++ way. I know that C++ objects can be simulated in C using structures and being strict in using function calls accordingly. But then I might as well use C++. In my way of thinking C++ using objects is superior for a team project so team members do not trample all over another team members variable names and function names. For a single person working on a one file source C++ methodology does not seem (as) beneficial. I can write 32 bit assembler with the best of em. However, the nuances of 64 bit assembly is giving me a hard time or I'd be writing this primarily in assembler. My goal is writing code that is as fast as it can be. I have sort of a reputation for that or at least I did when RomiChess first came out and also my perft examples I wrote. My perft example in 32 bit assembler runs at 65 million nodes per second using a single thread on my 3.4GHz i7. Not bragging, just saying I like to stick with my programming style. And learning a new paradigm at my age is not easy. What you are suggesting that I should do by passing a pointer around I understand would not make a very noticeable difference in speed but learning a whole new paradigm at my age would certainly slow my progress. I thank you for the philosophical discussion and anything more that you would like to add. I wonder what others might think about what you are suggesting.

Bob?

I am not Bob but what I did in the past (32 bit of course) is to write stuff in C then look at the ASM code the compiler generated and then manually optimize it. Perhaps it makes sense for 64 bit as well.

[Michael Sherwin]

I don't mean to be a pain but to me it sounds like you are describing the C++ way. I know that C++ objects can be simulated in C using structures and being strict in using function calls accordingly. But then I might as well use C++. In my way of thinking C++ using objects is superior for a team project so team members do not trample all over another team members variable names and function names. For a single person working on a one file source C++ methodology does not seem (as) beneficial. I can write 32 bit assembler with the best of em. However, the nuances of 64 bit assembly is giving me a hard time or I'd be writing this primarily in assembler. My goal is writing code that is as fast as it can be. I have sort of a reputation for that or at least I did when RomiChess first came out and also my perft examples I wrote. My perft example in 32 bit assembler runs at 65 million nodes per second using a single thread on my 3.4GHz i7. Not bragging, just saying I like to stick with my programming style. And learning a new paradigm at my age is not easy. What you are suggesting that I should do by passing a pointer around I understand would not make a very noticeable difference in speed but learning a whole new paradigm at my age would certainly slow my progress. I thank you for the philosophical discussion and anything more that you would like to add. I wonder what others might think about what you are suggesting.

Bob?

I am not Bob but what I did in the past (32 bit of course) is to write stuff in C then look at the ASM code the compiler generated and then manually optimize it. Perhaps it makes sense for 64 bit as well.

Ah, very logical Not Bob! Thanks!

[Michael Sherwin]

In other words if one is good at what they do stick to it. And if one is not good at it then modify one's approach to get better.

In other word use your brain. Usually it is better than the handbook.

If, given 2 pieces of code you are able to tell which is the best one, then this is already a good achievement.

If, given your code, you are able to rewrite it and make it better then this is an even better achievement.

If, after, you rewrite it, you feel satisfied and you want to rewrite it even one more time, well, in that case you don't need handbooks

Hi Marco, Unfortunately I was born with a memory disability for certain types of things. I always have to use a handbook. I wrote RomiChess with a C primer in one hand and a very basic book on computer chess programming in the other. If I do not use a specific feature in C, for example, for a period of time I forget it ever existed. So I am always searching the handbook for what I want to do.

[Ras]

what I did in the past (32 bit of course) is to write stuff in C then look at the ASM code the compiler generated and then manually optimize it. Perhaps it makes sense for 64 bit as well.

I wouldn't go for that. Several reasons:

1) the deep instruction pipelines of modern processors are difficult to deal with.
2) every processor, even compatible ones, has different pipelines. What's good today may be bad tomorrow.
3) out of order execution may easily mess up seemingly fine code.
4) it's not portable e.g. between x86 PCs and ARM smartphones.
5) the development time explodes, using up time that would yield more ELO when invested in the algorithms.

Stockfish has much less assembly (and half of it is even wrong, IMO) than Crafty and still plays stronger.

I'm using assembly only when I need more direct hardware access than C can provide.

[abulmo2]

Stockfish has much less assembly (and half of it is even wrong, IMO) than Crafty and still plays stronger.

What about asmfish ?
Doesn't it prove that assembly can provide faster engine than C++ ?

[Michael Sherwin]

Stockfish has much less assembly (and half of it is even wrong, IMO) than Crafty and still plays stronger.

What about asmfish ?
Doesn't it prove that assembly can provide faster engine than C++ ?

Speed was not Ras's mian focus. His focus was that assembly is not needed to create a really strong engine. The main reason that I would use 64 bit assembler over C right now is because my jump table style of chess programming lends itself to using a small subset of the assembly instructions. And that allows me to work faster due to my memory limitations.

Code: Select all

iptmf    dd          0
            dd          wpm,wpm,wpm,wpm,wpm,wpm,wpm,wpm
            dd          wnm,wnm,wbm,wbm,wrm,wrm,wqm,wkm
            dd          wck,wcq,wmter
            dd          cbcam
            dd          0
            dd          bpm,bpm,bpm,bpm,bpm,bpm,bpm,bpm
            dd          bnm,bnm,bbm,bbm,brm,brm,bqm,bkm
            dd          bck,bcq,bmter
            dd          cwcam

iptcf      dd          0
            dd          wpc,wpc,wpc,wpc,wpc,wpc,wpc,wpc
            dd          wnc,wnc,wbc,wbc,wrc,wrc,wqc,wkc
            dd          wcter,wcter,wcter
            dd          cbcac
            dd          0
            dd          bpc,bpc,bpc,bpc,bpc,bpc,bpc,bpc
            dd          bnc,bnc,bbc,bbc,brc,brc,bqc,bkc
            dd          bcter,bcter,bcter
            dd          cwcac            

wqmf    dd          0
            dd          wqmnd,wqmnd,wqmnd,wqmnd,wqmnd,wqmnd,wqmnd,wqmnd
            dd          wqmnd,wqmnd,wqmnd,wqmnd,wqmnd,wqmnd,wqmnd,wqmnd
            dd          0,0,0
            dd          wqmrm
            dd          0
            dd          wqmrc,wqmrc,wqmrc,wqmrc,wqmrc,wqmrc,wqmrc,wqmrc
            dd          wqmrc,wqmrc,wqmrc,wqmrc,wqmrc,wqmrc,wqmrc,wmcbki
            dd          wnxtm
            
wqcf        dd          0
            dd          wqcnd,wqcnd,wqcnd,wqcnd,wqcnd,wqcnd,wqcnd,wqcnd
            dd          wqcnd,wqcnd,wqcnd,wqcnd,wqcnd,wqcnd,wqcnd,wqcnd
            dd          0,0,0
            dd          wqcns
            dd          0
            dd          wqcrc,wqcrc,wqcrc,wqcrc,wqcrc,wqcrc,wqcrc,wqcrc
            dd          wqcrc,wqcrc,wqcrc,wqcrc,wqcrc,wqcrc,wqcrc,wccbki
            dd          wnxtc

wmg:    push        ebp
            push        edi
            push        esi
            mov         ebp,[ply]
            mov         eax,[first+ebp*4]
            mov         [lis+ebp*4],eax
            mov         edi,[nxt]
            jmp         [ptmf+edi*4]

wnxtm: mov         edi,[nxt+edi*4]
            jmp         [ptmf+edi*4]
        
wqm:    mov         ecx,[ps+edi*4]
            mov         esi,[qol+ecx*4]
            movsx       ebx,[qns+esi+ecx]
            mov         edx,[brd+ebx*4]
            jmp         [wqmf+edx*4]
        
wqmrm: mov         [tree.fsq+eax*8],cl
            mov         [tree.tsq+eax*8],bl
            mov         [tree.typ+eax*8],QMOV
            inc         eax
            movsx       ebx,[qns+esi+ebx]
            mov         edx,[brd+ebx*4]
            jmp         [wqmf+edx*4]

wqmrc: mov         [tree.fsq+eax*8],cl
            mov         [tree.tsq+eax*8],dl
            mov         [tree.typ+eax*8],QCAP
            inc         eax
wqmnd: movsx       ebx,[qnd+esi+ebx]
            mov         edx,[brd+ebx*4]
            jmp         [wqmf+edx*4]

And it is incredibly fast!