Darren Cook wrote:
> I wonder if you had anything to say on how the development was? I'm
> especially interested if you think if there was some aspect of the way
> libego is written that made it either hard work for you, or made it
> inefficient to wrap?
I don't think so, beyond being written in C++ in the first place. C++
code is harder to wrap than C code just because C++ interfaces are that
much richer, and because Pyrex isn't really designed for C++.
(Well, there was one thing: I didn't find a nice way to wrap the
functions that use iostreams in their interfaces. But that's not very
interesting, because those are the text-manipulation bits that you
wouldn't write in C++ if you were making a hybrid program).
A lot of the inefficiency comes because I was aiming for a Python
extension with pretty much the same interface as libego. For real work
it would be better to start with the attitude "let's make a decent
Python extension for working with go boards, and use libego to build
it". I suppose you'd have functions for looping over each point in the
board, for example, which would avoid constructing a silly Python Vertex
object for each point.
A real hybrid program would be more efficient again, because you could
have C++ code implementing exactly what the interpreted code happens to
need, and you could do away with the expectation that you shouldn't be
able to crash the Python interpreter by passing bad parameters to an
extension module. I still suspect that Python would be too slow to use
for anything that happens as frequently as once per playout.
> In notes.txt you say the speed dropped from 70-75 kpps to 43 kpps when
> used in the wrapper (compared to 1 or 2.5 kpps in native python). And
> you say this is due to the overhead of converting and checking
> parameters? If you increase the number of playouts by a factor of 10
> does it close in to 70kpps?
That drop happens because the Python code for running the benchmark
itself is slower than the C++ code for doing so. That is, (I think) we
lose so much speed because each iteration of the Python code in this
loop
for i in xrange(playout_count):
working_board = start_board.copy()
playout = Playout_cls(working_board, first_player)
status = runner(playout)
if status == pyego.PLAYOUT_OK:
wins[working_board.winner()] += 1
elif status == pyego.PLAYOUT_MERCY:
wins[working_board.approx_winner()] += 1
takes similar time to the single 9x9 libego playout that it runs.
Increasing the number of playouts doesn't change things. But if I try it
on a 19x19 board the penalty is rather lower, because the C++ code takes
more time.
> I wondered if it might be possible that some compiler optimization got
> missed, or is just not possible, when built as an extension?
The drop from ~75 to ~70 kpps is because of poorer compiler output when
building as an extension (that is: I changed 'always_inline' to plain
'inline' everywhere to get the extension to compile; I presume it would
be possible to put always_inline back and have separate entry points for
the Python code marked plain 'inline', and I should think this would
regain that 7%).
-M-
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
