How much longer can 32 bit Chess Engines survive?

[Michael Sherwin]

64-bit doesn't have any advantage for mailbox engines over 32-bits. In fact, it can be slightly detrimental. Only bitboard engines profit from 64-bit architecture (and only when the board is not larger than 8x8). But that is of course because bitboard is horrendously slow on 32-bit, and then upgrades to medium slow on 64-bit...

Why do you say that bitboards are medium slow under 64-bit? I understood they were faster than anything else as they allow multiple pieces (of the same type) to be manipulated using very few machine language instructions?

Cheers,
Andy

In simple perft examples 64 bit bitboard is much slower than 32 bit mailbox. In real world programs with complex evaluators then I believe bitboard done correctly is faster. It is harder to do bitboard well! Most beginning bitboarders will mix 32 bit programming style in with the bitboards and the results can be very slow.

[Uri Blass]

64-bit doesn't have any advantage for mailbox engines over 32-bits. In fact, it can be slightly detrimental. Only bitboard engines profit from 64-bit architecture (and only when the board is not larger than 8x8). But that is of course because bitboard is horrendously slow on 32-bit, and then upgrades to medium slow on 64-bit...

Why do you say that bitboards are medium slow under 64-bit? I understood they were faster than anything else as they allow multiple pieces (of the same type) to be manipulated using very few machine language instructions?

Cheers,
Andy

In simple perft examples 64 bit bitboard is much slower than 32 bit mailbox. In real world programs with complex evaluators then I believe bitboard done correctly is faster. It is harder to do bitboard well! Most beginning bitboarders will mix 32 bit programming style in with the bitboards and the results can be very slow.

I wonder if there are good tasks that are related to chess when bitboard are proved to be faster.

playing chess is a bad task to test speed because different programs generate different output.

calculating perft from fen is one example of a good task that is related to chess when bitboard are slower.

It is a good task because all programs with no bugs generate the same output.

calculating perft is only one example and there may be tasks when bitboard are faster.

It will be good if supporters of bitboards show that bitboards is better in other tasks by writing some programs that print specific output when H.G.Muller who claims that bitboard have no advantage fails to do the same task faster without bitboards.

Uri

[glorfindel]

Sure they can survive.
If I look at current market trends, at least where I live, I think 32-bit hardware may be selling better that 64-bit hardware nowadays. Just look at all those netbooks, how cheap they are and how many people are buying them. This time, we might be moving in the direction of slower, rather than faster hardware, because slower is more economical and because most people don't need very fast hardware.
So 32-bit engines still have a role to play, and perhaps even arm engines as well, as the arm-based laptops come in next year.

[bob]

Good Morning,

I was looking at the CCRL rating list today when this question came to my mind. How much longer can 32 bit Chess Engines survive in a fastly growing 64 bit world? I only see three 32 bit engines in the top ten. They were:

Rybka 3
Deep Fritz 11
Hiarcs 12

I also might add that Deep Fritz and Hiarcs are doing very well for 32 bit engines. Is there no limit as to how high a rating a 32 bit engine can score? 64 bit computer systems seem to finally be pushing there way into more and more consumer homes, and giving these engines more horse power every day.

This question has a two-part answer:

(1) non-bitboard programs won't get much help from the 64 bit processors in the context of doing 64 bit math. No normal values get that large, and doing 32 bit math on a 64 bit processor gains nothing over using a 32 bit processor.

(2) in the 64 bit world, however, we have an extra 8 registers to use. And a 32 bit engine, when compiled with a 64 bit compiler for a 64 bit operating system will get to use those extra 8 registers, and that offers a significant performance increase over the normal X86 architecture registers.

(2) represents a significant gain for everybody. (1) only affects bitboard programs. But (2) is very significant by itself...

[sje]

Most, if not all handheld machines have 32 bit processors. Some have only 24 bit address spaces. All other things being equal, a 32 bit chip will use less power than a 64 bit chip and that's an important consideration for units with milliamp current draw limits.

[Dirt]

(1) non-bitboard programs won't get much help from the 64 bit processors in the context of doing 64 bit math. No normal values get that large, and doing 32 bit math on a 64 bit processor gains nothing over using a 32 bit processor.

(2) in the 64 bit world, however, we have an extra 8 registers to use. And a 32 bit engine, when compiled with a 64 bit compiler for a 64 bit operating system will get to use those extra 8 registers, and that offers a significant performance increase over the normal X86 architecture registers.

(2) represents a significant gain for everybody. (1) only affects bitboard programs. But (2) is very significant by itself...

However, there is also:

(3) The code size grows in 64 bit mode, due to larger pointers and perhaps other reasons, which slows down the engine. Something causes Toga to be slower when compiled to run in 64-bit mode, if this isn't the reason there must be another.

[bob]

(1) non-bitboard programs won't get much help from the 64 bit processors in the context of doing 64 bit math. No normal values get that large, and doing 32 bit math on a 64 bit processor gains nothing over using a 32 bit processor.

(2) in the 64 bit world, however, we have an extra 8 registers to use. And a 32 bit engine, when compiled with a 64 bit compiler for a 64 bit operating system will get to use those extra 8 registers, and that offers a significant performance increase over the normal X86 architecture registers.

(2) represents a significant gain for everybody. (1) only affects bitboard programs. But (2) is very significant by itself...

However, there is also:

(3) The code size grows in 64 bit mode, due to larger pointers and perhaps other reasons, which slows down the engine. Something causes Toga to be slower when compiled to run in 64-bit mode, if this isn't the reason there must be another.

I'm not sure why it would slow anything down. Things may get bigger with regards to pointers, but it ought to run faster because of the extra registers. Are you running a _real_ 64 bit compiler on top of a _real_ 64 bit operating system, so that you can use the extra 8 registers, etc???

[Dirt]

However, there is also:

(3) The code size grows in 64 bit mode, due to larger pointers and perhaps other reasons, which slows down the engine. Something causes Toga to be slower when compiled to run in 64-bit mode, if this isn't the reason there must be another.

I'm not sure why it would slow anything down. Things may get bigger with regards to pointers, but it ought to run faster because of the extra registers. Are you running a _real_ 64 bit compiler on top of a _real_ 64 bit operating system, so that you can use the extra 8 registers, etc???

I'm just repeating what Bryan Hoffman said in posts on this forum. At times he wouldn't provide a 64-bit compile because they tested slower. Other times, because of continued demand, he produced them even though they were slightly slower.

I can see at least a couple of reasons why larger code would slow a program; there is effectively less cache and more memory bandwidth is required. Why the slowdown would be more than the speedup from more registers, I don't know. Maybe compilers have improved enough since then that this is no longer true, but I haven't seen that reported.

[bob]

However, there is also:

(3) The code size grows in 64 bit mode, due to larger pointers and perhaps other reasons, which slows down the engine. Something causes Toga to be slower when compiled to run in 64-bit mode, if this isn't the reason there must be another.

I'm not sure why it would slow anything down. Things may get bigger with regards to pointers, but it ought to run faster because of the extra registers. Are you running a _real_ 64 bit compiler on top of a _real_ 64 bit operating system, so that you can use the extra 8 registers, etc???

I'm just repeating what Bryan Hoffman said in posts on this forum. At times he wouldn't provide a 64-bit compile because they tested slower. Other times, because of continued demand, he produced them even though they were slightly slower.

I can see at least a couple of reasons why larger code would slow a program; there is effectively less cache and more memory bandwidth is required. Why the slowdown would be more than the speedup from more registers, I don't know. Maybe compilers have improved enough since then that this is no longer true, but I haven't seen that reported.

There are two kinds of 64 bit compiles. A true 64 bit compile requires a true 64 bit O/S, because without that the extra registers can't be used. A compile that uses just the traditional registers, but in 64 bit word size will only see registers like rax, rbx, ..., rxd, but not the new r8, r9, ..., r15 registers. If the executables don't require a 64 bit operating system, they are not using the new registers, just the old registers in 64 bit size.

[Dirt]

However, there is also:

(3) The code size grows in 64 bit mode, due to larger pointers and perhaps other reasons, which slows down the engine. Something causes Toga to be slower when compiled to run in 64-bit mode, if this isn't the reason there must be another.

I'm not sure why it would slow anything down. Things may get bigger with regards to pointers, but it ought to run faster because of the extra registers. Are you running a _real_ 64 bit compiler on top of a _real_ 64 bit operating system, so that you can use the extra 8 registers, etc???

I'm just repeating what Bryan Hoffman said in posts on this forum. At times he wouldn't provide a 64-bit compile because they tested slower. Other times, because of continued demand, he produced them even though they were slightly slower.

I can see at least a couple of reasons why larger code would slow a program; there is effectively less cache and more memory bandwidth is required. Why the slowdown would be more than the speedup from more registers, I don't know. Maybe compilers have improved enough since then that this is no longer true, but I haven't seen that reported.

There are two kinds of 64 bit compiles. A true 64 bit compile requires a true 64 bit O/S, because without that the extra registers can't be used. A compile that uses just the traditional registers, but in 64 bit word size will only see registers like rax, rbx, ..., rxd, but not the new r8, r9, ..., r15 registers. If the executables don't require a 64 bit operating system, they are not using the new registers, just the old registers in 64 bit size.

I've never heard of a 64-bit compile for Windows that doesn't require a 64-bit OS. Personally, I'm quite sure Bryan's compiles used the extra registers, but that's just my impression of all the long lost posts made here at that time.

Similar posts at the Winboard form are still there. In 2007,

I don't have a 64-bit version of windows xp (copy on the way!) with which to run the necessary testing/profiling required.

The expert in compiling 64-bit Crafty compiles (and other 64-bit engines) is Bryan Hoffman. Maybe you could pm/email him or perhaps he'll read this thread and offer some tips.

If Toga wasn't using the extra registers, I doubt Bryan's Crafty builds were either - and they were the best available at the time.