Developments of the last two years

[Aaron Becker]

Not a wise decision!

Definitely not, but I hope it will at least be a fun one!

Welcome back Aaron!

Miguel
PS: Dr. Becker?

Thanks Miguel! I did manage to finish my PhD, so I suppose so. I'm glad to see how well Gaviota is doing.

[Don]

To be sure, if you take some existing work and then make improvements there is no harm in that whatsoever. That is how open source works at it's best.

The problem is that people start from these great programs and stake their claim on the source code, basically putting their own name on the program and claiming the program as their own without revealing the source code. That's wrong on many levels including legally and ethically.

OH, is very clear, all agree,
Original, much better, much better, are wonderful, but I am one of the outlaws cloners, still trying to finish my original.
If deep'm envious, I admit, I hope someday.

But Aaron Friend, you think that in two years can people outside all this tumultuous Inquisition, who has not lived this world of hatred (Fruit, Rybka, Ippolit, Houdini, critter, robodini, ect, ect)
They are PUBLIC DOMAIN engine, an engine that technically gives another hundred laps,
and legally decide to develop it.

Sure they find that the "old place" has the right to insult you, call plagiarism hexedit call, call you all, and without the right of reply.

Moreover in these two years, practically the "originals" are somewhat stagnant, I have not seen a single idea in any of the literature, only a transfer of ideas from one program to another.

Then welcome his return.

[michiguel]

[MODERATION]
A branch that did not belong here was removed.

Miguel

[velmarin]

[MODERATION]
A branch that did not belong here was removed.

Miguel

It ends with the judgment of the untouchable "Don Daley"

As always talking about illegalities and immoralities, fucking great.
The water and oil.

[michiguel]

[MODERATION]
A branch that did not belong here was removed.

Miguel

It ends with the judgment of the untouchable "Don Daley"

As always talking about illegalities and immoralities, f***ing great.
The water and oil.

I posted a general request about getting back on topic (this subforum has a shorter leash). You complained about others offending you. Then, I removed the whole branch. Now, you complained more with profanity. Please, STOP.

Miguel

[Rebel]

Then what's the problem?

I know this question is not for me to answer. But there exists a real problem. And the problem is, it turns out, a programmer with superior code at hand may still end up with a lower ELO engine, simply because his compiler is not the best one. And the best compiler is not free. For a free, open-source project, this becomes a problem, especially if one is unaware of it. There is a real risk to give up too early by mistake. In the meanwhile, someone else may win on the compiler strength. I hope people realize that Stockfish 2.2.2 used the new intrinsics. (Nothing wrong with that.)

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

[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.

[lucasart]

Then what's the problem?

I know this question is not for me to answer. But there exists a real problem. And the problem is, it turns out, a programmer with superior code at hand may still end up with a lower ELO engine, simply because his compiler is not the best one. And the best compiler is not free. For a free, open-source project, this becomes a problem, especially if one is unaware of it. There is a real risk to give up too early by mistake. In the meanwhile, someone else may win on the compiler strength. I hope people realize that Stockfish 2.2.2 used the new intrinsics. (Nothing wrong with that.)

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

I'm pretty sure that statement is wrong. Other than writing in assembly the usual lsb(), msb(), and popcnt(), anything else is either useless or counter-productive (not to mention the portability issues). In fact you should not write those in assembly, but use compiler intrinsics instead, to ensure plateform portability at least (compiler decides which asm instruction to use depending on the plateform).

Have you ever tried to beat the C compiler with your own hand-written assembly ? In the old days (80486 let's say) it was still possible. But nowadays, architectures have become so complicated, and compilers so powerful, that it's virtually impossible to beat the compiler on any significant portion of code. Even Linus Torvaldes said that. And you can be sure that he has tried

Perhaps you don't realize just how powerful modern compilers have become. The best way to improve the speed of your program is to rewrite your C code in a better way, so as to make it do less calculation in time critical path.

[Rebel]

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.

[ZirconiumX]

I'm pretty sure that statement is wrong. Other than writing in assembly the usual lsb(), msb(), and popcnt(), anything else is either useless or counter-productive (not to mention the portability issues). In fact you should not write those in assembly, but use compiler intrinsics instead, to ensure plateform portability at least (compiler decides which asm instruction to use depending on the plateform).

Have you ever tried to beat the C compiler with your own hand-written assembly ? In the old days (80486 let's say) it was still possible. But nowadays, architectures have become so complicated, and compilers so powerful, that it's virtually impossible to beat the compiler on any significant portion of code. Even Linus Torvaldes said that. And you can be sure that he has tried

Perhaps you don't realize just how powerful modern compilers have become. The best way to improve the speed of your program is to rewrite your C code in a better way, so as to make it do less calculation in time critical path.

Compilers are like a sharp knife. You can cut both a pineapple and a pizza with them. But if you make Hawaiian style pizza often, you'll learn that you use a cleaver to chop the pineapple, and the circular bladed gizmo to cut the pizza.

Compilers do not know about tricks like keeping bitboards in registers, using popcnt and lsb. A C compiler has to do almost everything. It has to compile and optimize both a Sieve of Erastothenes and your chess program as best as it can.

If someone made a compiler dedicated to chess that used tricks like that it'd produce one of the best compiles out there.

Matthew:out