Hood wrote:
64 bitboard and more registers are logical reasons but it concerns x86 only.
No there is a distinction in what Ronald is saying that you seem to have missed
=> yes x86-64 is faster than x86 in general, and that is an *exception* (more registers)
=> the extensive use of bitboards makes chess programs faster on 64 bit regardless of the architecture. in my engine the difference is like day and night, 64 bit is almost twice faster, and it's normal given the amount of bitboard operations.
is that 64b architecture neccassary, what is an advantage? 32bit seems to be enough to host chess program. Programs are not so big to need 64b addrress space.
The reason might be Java which is memory consuming when garbage collector is sleeping but good written C program ....
Rgds Hood
You gotta realize chess really had little or nothing to do with the decision to up it to 64bit. Just like we have no choice about Windows 7- if we want the latest technology. Then Windows 8. Programmers saw the day was coming soon when everything newly built was going to be 64bit- they really had little or no choice if they wanted to keep up. I'm not saying they don't like 64bit better- just that when it was still in the "thinking" stages- chess was never given a thought.
gts
What are you talking about ? You speak in the name of programmers, but from what you say, it's obvious that you've never written a line of code in your life.
Yes, AMD developed the 64 bit architecture for general purpose computing not chess. But the fact that you're running a x86-64 archi does not mean that 32 bit registers or 32 bit operations, nor does it mean that 16 bit ones are not possible anymore.
But in chess, because there are 64 squares on the board, a lot of theory was developped to take advantage of 64 bit operations to do chess operations. And the most advanced stage of it is certainly magic bitboards. To give you an idea, in layman terms, it means that I can calculate all the squares attacked by a sliding piece without a single loop, and with only a couply of 64 bit operations (multiplication and bit shift) and a couple of pointer deferencing.
lucasart wrote:
Java is a very bad choice for programing
Nope.
Ralph Stoesser wrote:
Goodby Javasrcipt.
contradiction
Anyway, maybe GWT is good for web apps, and it is based on Java, although it is not Java. But using Java to develop applications running "natively" on a PC (that is to say in a Jav VM) is nonsense. Anyone in their sane mind would rule out Java from application developpement (I mean proper apps not web apps).
syzygy wrote:For non-bitboard engines, it seems likely that the 64-bit version will be faster than the 32-bit version only on x86, due to the increased number of registers.
Usually, but not always. Toga II always ran slightly faster if compiled for 32 bits.
lucasart wrote: in my engine the difference is like day and night, 64 bit is almost twice faster, and it's normal given the amount of bitboard operations.
However, it seems that today, for major programs (Houdini, Stockfish), when some effort is made for 32-bit efficiency, the speed advantage of 64-bit over 32-bit is only of the order of 30%
neelbasant wrote:putting data in 32-bit processing is slower than 64-bit processing.
Only if you really need to process 64-bit values such as bitboards. Many many applications do not need 64-bit values, and in general they won't run faster as a result of compiling as a 64-bit program. In general, they run slower because 64-bit instructions and pointer values take up more space and therefore consume more memory bandwidth and cache.
The exception is the x86-32/64 architecture. On this architecture, 64-bit programs generally are faster than the equivalent 32-bit programs. The reason is that the x86-64 architecture provides double the amount of cpu registers compared to the x86-32 architecture. This has basically nothing to do with the fact that it is a 64-bit architecture. What happened is that AMD (who designed the x86-64 instruction set which was later adopted by Intel) took the transition to 64-bit as an opportunity to improve on the 32-bit x86 architecture by extending the set of general purpose registers (plus some other improvements).
You can imagine it as .
You have 32 lane(bit) for transportation.\
& now you have 64 lane ( bit) for transportation.
Only helps where 32-bit values are not enough.
There ARE advantages to 64 bits beyond just 64 bits. For example, 8 additional general-purpose registers, something the x86 really needs. And this is a bit more than "doubling" given that we only have eax-edx in 32 bit mode, and get 8 more in 64 bits, so really tripling. And when you consider how eax/edx are used in multiply, the number of extra registers becomes even more significant. I have not seen many applications that run slower in 64 bit mode, not that they don't exist. But they are a small minority. Most run faster. And those that are left are mostly just more modest gains, or break-even. And some, notably bitboard chess engines, run significantly faster. Overall it is a significant gain no matter what the software...
geots wrote:
You gotta realize chess really had little or nothing to do with the decision to up it to 64bit. Just like we have no choice about Windows 7- if we want the latest technology. Then Windows 8. Programmers saw the day was coming soon when everything newly built was going to be 64bit- they really had little or no choice if they wanted to keep up. I'm not saying they don't like 64bit better- just that when it was still in the "thinking" stages- chess was never given a thought.
gts
It is not only about modern technology. There are a lot of 32bit OS on the market. It has to be consider by commercial programmers.
Not everyone is involved in technology race. Better is enemy of good.
Many people are keeping with 32b, why do we need 64 b for typing or surfing machine? The last Deep Fritz is 32b takes care about whole market as well Strielka.
Last example shows that 32 b can be very strong.
32 MP is wise solution.
neelbasant wrote:putting data in 32-bit processing is slower than 64-bit processing.
Only if you really need to process 64-bit values such as bitboards. Many many applications do not need 64-bit values, and in general they won't run faster as a result of compiling as a 64-bit program. In general, they run slower because 64-bit instructions and pointer values take up more space and therefore consume more memory bandwidth and cache.
The exception is the x86-32/64 architecture. On this architecture, 64-bit programs generally are faster than the equivalent 32-bit programs. The reason is that the x86-64 architecture provides double the amount of cpu registers compared to the x86-32 architecture. This has basically nothing to do with the fact that it is a 64-bit architecture. What happened is that AMD (who designed the x86-64 instruction set which was later adopted by Intel) took the transition to 64-bit as an opportunity to improve on the 32-bit x86 architecture by extending the set of general purpose registers (plus some other improvements).
You can imagine it as .
You have 32 lane(bit) for transportation.\
& now you have 64 lane ( bit) for transportation.
Only helps where 32-bit values are not enough.
There ARE advantages to 64 bits beyond just 64 bits. For example, 8 additional general-purpose registers, something the x86 really needs. And this is a bit more than "doubling" given that we only have eax-edx in 32 bit mode, and get 8 more in 64 bits, so really tripling. And when you consider how eax/edx are used in multiply, the number of extra registers becomes even more significant. I have not seen many applications that run slower in 64 bit mode, not that they don't exist. But they are a small minority. Most run faster. And those that are left are mostly just more modest gains, or break-even. And some, notably bitboard chess engines, run significantly faster. Overall it is a significant gain no matter what the software...
Did you intend to add anything to what I already wrote?
lucasart wrote:
No there is a distinction in what Ronald is saying that you seem to have missed
=> yes x86-64 is faster than x86 in general, and that is an *exception* (more registers)
=> the extensive use of bitboards makes chess programs faster on 64 bit regardless of the architecture. in my engine the difference is like day and night, 64 bit is almost twice faster, and it's normal given the amount of bitboard operations.
Would that mean that Strelka being 32b and SP is the strongest algorithm?
It is at 5th place above and among 64 b programs!
Hood
is that 64b architecture neccassary, what is an advantage? 32bit seems to be enough to host chess program. Programs are not so big to need 64b addrress space.
The reason might be Java which is memory consuming when garbage collector is sleeping but good written C program ....
Rgds Hood
You gotta realize chess really had little or nothing to do with the decision to up it to 64bit. Just like we have no choice about Windows 7- if we want the latest technology. Then Windows 8. Programmers saw the day was coming soon when everything newly built was going to be 64bit- they really had little or no choice if they wanted to keep up. I'm not saying they don't like 64bit better- just that when it was still in the "thinking" stages- chess was never given a thought.
gts
What are you talking about ? You speak in the name of programmers, but from what you say, it's obvious that you've never written a line of code in your life.
Yes, AMD developed the 64 bit architecture for general purpose computing not chess. But the fact that you're running a x86-64 archi does not mean that 32 bit registers or 32 bit operations, nor does it mean that 16 bit ones are not possible anymore.
But in chess, because there are 64 squares on the board, a lot of theory was developped to take advantage of 64 bit operations to do chess operations. And the most advanced stage of it is certainly magic bitboards. To give you an idea, in layman terms, it means that I can calculate all the squares attacked by a sliding piece without a single loop, and with only a couply of 64 bit operations (multiplication and bit shift) and a couple of pointer deferencing.
You just need to be sure, whether 32-bit or 64-bit, that you don't get your hands "soiled" by touching Windows. We can't have that- you with filthy hands.
but good written C program ....
