bob wrote:
You don't like my using a program from 1995, that was designed to run on 1995 hardware and be fast, and now because it happens to be able to use the last 8 years of hardware improvements, that is a no-no. It is breaking some mythical rule that you attribute to me but I do not recall ever making such.
I don't understand why one would need to pick something that is still actively developed in both time periods. The odds that one thing is a good representative of the state of software at both points is pretty low. I know comparing the program I wrote in 1990 with my current program, while interesting (to me), would not really add much to this debate.
If you need source code to get things running, you could pick the best open source code from both periods. One advantage of this, is that the best open source is often extremely influential on other programs of the time. Stockfish from this period would be fine for representing top open source from this period. Not sure what represents the best open source from the past period you are trying to compare against...perhaps Crafty? If so, Crafty 1995 vs. Stockfish 2010 would be an interesting comparison.
Don wrote:The main problem is the 64 bit vs 32 bit difference.
If you believe that, then why are you testing 32-bit Rebel on 64-bit modern hardware? That's rendering Rebel as cripple-ware, because its not optimized for 64-bit. So it's unfair by your definition.
A 32 bit program is not crippled on a 64 bit machine. Run a 32 bit program on a 32 bit machine and then time it on a 64 bit machine and you will see it runs just as well.
Then do the same experiment with a 64 bit program and your eyes will be opened.
Don wrote:
There is this argument that 32 bit is not the right way to write a program that runs on a 64 bit machine. But I don't think anyone has actually proved that. It's difficult to prove because it's a whole different way of writing a program so you cannot just compare 2 programs.
Usually, sowing a little FUD is a resource for a not-very-strong argument. I'll sprinkle some agent orange on it by saying most people think crafty is one of the faster searchers. Sure, it's not proof, just like your doubts.
Don wrote:The primary argument in favor of 64 bit is Rybka,
It could hardly have been so in the 1990s when crafty was born.
Because there was none in the 90's!
Bob was heavily criticized for this design choice, and day after day we had to hear the argument "How many bitboard programs are in the top 10?" blah, blah, blah. Few believe in bitboards, or at least, it was a common strategy to disregard the technique as not practical. Many times I suspected it was a commercial strategy to disregard what you were not doing, but that was my impression. I followed this argument very closely over the years because I started to program my move generator by 1997 in bitboards. I never did anything different and I was very interested to hear the comments (now bob extrapolates that I criticize his choice ).
Rybka was finally the break that FINALLY convinced people that the technique could lead a program to the top. If the #1 is a bitboard program, of course, the previous statement was proven.
Miguel
Sorry, but this is wrong. Chess 4.x was bitboard in 1974. As were the Russians with Kaissa. As was Tom Truscott with Duchess in 1977. Bitboards have been around since the beginning of computer chess. We had dozens of bitboard programs well before Rybka became yet another bitboard program. Rybka was not "the beginning". It was well after "the end" of the debate.
Very well known facts, but irrelevant to what I wrote.
Rybka was not after the end of the debate, Rybka was the end of the debate.
Miguel
What is that based on? We had dozens of bitboard programs prior to Rybka. I do not know of any after Rybka that were not there before it was modified to use bitboards... There is a limit to how much credit one can give to Rybka. It's certainly strong. It was not the "final coronation" for bitboard programs. It came to that party _way_ late.
bob wrote:
You don't like my using a program from 1995, that was designed to run on 1995 hardware and be fast, and now because it happens to be able to use the last 8 years of hardware improvements, that is a no-no. It is breaking some mythical rule that you attribute to me but I do not recall ever making such.
I don't understand why one would need to pick something that is still actively developed in both time periods. The odds that one thing is a good representative of the state of software at both points is pretty low. I know comparing the program I wrote in 1990 with my current program, while interesting (to me), would not really add much to this debate.
If you need source code to get things running, you could pick the best open source code from both periods. One advantage of this, is that the best open source is often extremely influential on other programs of the time. Stockfish from this period would be fine for representing top open source from this period. Not sure what represents the best open source from the past period you are trying to compare against...perhaps Crafty? If so, Crafty 1995 vs. Stockfish 2010 would be an interesting comparison.
-Sam
The point is that it is very hard to compare program A(1995) to program B(2010). It's simply easier to run all the tests when you have the source of both, and it is (to me) a bit easier to use the same program on both ends. Each program does things differently, each can easily produce different results in these tests. Some, for example, won't see the big speedup I see in Crafty. Comparing apples to oranges always makes things less clear.
bob wrote:
You don't like my using a program from 1995, that was designed to run on 1995 hardware and be fast, and now because it happens to be able to use the last 8 years of hardware improvements, that is a no-no. It is breaking some mythical rule that you attribute to me but I do not recall ever making such.
I don't understand why one would need to pick something that is still actively developed in both time periods. The odds that one thing is a good representative of the state of software at both points is pretty low. I know comparing the program I wrote in 1990 with my current program, while interesting (to me), would not really add much to this debate.
If you need source code to get things running, you could pick the best open source code from both periods. One advantage of this, is that the best open source is often extremely influential on other programs of the time. Stockfish from this period would be fine for representing top open source from this period. Not sure what represents the best open source from the past period you are trying to compare against...perhaps Crafty? If so, Crafty 1995 vs. Stockfish 2010 would be an interesting comparison.
-Sam
The point is that it is very hard to compare program A(1995) to program B(2010). It's simply easier to run all the tests when you have the source of both, and it is (to me) a bit easier to use the same program on both ends. Each program does things differently, each can easily produce different results in these tests. Some, for example, won't see the big speedup I see in Crafty. Comparing apples to oranges always makes things less clear.
I don't understand why its harder to compare top 1995 open source to top 2010 open source than top 1995 crafty to top 2010 crafty. The point is not to determine crafty software progress, the point is to determine software progress (redefined by me as open source software progress because I know you want source code).
I understand its easier to have the source code, luckily you do have the Stockfish 2010 source code (and Crafty 1995 source code). Regarding comparing apples to oranges...well whole point of the exercise is to compare apples to oranges, so I guess we are stuck there.
bob wrote:
You don't like my using a program from 1995, that was designed to run on 1995 hardware and be fast, and now because it happens to be able to use the last 8 years of hardware improvements, that is a no-no. It is breaking some mythical rule that you attribute to me but I do not recall ever making such.
I don't understand why one would need to pick something that is still actively developed in both time periods. The odds that one thing is a good representative of the state of software at both points is pretty low. I know comparing the program I wrote in 1990 with my current program, while interesting (to me), would not really add much to this debate.
If you need source code to get things running, you could pick the best open source code from both periods. One advantage of this, is that the best open source is often extremely influential on other programs of the time. Stockfish from this period would be fine for representing top open source from this period. Not sure what represents the best open source from the past period you are trying to compare against...perhaps Crafty? If so, Crafty 1995 vs. Stockfish 2010 would be an interesting comparison.
-Sam
The point is that it is very hard to compare program A(1995) to program B(2010). It's simply easier to run all the tests when you have the source of both, and it is (to me) a bit easier to use the same program on both ends. Each program does things differently, each can easily produce different results in these tests. Some, for example, won't see the big speedup I see in Crafty. Comparing apples to oranges always makes things less clear.
I don't understand why its harder to compare top 1995 open source to top 2010 open source than top 1995 crafty to top 2010 crafty. The point is not to determine crafty software progress, the point is to determine software progress (redefined by me as open source software progress because I know you want source code).
I understand its easier to have the source code, luckily you do have the Stockfish 2010 source code (and Crafty 1995 source code). Regarding comparing apples to oranges...well whole point of the exercise is to compare apples to oranges, so I guess we are stuck there.
-Sam
Simple. there are two components. Hardware and software. If one gets more from hardware than the other, then comparing the software advantage is impossible because you will be measuring hardware when you test both on the same machine. We've already seen that Rebel sucks on new hardware. This affects its overall Elo as well.
Much easier if there is only one variable measured at a time. Same version on two different hardware platforms. Different versions on same hardware platform. Then you know which is hardware and which is software. If you mix, you won't.
Don wrote:The main problem is the 64 bit vs 32 bit difference.
If you believe that, then why are you testing 32-bit Rebel on 64-bit modern hardware? That's rendering Rebel as cripple-ware, because its not optimized for 64-bit. So it's unfair by your definition.
A 32 bit program is not crippled on a 64 bit machine. Run a 32 bit program on a 32 bit machine and then time it on a 64 bit machine and you will see it runs just as well.
Then do the same experiment with a 64 bit program and your eyes will be opened.
Don wrote:
There is this argument that 32 bit is not the right way to write a program that runs on a 64 bit machine. But I don't think anyone has actually proved that. It's difficult to prove because it's a whole different way of writing a program so you cannot just compare 2 programs.
Usually, sowing a little FUD is a resource for a not-very-strong argument. I'll sprinkle some agent orange on it by saying most people think crafty is one of the faster searchers. Sure, it's not proof, just like your doubts.
Don wrote:The primary argument in favor of 64 bit is Rybka,
It could hardly have been so in the 1990s when crafty was born.
Because there was none in the 90's!
Bob was heavily criticized for this design choice, and day after day we had to hear the argument "How many bitboard programs are in the top 10?" blah, blah, blah. Few believe in bitboards, or at least, it was a common strategy to disregard the technique as not practical. Many times I suspected it was a commercial strategy to disregard what you were not doing, but that was my impression. I followed this argument very closely over the years because I started to program my move generator by 1997 in bitboards. I never did anything different and I was very interested to hear the comments (now bob extrapolates that I criticize his choice ).
Rybka was finally the break that FINALLY convinced people that the technique could lead a program to the top. If the #1 is a bitboard program, of course, the previous statement was proven.
Miguel
Sorry, but this is wrong. Chess 4.x was bitboard in 1974. As were the Russians with Kaissa. As was Tom Truscott with Duchess in 1977. Bitboards have been around since the beginning of computer chess. We had dozens of bitboard programs well before Rybka became yet another bitboard program. Rybka was not "the beginning". It was well after "the end" of the debate.
Very well known facts, but irrelevant to what I wrote.
Rybka was not after the end of the debate, Rybka was the end of the debate.
Miguel
What is that based on? We had dozens of bitboard programs prior to Rybka. I do not know of any after Rybka that were not there before it was modified to use bitboards... There is a limit to how much credit one can give to Rybka. It's certainly strong. It was not the "final coronation" for bitboard programs. It came to that party _way_ late.
Who is talking about credit?
When Rybka become #1, it was not possible anymore to come with any type of argument to demonstrate the alleged "inferiority" of bitboards (even if bitboards had nothing to do with R becoming #1). The fact is all the discussions we had seen in the past evaporated.
Don wrote:The main problem is the 64 bit vs 32 bit difference.
If you believe that, then why are you testing 32-bit Rebel on 64-bit modern hardware? That's rendering Rebel as cripple-ware, because its not optimized for 64-bit. So it's unfair by your definition.
A 32 bit program is not crippled on a 64 bit machine. Run a 32 bit program on a 32 bit machine and then time it on a 64 bit machine and you will see it runs just as well.
Then do the same experiment with a 64 bit program and your eyes will be opened.
Don wrote:
There is this argument that 32 bit is not the right way to write a program that runs on a 64 bit machine. But I don't think anyone has actually proved that. It's difficult to prove because it's a whole different way of writing a program so you cannot just compare 2 programs.
Usually, sowing a little FUD is a resource for a not-very-strong argument. I'll sprinkle some agent orange on it by saying most people think crafty is one of the faster searchers. Sure, it's not proof, just like your doubts.
Don wrote:The primary argument in favor of 64 bit is Rybka,
It could hardly have been so in the 1990s when crafty was born.
Because there was none in the 90's!
Bob was heavily criticized for this design choice, and day after day we had to hear the argument "How many bitboard programs are in the top 10?" blah, blah, blah. Few believe in bitboards, or at least, it was a common strategy to disregard the technique as not practical. Many times I suspected it was a commercial strategy to disregard what you were not doing, but that was my impression. I followed this argument very closely over the years because I started to program my move generator by 1997 in bitboards. I never did anything different and I was very interested to hear the comments (now bob extrapolates that I criticize his choice ).
Rybka was finally the break that FINALLY convinced people that the technique could lead a program to the top. If the #1 is a bitboard program, of course, the previous statement was proven.
Miguel
Sorry, but this is wrong. Chess 4.x was bitboard in 1974. As were the Russians with Kaissa. As was Tom Truscott with Duchess in 1977. Bitboards have been around since the beginning of computer chess. We had dozens of bitboard programs well before Rybka became yet another bitboard program. Rybka was not "the beginning". It was well after "the end" of the debate.
Very well known facts, but irrelevant to what I wrote.
Rybka was not after the end of the debate, Rybka was the end of the debate.
Miguel
What is that based on? We had dozens of bitboard programs prior to Rybka. I do not know of any after Rybka that were not there before it was modified to use bitboards... There is a limit to how much credit one can give to Rybka. It's certainly strong. It was not the "final coronation" for bitboard programs. It came to that party _way_ late.
Who is talking about credit?
When Rybka become #1, it was not possible anymore to come with any type of argument to demonstrate the alleged "inferiority" of bitboards (even if bitboards had nothing to do with R becoming #1). The fact is all the discussions we had seen in the past evaporated.
Miguel
Exactly _what_ discussions? The only person I recall in the past 10-15 years continually bashing bitboards was Vincent D. I've not seen anybody else suggest that they were not working, and I have seen dozens of new programs using them. The magic move generation development showed that many were using them. Etc. If Vincent carries that much weight with you, fine. But I have not seen anyone else suggest bitboards are no good. And I haven't seen anyone at all suggest such in the past 5 years, well before Rybka existed or used bitboards.
Don wrote:The main problem is the 64 bit vs 32 bit difference.
If you believe that, then why are you testing 32-bit Rebel on 64-bit modern hardware? That's rendering Rebel as cripple-ware, because its not optimized for 64-bit. So it's unfair by your definition.
A 32 bit program is not crippled on a 64 bit machine. Run a 32 bit program on a 32 bit machine and then time it on a 64 bit machine and you will see it runs just as well.
Then do the same experiment with a 64 bit program and your eyes will be opened.
Don wrote:
There is this argument that 32 bit is not the right way to write a program that runs on a 64 bit machine. But I don't think anyone has actually proved that. It's difficult to prove because it's a whole different way of writing a program so you cannot just compare 2 programs.
Usually, sowing a little FUD is a resource for a not-very-strong argument. I'll sprinkle some agent orange on it by saying most people think crafty is one of the faster searchers. Sure, it's not proof, just like your doubts.
Don wrote:The primary argument in favor of 64 bit is Rybka,
It could hardly have been so in the 1990s when crafty was born.
Because there was none in the 90's!
Bob was heavily criticized for this design choice, and day after day we had to hear the argument "How many bitboard programs are in the top 10?" blah, blah, blah. Few believe in bitboards, or at least, it was a common strategy to disregard the technique as not practical. Many times I suspected it was a commercial strategy to disregard what you were not doing, but that was my impression. I followed this argument very closely over the years because I started to program my move generator by 1997 in bitboards. I never did anything different and I was very interested to hear the comments (now bob extrapolates that I criticize his choice ).
Rybka was finally the break that FINALLY convinced people that the technique could lead a program to the top. If the #1 is a bitboard program, of course, the previous statement was proven.
Miguel
Sorry, but this is wrong. Chess 4.x was bitboard in 1974. As were the Russians with Kaissa. As was Tom Truscott with Duchess in 1977. Bitboards have been around since the beginning of computer chess. We had dozens of bitboard programs well before Rybka became yet another bitboard program. Rybka was not "the beginning". It was well after "the end" of the debate.
Very well known facts, but irrelevant to what I wrote.
Rybka was not after the end of the debate, Rybka was the end of the debate.
Miguel
What is that based on? We had dozens of bitboard programs prior to Rybka. I do not know of any after Rybka that were not there before it was modified to use bitboards... There is a limit to how much credit one can give to Rybka. It's certainly strong. It was not the "final coronation" for bitboard programs. It came to that party _way_ late.
Who is talking about credit?
When Rybka become #1, it was not possible anymore to come with any type of argument to demonstrate the alleged "inferiority" of bitboards (even if bitboards had nothing to do with R becoming #1). The fact is all the discussions we had seen in the past evaporated.
Miguel
Exactly _what_ discussions? The only person I recall in the past 10-15 years continually bashing bitboards was Vincent D. I've not seen anybody else suggest that they were not working, and I have seen dozens of new programs using them. The magic move generation development showed that many were using them. Etc. If Vincent carries that much weight with you, fine. But I have not seen anyone else suggest bitboards are no good. And I haven't seen anyone at all suggest such in the past 5 years, well before Rybka existed or used bitboards.
This is wishful thinking.
It took me few seconds to find a post from C. Theron criticizing bitboards.
Yes, Vincent too.
>>>>You have just explained why the bitboarders are less handicapped on 64 bits
>>>>machines.
>>>>
>>>>You have not explained why they are supposed to have "a bit of performance
>>>>advantage on 64 bits processors".
>>>>
>>>>
>>>>
>>>> Christophe
>>>
>>>Clearly, nothing beats the ugliness of bitboards.
>>>
>>>
>>>
>>> Christophe
I cannot believe you do not remember any of these posts.
Don wrote:The main problem is the 64 bit vs 32 bit difference.
If you believe that, then why are you testing 32-bit Rebel on 64-bit modern hardware? That's rendering Rebel as cripple-ware, because its not optimized for 64-bit. So it's unfair by your definition.
A 32 bit program is not crippled on a 64 bit machine. Run a 32 bit program on a 32 bit machine and then time it on a 64 bit machine and you will see it runs just as well.
Then do the same experiment with a 64 bit program and your eyes will be opened.
Don wrote:
There is this argument that 32 bit is not the right way to write a program that runs on a 64 bit machine. But I don't think anyone has actually proved that. It's difficult to prove because it's a whole different way of writing a program so you cannot just compare 2 programs.
Usually, sowing a little FUD is a resource for a not-very-strong argument. I'll sprinkle some agent orange on it by saying most people think crafty is one of the faster searchers. Sure, it's not proof, just like your doubts.
Don wrote:The primary argument in favor of 64 bit is Rybka,
It could hardly have been so in the 1990s when crafty was born.
Because there was none in the 90's!
Bob was heavily criticized for this design choice, and day after day we had to hear the argument "How many bitboard programs are in the top 10?" blah, blah, blah. Few believe in bitboards, or at least, it was a common strategy to disregard the technique as not practical. Many times I suspected it was a commercial strategy to disregard what you were not doing, but that was my impression. I followed this argument very closely over the years because I started to program my move generator by 1997 in bitboards. I never did anything different and I was very interested to hear the comments (now bob extrapolates that I criticize his choice ).
Rybka was finally the break that FINALLY convinced people that the technique could lead a program to the top. If the #1 is a bitboard program, of course, the previous statement was proven.
Miguel
Sorry, but this is wrong. Chess 4.x was bitboard in 1974. As were the Russians with Kaissa. As was Tom Truscott with Duchess in 1977. Bitboards have been around since the beginning of computer chess. We had dozens of bitboard programs well before Rybka became yet another bitboard program. Rybka was not "the beginning". It was well after "the end" of the debate.
Very well known facts, but irrelevant to what I wrote.
Rybka was not after the end of the debate, Rybka was the end of the debate.
Miguel
What is that based on? We had dozens of bitboard programs prior to Rybka. I do not know of any after Rybka that were not there before it was modified to use bitboards... There is a limit to how much credit one can give to Rybka. It's certainly strong. It was not the "final coronation" for bitboard programs. It came to that party _way_ late.
Who is talking about credit?
When Rybka become #1, it was not possible anymore to come with any type of argument to demonstrate the alleged "inferiority" of bitboards (even if bitboards had nothing to do with R becoming #1). The fact is all the discussions we had seen in the past evaporated.
Miguel
Exactly _what_ discussions? The only person I recall in the past 10-15 years continually bashing bitboards was Vincent D. I've not seen anybody else suggest that they were not working, and I have seen dozens of new programs using them. The magic move generation development showed that many were using them. Etc. If Vincent carries that much weight with you, fine. But I have not seen anyone else suggest bitboards are no good. And I haven't seen anyone at all suggest such in the past 5 years, well before Rybka existed or used bitboards.
This is wishful thinking.
It took me few seconds to find a post from C. Theron criticizing bitboards.
Yes, Vincent too.
>>>>You have just explained why the bitboarders are less handicapped on 64 bits
>>>>machines.
>>>>
>>>>You have not explained why they are supposed to have "a bit of performance
>>>>advantage on 64 bits processors".
>>>>
>>>>
>>>>
>>>> Christophe
>>>
>>>Clearly, nothing beats the ugliness of bitboards.
>>>
>>>
>>>
>>> Christophe
I cannot believe you do not remember any of these posts.
Miguel
"ugliness" has nothing to do with performance. Any others you can recall? CT has not posted here in at least 5 years or so, so as I said, nothing recently.
Don wrote:The main problem is the 64 bit vs 32 bit difference.
If you believe that, then why are you testing 32-bit Rebel on 64-bit modern hardware? That's rendering Rebel as cripple-ware, because its not optimized for 64-bit. So it's unfair by your definition.
A 32 bit program is not crippled on a 64 bit machine. Run a 32 bit program on a 32 bit machine and then time it on a 64 bit machine and you will see it runs just as well.
Then do the same experiment with a 64 bit program and your eyes will be opened.
Don wrote:
There is this argument that 32 bit is not the right way to write a program that runs on a 64 bit machine. But I don't think anyone has actually proved that. It's difficult to prove because it's a whole different way of writing a program so you cannot just compare 2 programs.
Usually, sowing a little FUD is a resource for a not-very-strong argument. I'll sprinkle some agent orange on it by saying most people think crafty is one of the faster searchers. Sure, it's not proof, just like your doubts.
Don wrote:The primary argument in favor of 64 bit is Rybka,
It could hardly have been so in the 1990s when crafty was born.
Because there was none in the 90's!
Bob was heavily criticized for this design choice, and day after day we had to hear the argument "How many bitboard programs are in the top 10?" blah, blah, blah. Few believe in bitboards, or at least, it was a common strategy to disregard the technique as not practical. Many times I suspected it was a commercial strategy to disregard what you were not doing, but that was my impression. I followed this argument very closely over the years because I started to program my move generator by 1997 in bitboards. I never did anything different and I was very interested to hear the comments (now bob extrapolates that I criticize his choice ).
Rybka was finally the break that FINALLY convinced people that the technique could lead a program to the top. If the #1 is a bitboard program, of course, the previous statement was proven.
Miguel
Sorry, but this is wrong. Chess 4.x was bitboard in 1974. As were the Russians with Kaissa. As was Tom Truscott with Duchess in 1977. Bitboards have been around since the beginning of computer chess. We had dozens of bitboard programs well before Rybka became yet another bitboard program. Rybka was not "the beginning". It was well after "the end" of the debate.
Very well known facts, but irrelevant to what I wrote.
Rybka was not after the end of the debate, Rybka was the end of the debate.
Miguel
What is that based on? We had dozens of bitboard programs prior to Rybka. I do not know of any after Rybka that were not there before it was modified to use bitboards... There is a limit to how much credit one can give to Rybka. It's certainly strong. It was not the "final coronation" for bitboard programs. It came to that party _way_ late.
Who is talking about credit?
When Rybka become #1, it was not possible anymore to come with any type of argument to demonstrate the alleged "inferiority" of bitboards (even if bitboards had nothing to do with R becoming #1). The fact is all the discussions we had seen in the past evaporated.
Miguel
Exactly _what_ discussions? The only person I recall in the past 10-15 years continually bashing bitboards was Vincent D. I've not seen anybody else suggest that they were not working, and I have seen dozens of new programs using them. The magic move generation development showed that many were using them. Etc. If Vincent carries that much weight with you, fine. But I have not seen anyone else suggest bitboards are no good. And I haven't seen anyone at all suggest such in the past 5 years, well before Rybka existed or used bitboards.
This is wishful thinking.
It took me few seconds to find a post from C. Theron criticizing bitboards.
Yes, Vincent too.
>>>>You have just explained why the bitboarders are less handicapped on 64 bits
>>>>machines.
>>>>
>>>>You have not explained why they are supposed to have "a bit of performance
>>>>advantage on 64 bits processors".
>>>>
>>>>
>>>>
>>>> Christophe
>>>
>>>Clearly, nothing beats the ugliness of bitboards.
>>>
>>>
>>>
>>> Christophe
I cannot believe you do not remember any of these posts.
Miguel
"ugliness" has nothing to do with performance. Any others you can recall? CT has not posted here in at least 5 years or so, so as I said, nothing recently.
That is the whole point!! because all of those discussions happened before Rybka became #1
You want more posts? Why? so you can keep ignoring them ? You answered the second but ignored the first one, which said
>>>>You have just explained why the bitboarders are less handicapped on 64 bits
>>>>machines.
). 
? You answered the second but ignored the first one, which said