[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnubg] Re: Bug-gnubg Digest, Vol 48, Issue 6
From: |
Frank Berger |
Subject: |
[Bug-gnubg] Re: Bug-gnubg Digest, Vol 48, Issue 6 |
Date: |
Mon, 6 Nov 2006 20:27:22 +0100 |
Message: 10
Date: Mon, 06 Nov 2006 14:27:50 +0100
From: ? ystein Johansen<address@hidden>
Subject: Re: [Bug-gnubg] 50% decrease in evaluation speed
There was also a suggestion of moving the whole neural net
evaluation over to the GPU to let the strong processor in
a modern computer do the hard work. The neural net evaluation
is basically just a matrix multiplication and GPUs are just
made for that. No work has been done thought.
There is a master thesis(?) realted to neural nets on GPU's. didnt
was that promising. The setup is so expensive, that it has only a
small gain with very large nets. O.k. This article is 1-2 years old
so the circumstances may have changed.
So, should we maybe make another benchmark test?
A test that tests all the neural nets, all the databases, and
all input calculations and so on. I guess we'll have to make
set of positions for such a benchmark, and these positions
should then not be selected at random, as todays speed
evaluation.
Good idea. Forward the positions to me and I will come up with the
same test.
I suggest a small set of positions:
3 contact
1 running because running is roughly 25% of the positions
or
6 contact
1 running
1 Bear off db... where with the later it depends a lot on the size of
the DB
so the first makes more appropriate to me.
IMHo it makes sense to differentiate with the ply 0/1/2 (or 1/2/3-
rest of the world counting)
Caching should be turned of IMHO
ciao
Frank
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug-gnubg] Re: Bug-gnubg Digest, Vol 48, Issue 6,
Frank Berger <=