Developments of the last two years

[hgm]

I once hand-optimized the assembly code generated by the compiler for my qperft program. I could eliminate about 40% of the instructions (redundant loads and stores due to poor register allocation), for a speedup of exactly 0%...

[tpetzke]

So called original authors often claim there is nothing but cloning, but that does not explain the progress technically. I suspect that most of them simply do not know what's going on.

That is just evolution. Take a strong program, create 100+ copies from it where you make some randoms changes in each, let the copies compete among themselves or against others to evaluate their fitness. Keep the original one in the pool (Elitism). If you find a new best use it as the base for creating new copies from it.

This will produce probably a stronger engine given enough time and people who participate but it's somehow not a creative process. However there is a huge investment of CPU time involved that a community of people dedicates to that evolution.

As an author of an original engine it is very hard to overcome that competitive advantage assuming you don't have a similar amount of resources and time at your disposal.

So at the top of the ratings lists the progress is more of an evolutionary type. That does not mean there is no creativity in chess programming. But even if you have a real cool idea in an original program chances are it will not push its fitness above the one of the advanced evolved clones at the top.

Thomas...

[Joost Buijs]

Using inline 64-bit ASM on the time critical parts should give a skilled ASM programmer a 20-25% speed-up.

Maybe you are talking about the past?
My experience is that the code-generators/optimizers of modern C/C++ compilers are so good that it is very difficult or even impossible to produce something faster with handwritten assembler.

1. My engine is in 32 bit ASM and I have a ported back to C version and it was a disappointing experience.

2. 64-bit gives 8 extra registers, you can do nice new tricks with that. One big saver would be to keep your bit-boards in registers instead of memory.

Alright, maybe 20-25% is a bit too optimistic.

In another thread I saw you are using the "Digital Mars" compiler.
I have no experience with this compiler but I can imagine that it produces (much) slower code as e.g. the Intel, Microsoft or the latest version of the GCC compiler.

A couple of years ago I wrote my whole evaluation function in 64 bit ASM and at best I could reach approximately the same performance as with the C++ version. I really tried very hard to get it better but it just didn't work.

[Don]

Using inline 64-bit ASM on the time critical parts should give a skilled ASM programmer a 20-25% speed-up.

Maybe you are talking about the past?
My experience is that the code-generators/optimizers of modern C/C++ compilers are so good that it is very difficult or even impossible to produce something faster with handwritten assembler.

You probably read that somewhere and are just repeating it as this is one of those often repeated myths that you can see all over the place on the web.

What is probably true is that most people cannot write better assembly than a good compiler. But someone with real skill who understand the issues and how modern CPU's work can write better code than a dumb program can.

[Joost Buijs]

Using inline 64-bit ASM on the time critical parts should give a skilled ASM programmer a 20-25% speed-up.

Maybe you are talking about the past?
My experience is that the code-generators/optimizers of modern C/C++ compilers are so good that it is very difficult or even impossible to produce something faster with handwritten assembler.

You probably read that somewhere and are just repeating it as this is one of those often repeated myths that you can see all over the place on the web.

What is probably true is that most people cannot write better assembly than a good compiler. But someone with real skill who understand the issues and how modern CPU's work can write better code than a dumb program can.

I did not read this anywhere, I actually tried it myself. I'm not a skilled assembler programmer, but I had my share of assembler programming in the past, that is probably more than you can say.

[lucasart]

Using inline 64-bit ASM on the time critical parts should give a skilled ASM programmer a 20-25% speed-up.

Maybe you are talking about the past?
My experience is that the code-generators/optimizers of modern C/C++ compilers are so good that it is very difficult or even impossible to produce something faster with handwritten assembler.

You probably read that somewhere and are just repeating it as this is one of those often repeated myths that you can see all over the place on the web.

What is probably true is that most people cannot write better assembly than a good compiler. But someone with real skill who understand the issues and how modern CPU's work can write better code than a dumb program can.

I did not read this anywhere, I actually tried it myself. I'm not a skilled assembler programmer, but I had my share of assembler programming in the past, that is probably more than you can say.

Same here. I have tried myself to write faster assembly code than C (compiled with GCC) and failed, even on very simple pieces.

OK, so you and I might not be super expert assembly programmers. But perhaps Don Daily will at least listen to Linus Torvaldes:

The same goes for the choice of a C compiler over hand-written assembly.
Nobody sane these days claims that handwritten assembly will outperform
a good compiler, especially if the code is allowed to use inline asms
for stuff that the compiler can't handle well natively.

Full discussion here:
http://yarchive.net/comp/microkernels.html

It's not a myth, it's a reality! Try it, and you will see for yourself.

[syzygy]

OK, so you and I might not be super expert assembly programmers. But perhaps Don Daily will at least listen to Linus Torvaldes:

The same goes for the choice of a C compiler over hand-written assembly.
Nobody sane these days claims that handwritten assembly will outperform
a good compiler, especially if the code is allowed to use inline asms
for stuff that the compiler can't handle well natively.

Full discussion here:
http://yarchive.net/comp/microkernels.html

It's not a myth, it's a reality! Try it, and you will see for yourself.

Let's add another Linus quote:

And if you never look at the produced assembler code, then you'll never have a fast system. Really. Compilers can do only so much. People who understand what the end result is makes for a difference.

On the same page Linus is arguing against the use of builtins and in favour of handcrafting your own (inline) assembly.

[velmarin]

Maybe in two years and have a Komodo MP,

I doubt it, but with the ability to "Don"

Do you guys think?

Well, teacher Lucas could help.

[Michel]

Maybe in two years and have a Komodo MP,

I doubt it, but with the ability to "Don"

Do you guys think?
Question
Well, teacher Lucas could help.
Twisted Evil

Could you please stop spouting this drivel.

[Rebel]

In another thread I saw you are using the "Digital Mars" compiler. I have no experience with this compiler but I can imagine that it produces (much) slower code as e.g. the Intel, Microsoft or the latest version of the GCC compiler.

I was curious how the MS compiler would perform and the 2010 edition was a disappointing experience, a speed loss (ASM->C) of 15% (IIRC). Besides, although the DigitalMars compiler is old and development has stopped its code speed-wise is on the same level as MSVC-2010.

A couple of years ago I wrote my whole evaluation function in 64 bit ASM and at best I could reach approximately the same performance as with the C++ version. I really tried very hard to get it better but it just didn't work.

I take your word for it. Just curious, did you apply the rules of "pairing" ?