On Sep 9, 2009, at 11:57 PM, Christian Nentwich wrote:
Mark,
let me try to add some more context to answer your questions. When
I say in my conclusion that "it's not worth it", I mean it's not
worth using the GPU to run playout algorithms of the sort that are
in use today. There may be many other algorithms that form part of
Go engines where the GPU can provide an order-of-magnitude speedup.
Still more where the GPU can run in parallel with the CPU to help.
In my experiments, a CPU core got 47,000 playouts per second and
the GPU 170,000. But:
- My computer has two cores (so it gets 94,000 playouts with 2
threads)
later generion quadcores hardly have a higher ipc than core2.
the core2 dual has a brilliant IPC.
Nehalem is hardly faster than phenom2 nor core2 for diep. It's really
the compiler quality and tricks with turboboost
that lure the audience (like the experimental testmachine at
testsites gets cooled down to far under 20C, entire machine
all components, as there is a powerincrease of 10% when moving from
25C to 50C, ever seen at home a machine that's
cooler than 50C? Additionally the turboboost gets manually
overclocked/put to +600Mhz and the RAM is a type of RAM
you can't realy afford bla bla bla). Of course this is multibillion
companies and every single one of them tries to outdo another
one to look better.
So really you should compare it 1 to 1 powerwise.
the gtx285 then is not so impressive. It's on par with quadcore
nehalems in terms of gflops per watt.
I wouldn't say it's an outdated gpu, as it is a fast gpu, but for
gpgpu it obviously is slow.
The latest AMD gpu is however 4 times better here.
So your result is maximum factor 2 off for the core2 playouts there
at a chip that in other areas is on par with Nehalem.
You beat it factor 2 there.
8 core machines is not a fair compare as those have 2 sockets. So you
should compare that with the 4 tesla setup, it has 960 streamcores.
The only fair Nvidia compare with quadcores is when using tesla. Now
i realize it is like $1800 a piece nearly, which is a lot for a GPU
on stereoids,
yet that's a fair compare to be honest.
If we compare things let's compare fair. A 8 core nehalem is the
maximum number of cores intel can deliver single machine as a fast
machine.
I'm skipping the single memory controller 24 core box now from a year
ago (dunnington).
The 8 core setup you really should compare with the Tesla times 4
cpu's so that's 960 cores.
In reality you take a 300 euro card now. What's there for 300 euro
from intel or AMD, not a 3.2Ghz i7-965 that's for sure,
as that thing has a cost of 1000+ euro.
So effectively you lose a factor 2 at most, your thing at the nvidia
is still scaling better then.
As for the parallel speedup one would get out of game tree search
with so many threads versus 4 fast cores, this is a reality.
Yes that's not so efficient yet.
However there is a solution there to get a good speedup (at least for
chess) that i figured out on paper. If there is 1 solution i bet
there is more
and also solutions for computer-go. The problem as always is getting
funded to carry something out like that, as software on a gpu doesn't
sell
of course.
- My computer's processor (intel core duo 6600) is 3 years old,
and far from state of the art
- My graphics card (Geforce 285) on the other hand, is recently
purchased and one of the top graphics cards
That means that my old CPU already gets more than twice the speed
of the GPU. An Intel Nehalem processor would surely beat it, let
alone an 8-core system. Bearing in mind the severe drawbacks of the
GPU - these are not general purpose processors, there is much you
can't do on them - this limits their usefulness with this
algorithm. Compare this speedup to truly highly parallel
algorithms: random number generation, matrix multiplication, monte-
carlo simulation of options (which are highly parallel because
there is no branching and little data); you see speedups of 10x to
100x over the CPU with those.
matrixmultiplication is not THAT easy to solve well. Initial attempts
were 20% efficient at Nvidia gpu's when using faster approximations
(so not stupid simple manner which is
ugly slow, but FFT wise), and that was for ideal sized matrice. So if
in the lab it already is that inefficient that means there is
problems everywhere.
it's maturing rapidly now however.
The 9% occupancy may be puzzling but there is little that can be
done about that. This, and the talk about threads and blocks would
take a while to explain, because GPUs don't work like general
purpose CPUs. They are SIMD processors meaning that each processor
can run many threads in parallel on different items of data but
only if *all threads are executing the same instruction*. There is
only one instruction decoding stage per processor cycle. If any
"if" statements or loops diverge, threads will be serialised until
they join again. The 9% occupancy is a function of the amount of
data needed to perform the task, and the branch divergence (caused
by the playouts being different). There is little that can be done
about it other than use a completely different algorithm.
If you google "CUDA block threads" you will find out more. In
short, the GPU runs like a grid cluster. In each block, 64 threads
run in parallel, conceptually. On the actual hardware, in each
processor 16 threads from one block will execute followed by 16
from another ("half-warps"). If any threads are blocked (memory
reads costs ~400 cycles!)
400 cycles is rather optimistic guess.
Nvidia itself only quote for the 8800 was 600 cycles,
yet i assume that's when all other streamcores idle and assuming
ideal sequential reads from all streamcores,
not crisscross random as you do in reality.
then threads from another block are scheduled instead. So the
answer is: yes, there are 64 * 80 threads conceptually but they're
not always scheduled at the same time.
Comments on specific questions below.
If paralellism is what you're looking for, why not have one thread
per
move candidate? Use that to collect AMAF statistics. 16Kb is not a
lot
to work with, so the statistics may have to be shared.
One thread per move candidate is feasible with the architecture I
used, since every thread has its own board. I have not implemented
AMAF, so I cannot comment on the statistics bit, but the "output"
of your algorithm is typically not in the 16k shared memory anyway.
You'd write that to global memory (1GB). Would uniform random
playouts be good enough for this though?
Another question I'd have is whether putting two graphics card would
double the capacity.
Yes it would. It would pretty much precisely double it (the "grid"
to schedule over just gets larger, but there is no additional
overhead).
Well here you hit a problem. 2 gpu's have no shared memory between
each other. So for computerchess it's not so easy to have 2 gpu's
cooperate (say the x2 versions or the 295 version).
Note there is memory links between the 2 gpu's. Nvidia and AMD each
have their own solution there, but it's again a lot of programming
work to get it to work i'd assume and speedup not
so very brilliant....
Did you try this for 9x9 or 19x19?
I used 19x19. If you do it for 9x9, you can probably run 128
threads per block because of the smaller board representation. The
speedup would be correspondingly larger (4x or more). I chose 19x19
because of the severe memory limitations of the architecture; it
seemed that 9x9 would just make my life a bit too easy for comfort...
Well we can also play chess on a 4x4 chessboard, or play checkers on
a 8x8 board, but it isn't much fun is it. 19x19 is more realistic for
go.
Christian
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
