According to this article intel is going to detail an eight-core Xeon processor at the International Solid-State Circuits Conference in San Francisco next month: http://www.tcmagazine.com/comments.php? ... 89&catid=2
Sounds interesting ... personally I would really like to get my hands on an overclockable "Skulltrail" type platform for 2 x 8core Nehalems. Imagine 16 cores at 5ghz !!! I think after 16 cores the advantage of hardware for chess gets diminishing returns and thus a different method such as clustering type setup would give more performance.
I think when 32 core system will be available someone should run tests on 8,16 and 32 cores and put numbers. When we will see numbers, we can make conclusion
Yar wrote:I think when 32 core system will be available someone should run tests on 8,16 and 32 cores and put numbers. When we will see numbers, we can make conclusion
We can only make a conclusion about the program under test, though.
An improved algorithm may scale better.
I read a paper on memory transactions that showed it scales well up to the hundreds of CPUs.
M ANSARI wrote:Sounds interesting ... personally I would really like to get my hands on an overclockable "Skulltrail" type platform for 2 x 8core Nehalems. Imagine 16 cores at 5ghz !!! I think after 16 cores the advantage of hardware for chess gets diminishing returns and thus a different method such as clustering type setup would give more performance.
You will never get more performance out of clustering than out of a shared memory system. (Barring edge cases where the cluster connect is faster than the remote memory, of course)
But you can get loads more performance per dollar.
You might be right in general to a certain point. But really shared memory multi CPU systems using today's parallel code will start to get diminishing returns probably starting with 16 cores ... maybe 32 cores. Then you would need something quite different and clustering ala Rybka Cluster seems to be a very strong idea.
M ANSARI wrote:Sounds interesting ... personally I would really like to get my hands on an overclockable "Skulltrail" type platform for 2 x 8core Nehalems. Imagine 16 cores at 5ghz !!! I think after 16 cores the advantage of hardware for chess gets diminishing returns and thus a different method such as clustering type setup would give more performance.
You will never get more performance out of clustering than out of a shared memory system. (Barring edge cases where the cluster connect is faster than the remote memory, of course)
But you can get loads more performance per dollar.
Somehow most think that using a cluster is just a matter of compiling differently or something. Not having shared memory is a _huge_ issue...
M ANSARI wrote:You might be right in general to a certain point. But really shared memory multi CPU systems using today's parallel code will start to get diminishing returns probably starting with 16 cores ... maybe 32 cores. Then you would need something quite different and clustering ala Rybka Cluster seems to be a very strong idea.
You missed his point. _anything_ you can do with a cluster, I can do with a normal SMP box _better_. Because the cluster has communication overhead that a SMP box does not. The advantage of a cluster is in terms of cost per node. Far cheaper to buy a 32 node cluster than a 32 CPU (single core chips) SMP box. But given the choice, I'll take the SMP box _every_ time if all else but cost is equal..
Yes, but you will end up at a point where an SMP box would have to be configured with a totally different approach, and by that I mean to have some cores that are working as modules and not as one coherent calculating engine as is done today. So ofcourse if you have this "cluster type" engine within one hardware roof the results would be better than having the same configuration with a LAN latency hit. But the way MP engines work today they will reach a certain wall where throwing a huge number of cores will get minimal benefit ... and thus I would think that using all those additional cores that are not doing much benefit can be used in a better configuration.
