Atom CPU Benchmarks

[brianr]

Below are links to some Atom Crafty CPU benchmarks in this separate thread from the outstanding idea Michael Sherwin is proposing here
http://www.talkchess.com/forum/viewtopic.php?t=36623

http://www.timelordz.com/wiki/index.php ... Benchmarks
http://macles.blogspot.com/2008/09/inte ... -atom.html

I had assumed Atom was far more wimpy than it appears.
On the other hand, engines where authors have devoted time to strong parallel searching will be shortchanged, I think.
Nonetheless, this sort of event will help invigorate the CC community, and I think we should all try to "make it happen".

[ernest]

Where do you see Atom benchmarks ???

[Gian-Carlo Pascutto]

On the other hand, engines where authors have devoted time to strong parallel searching will be shortchanged, I think.

An efficient parallel search can be interesting on Atom due to the big effect of hyperthreading there.

[brianr]

Both links seem to refer to Atom N270 1.6GHz CPUs with just one core but with HT.
There are dual core models too; see
http://ark.intel.com/ProductCollection. ... lyID=29035

As to HT with parallel search, yes it does help NPS, but not time-to-depth (for most engines, I think), which I think is a more meaningful indicator.

[bob]

Both links seem to refer to Atom N270 1.6GHz CPUs with just one core but with HT.
There are dual core models too; see
http://ark.intel.com/ProductCollection. ... lyID=29035

As to HT with parallel search, yes it does help NPS, but not time-to-depth (for most engines, I think), which I think is a more meaningful indicator.

Question is, what is the HT gain? If memory is slow, so that HT can hide some of the latency by executing a 2nd thread, then you _could_ see more benefit from HT on than the 30% search overhead the second thread brings with it. I've never seen that kind of gain with Crafty on Intel, since I have spent a ton of time trying to make memory accesses as efficient as possible.

But I have not tested or worked on an atom-based platform, as of yet...

[Gian-Carlo Pascutto]

As to HT with parallel search, yes it does help NPS, but not time-to-depth (for most engines, I think), which I think is a more meaningful indicator.

This is entirely dependent on the engine and the speedup it has (both NPS and parallel efficiency). This is why it is MORE important to have a good SMP search on Atom, contrary to what you claimed.

Atom is an in-order core, and even with proper prefetching and proper cache layout you are still going to stall a lot for memory, because it cannot hide cache latency *at all*, except through running the second thread.

[brianr]

This is entirely dependent on the engine and the speedup it has (both NPS and parallel efficiency). This is why it is MORE important to have a good SMP search on Atom, contrary to what you claimed.

Perhaps you misunderstood my comment.
I am sure that the architecture issues are also important.

What I was trying to say was that engines with strong parallel search will be limited by the small number of cores with Atom (2) relative to the much larger number of cores used in recent events (8+, excluding clusters).

Tinker does not use parallel search and I do not claim to know very much about it, but I gather that it is quite a bit easier to just do parallel search for 2 cores than it is to do it really well with 8 or more. The "really well for 8+" effort is what looks to me like it would be wasted on Atom.

Atom is probably new to many of us, so additional insights regarding the Atom architecture would be much appreciated.

[rbarreira]

One significant difference is that the bit-scanning instructions are quite slow on the Atom (16 cycles of latency, as opposed to 1-4 on AMD K10, Intel Core 2 and Nehalem). I think many people use those on their bitboard chess engines.