rbarreira wrote:bob wrote:But one could argue that since Crafty's NPS would actually be 6x or 12x faster on the above hardware, that is a software shortcoming, and the hardware should get full credit. If we can't use it effectively, is that the engineer's fault?
But for my summary of results, I certainly used the effective speedup number, which was about 1024, as opposed to the theoretical max, which was 1500x.
The hardware shouldn't get full credit, if the question being asked is "how much does hardware contribute to chess strength".
What about slight re-wording: "How much _could_ the hardware contribute to chess strength?" If we omit the potential theoretical gain, could we not apply that same logic to parallel search in general, since not everyone is doing it, and just limit it to one CPU since they get nothing from the extra cores? Nothing says that we can't one day develop a perfect parallel algorithm.
If the algorithms being used can't take full advantage of the hardware, that means the hardware is contributing less. What matters are the facts of what the hardware is contributing in reality, not some pipe dream of what could be.
So we average this over all chess engines, and the ones without any parallel search drag this way back from where the ones with parallel search are, and the average then says that hardware contributes a lot less than it really does? It is not exactly black and white. One can make a case for either, and one can punch holes in either argument just as easily.
If alpha-beta was impossible to parallelize (fortunately it isn't), parallel hardware wouldn't contribute to chess strength, so it wouldn't get credit. That's clear as day to me...
What if we went back to 1976 or so before there was any thought of parallelizing alpha/beta, even though we had dual and quad-cpu systems around? So that hardware advance would not count in the "did" but would count in the "could" and we'd be having the same discussion back then as well. For the actual numbers, I fudged my calculations to account for the lost performance due to smp overhead. But that "loss" is still there, it still bugs me, and I still take a whack every now and then to reduce it. I do not believe it is an impossible task, just a very difficult one. But today, we are far enough from optimal that there is a _lot_ of room left to improve. That last 5% might be very difficult, but the next 10% from now is not.
But as you said, your results use this way of calculating, so all is well.