Thread: A basic optimization request...

Originally Posted by brewbuck

Translation: write something unacceptable, then throw it all away and do it right. Might as well skip that pointless first step.

Absolutely not.
Again, it's the whole premature optimizing part.
Choose the right container and structure is obviously. Any good software will do that. But when it comes down to micro-optimizing, it's better to know where to apply them rather than applying them everywhere to save yourself headache and trouble.

If I'm not mistaken, new in C++ is quite different from one in C#. In C# it is the default way of creating objects, in C++ it is not.

(If you see a benchmark where Java or C# outperforms C++ greatly, often the reason may be that small-object allocation with new is a lot slower in C++.)

Like I said, write code first, optimize later.

One should also avoid premature pessimisation.

Originally Posted by Elysia

Absolutely not.
Again, it's the whole premature optimizing part.
Choose the right container and structure is obviously. Any good software will do that. But when it comes down to micro-optimizing, it's better to know where to apply them rather than applying them everywhere to save yourself headache and trouble.

We DO know where to apply them. People have known this stuff for decades. We don't have to feign ignorance of the issues.

Fine fine, whatever.

Write it in C xD

Elysia is right. Write first, optimize later. Debugging (and you will do that a lot) is much more important than speed. A program that crashes in 9 ms less time is not useful.

Just thinking that a routine will be called often is not a good solution. Use a profiler. You will be surprised at how much time passes in little functions you ignored.

That means, you can optimize on-the-fly. That would be f.i. choosing the right containers, pass by reference or pointer, inline small functions etc. which would not make it difficult to debug.

Also, in my experience, more than 50% of my code is thrown away immediately, so coding everything in assembly or complicated expressions is not the best solution. Maybe some people are not that wasteful, but in my case, hey, I'm not perfect.

Or you could fill your code with #ifdefs and use a threaded dispatch mechanism for all switch-case-labels for each architecture and compiler. That may be used in a final version, but debugging it will be a pain.

Anyway, the switch-case-thingies might as well go as this:

Code:

static const ptrdiff_t table[] = {&offsetof(BitBoard, WhitePawns), offsetof(...)};
if (Piecetype > 13)
    return NULL;
return *(unsigned long long *)((char *)Board + table[Piecetype]);

One comparison, two adds and two deferences. That should be fast enough. But, if you change something in BitBoard, aka make it a real class, you have to rewrite this routine.

And inline those functions. The getter/setter ones always.

Elysia is right. Write first, optimize later. Debugging (and you will do that a lot) is much more important than speed. A program that crashes in 9 ms less time is not useful.

Depends on the kind of things we are talking about. If, for some reason, you had to implement your own sorting function for large datasets, there's no point to start out writing a bubble-sort, even though it is simplest and easiest to debug.

I also don't think in chess there would be much reason to start out with a "simpler" data representation because the whole thing is all about the representation and algorithms on it. If you find out later that you need to change the representation, you are going to have to rewrite it all, so the easy debuggability gives no benefit.

These are not micro-optimizations.

Anyway, the switch-case-thingies might as well go as this:

And there you go suggesting a micro-optimization, that the compiler may already be performing for you, perhaps even better...

Originally Posted by Brafil

Write it in C xD

Elysia is right. Write first, optimize later. Debugging (and you will do that a lot) is much more important than speed. A program that crashes in 9 ms less time is not useful.

A chess program that loses is lame.

Given two chess players, which are identical in all respects except that one uses bit boards and one does not, the version using bit boards will win. Every time. Guaranteed. Calling bit boards a micro-optimization is like saying that having walls on your house is "convenient." Uh, no. You need walls. You need bit boards.

Just thinking that a routine will be called often is not a good solution. Use a profiler. You will be surprised at how much time passes in little functions you ignored.

The only point in profiling would be to verify that indeed, almost all of the time is spent in the heuristic evaluator. If it isn't, then your program clearly has a bug in it. So I suppose it could be a useful test in that respect.

The reason that it is not premature optimisation to start out with bit boards in this case is because it is a very common problem which has already been researched thoroughly, and it is well known ahead of time that this is necessary to have a decent chess engine.
It could be premature optimisation if you were amoung the first to write it and there was no pre-existing research about it. But in this case, not using bit-boards initially would simply be a failure to do prior research first.
I would not expend the significant effort required to code up a non-bit-board solution first for any other reason either.