How to speed up my engine

[Henk]

I prefer hundred bugs extra in my code then having my code polluted with all kinds of annoying asserts and tests that hardly ever catch any errors.

[Wait a minute you are programming in C++ and not C#. Maybe in that case I would add asserts too for C++ code is unsafe]

[jdart]

Asserts help because they can catch something wrong before you crash .. sometimes you do something wrong (like execute an invalid move) and hundreds or thousands of machine instructions later, you crash.

But if you don't like asserts .. at least check out the new flags in GCC 5.0, for example -fsanitize=bounds.

--Jon

[Henk]

If one tries to add complete post conditions you really make it unnecessarily complex.

[bob]

If one tries to add complete post conditions you really make it unnecessarily complex.

Debugging is not easy nor fast. The more you get the compiler to help, the less you have to figure out mentally.

X-rays, CT scans and MRI's are extremely complex processes. Should we get rid of those and do it the direct way (exploratory surgery) instead?

[wgarvin]

Asserts are a way for programmers to check their assumptions at runtime.

If you thought the program would be in a certain state at that point and its not in that state, you want to find out about that sooner rather than later.

As John Carmack once wrote:

Most bugs are a result of the execution state not being exactly what you think it is.

Asserts are of course NOT for error handling. (Thats why you can disable them in a Release build for better performance: if the program is correct the asserts should never fire anyway).

[Edit: Figuring out exactly which asserts are worth putting in, is a bit of an art. At least with practice you get better at it.]

[lauriet]

If one tries to add complete post conditions you really make it unnecessarily complex.

Debugging is not easy nor fast. The more you get the compiler to help, the less you have to figure out mentally.

X-rays, CT scans and MRI's are extremely complex processes. Should we get rid of those and do it the direct way (exploratory surgery) instead?

"Bloody Hell...Damn Straight" Thats Australian for
"Gee Wiz, you sure are right"

Of all the programming I have done, debugging chess software is the hardest. Normally I can use the built in debugger and find the error pretty quickly. But with search the debugger seems to get confused with all the nested/recursive calls and never displays the variables properley. How do you find a bug that only shows up at node 10,265,356 ????

Laurie.

[sje]

But with search the debugger seems to get confused with all the nested/recursive calls and never displays the variables properley. How do you find a bug that only shows up at node 10,265,356 ????

Use a non-recursive, finite state machine search.

[Werner Taelemans]

How do you find a bug that only shows up at node 10,265,356 ????
Laurie.

Add a counter in your make_move(). Increment this counter each time you do a move (and don't decrement in unmake_move() )
When you find a bug, print this counter, and if it says 10,265,356, start logging from 10,265,000.
There's no need to log millions of nodes.

[Rebel]

Never used assert, neither a debugger, well maybe 1-2 times.

My philosophy was (still is) type small changes and test it immediately, if needed displaying the contents of variables with printf. Small steps, few bugs.

[Chessqueen]

Well if you take a look at uci.cpp you'll notice my abhorrent lack of UCI implementations. Aside from that, I am also searching for a new name for the engine because Ethereal is VERY bad for two reasons. 1) Because EtherealChess is already around, and 2) Ethereal makes people think of WireShark before it was WireShark.

I will release it as soon as I find a new name and figure out what I need to do to meet UCI standards. As of now, all my engine does is play 40/4 games with zero settings.

Also, excuse my lack of information here (self taught) what do you mean by " but it was not statically linked vs. libstdc++-6.dll at least."

A great name would be bootstrapChess ==> A bootstrap is the program that initializes the operating system (OS) during startup. The term bootstrap or bootstrapping originated in the early 1950s. It referred to a bootstrap load button that was used to initiate a hardwired bootstrap program, or smaller program that executed a larger program such as the OS.