Go language

[Don]

I have a long list of things that my perfect language should have and some that it MUST have, but near the top of my list is that it should be nearly as fast as C, produce standalone executable's and be highly cross platform. I would really also like to have associative arrays built into the language. I would like it to be easy enough to work with that I might reach for it to write scripts I might normally write in perl or ruby.

The first thing that comes to my mind when reading this is Cython (C-Extensions for Python).

The one question I have about it is whether or not it is practical for one to write "Python code" and have it run at C speed. I know that I can write "C code in Cython" and it will run at C speed, but then I might as well write it in C. I guess you do get some niceties with string processing, associative arrays, and a huge standard library.

The one possible path I see is that you can write a pure Python file, then you create second modifying file that includes static declarations which the Cython compiler uses to modify your Python file. That means you write Python code, and the Python code stays untouched.

It sounds like you get the best of both worlds, but again I'm not sure how well it works out in practice. Perhaps it's time for me to find out

I never noticed that Cython compiled Python to C code. I thought it was just for interfacing Python to C libraries, but now that I've read the Cython page more carefully, it seems that it is a full Python-to-C translator. Please report on your Cython experiment and thanks for the link!

I am sure this will not run Python programs at C speed. Python is a very very high level language with dynamic types - you don't run at C speed just by writing a Python to C translator. However it could very well be many times faster than Python, which is quite slow. I also doubt that it executes all Python programs, these things always come with limitations such as no run time reflection, no eval calls and such. If you can do eval it means that there is really a python interpreter embedded in the code and it's all a sham. Dynamic types would be a major problem and speed killer. I'm not being critical, I think such a thing is a great idea, especially if the limitations are not too severe. But it's no replacement for C for writing a chess program.

[rreagan]

I am sure this will not run Python programs at C speed. Python is a very very high level language with dynamic types - you don't run at C speed just by writing a Python to C translator. However it could very well be many times faster than Python, which is quite slow. I also doubt that it executes all Python programs, these things always come with limitations such as no run time reflection, no eval calls and such. If you can do eval it means that there is really a python interpreter embedded in the code and it's all a sham. Dynamic types would be a major problem and speed killer. I'm not being critical, I think such a thing is a great idea, especially if the limitations are not too severe. But it's no replacement for C for writing a chess program.

Perhaps it helps to have some background on how it works. Cython isn't like some other Python optimizers where you just give it the Python code and say "run this". Cython is a tool that lets you create Python extensions. When you compile Python with Cython, you literally get a .dll or .so that you can "import" like any other Python module.

The alternative is, you could learn the CPython C API and write C code, a whole bunch of it, ugly code, and compile that into a .dll/.so that you can import as a Python module. That's one way. Another way is to write a module in Python, do testing in Python, get it working as desired, then let Cython compile it to the same .dll/.so module. The benefit is, you don't have to write that ugly C code using the CPython API.

Cython lets you call C code (including C standard library), Python code (including Python standard library), and also write Python modules that get compiled to C speed code, and Cython glues it all together. All you have to do is tell Cython what C types your Python variables are (int, float, etc). Yes, if you're actually running Python code under the hood in part of your program, it's going to run at Python speed. And if you're running a converted C speed part of your program, you won't have things like introspection, but I think that's the point. You're willing to drop some of those nice features in your core loops in return for C speed. If you're wanting all of those nice dynamic features AND C speed, I'm not holding my breath for that happening in my lifetime.

So you wouldn't exactly write a chess program in Python and just compile it with Cython. You would probably take the approach of writing your user interface code in Python (UCI, etc), and then you would develop a chess module that you compile with Cython so it's C fast.

The main problem is overcoming Python idioms. For instance, the Cython compiler knows how to convert things like

Code: Select all

for i in range(64):
    ...

Into the standard C for loop:

Code: Select all

for &#40;i = 0; i < 64; i++) ...

As long as you tell it that "i" is an int.

However, I'm not sure how how well it's going to handle converting list comprehensions and generators and class objects and things like that. From what I have read these are all things on their roadmap, so it may just be a matter of time for them to appropriately handle enough of the idioms. It looks like their path to get there is clear, it's just the small matter of hammering out the details (isn't it always?).

I know that at the very least, you could write straightforward code with very few idioms, and it will compile to C speed. That's my first hand experience. The question is whether or not they can handle enough idioms that it makes for a more pleasant coding experience where you can "write Python" and end up with C speed.

For instance, a tic tac toe move generator in Python is:

Code: Select all

def moves ():
    return [ sq for sq in board if board[sq] == empty ]

But I'm not sure how Cython will handle that. It might handle it, I'm just not sure yet.

[spambanane]

As I always wanted to write a chess program, I took the chance now that Go was finally released:

http://code.google.com/p/gochess/

It is in eary stage, but capable of giving a beginner a hard time. I can't tell much about engine speed, I guess it's rather poor.

I found another go chess project recently:

http://code.google.com/p/gochess/

This guy is using bitboards, I use a 10x12 board representation.

One performance hit I came across is array access. Go is memory safe, so every access to an array element includes an assertion to make sure the array index is not out of bound. This, of course, comes at a cost. As I use arrays a lot (precomputed moves e.g.) this sums up.

So I wonder how the Go people will achive their goal to make Go (almost) as fast as C.

From my first project with Go I can tell that Go is fun to work with and it makes me very productive.

Heiko

[Don]

As I always wanted to write a chess program, I took the chance now that Go was finally released:

http://code.google.com/p/gochess/

It is in eary stage, but capable of giving a beginner a hard time. I can't tell much about engine speed, I guess it's rather poor.

I found another go chess project recently:

http://code.google.com/p/gochess/

This guy is using bitboards, I use a 10x12 board representation.

One performance hit I came across is array access. Go is memory safe, so every access to an array element includes an assertion to make sure the array index is not out of bound. This, of course, comes at a cost. As I use arrays a lot (precomputed moves e.g.) this sums up.

So I wonder how the Go people will achive their goal to make Go (almost) as fast as C.

From my first project with Go I can tell that Go is fun to work with and it makes me very productive.

Heiko

I think you should give it a go (no pun intended.) I'm pretty sure you will suffer some penalty in speed, but you may gain a lot with productivity. And if Go really catches on, which seems likely, you can look forward to future versions of Go with much higher performance. I think Go is already slated to be included in the GCC compiler suite if it's not already there - so performance is likely to get some serious attention.

[spambanane]

Thanks, Don.

Yes, there is gccgo. I think I should give it a try, I use the native go compiler so far. Anyway, I will stick to Go, it's to much fun to put it aside

Actually i'ts more important to see my engine "grow up" and to have a good design than to squeeze out another 3% by putting code into endless functions. The costs are to high - I can't imagine how people test code like this (My test code hase more SLOC than my engine code!).

[Don]

Thanks, Don.

Yes, there is gccgo. I think I should give it a try, I use the native go compiler so far. Anyway, I will stick to Go, it's to much fun to put it aside

Actually i'ts more important to see my engine "grow up" and to have a good design than to squeeze out another 3% by putting code into endless functions. The costs are to high - I can't imagine how people test code like this (My test code hase more SLOC than my engine code!).

My suggestion is to use BOTH compilers, but primarily use the golang version since is compiles fast as lightening - it will be more interactive. But make frequent compiles using gccgo too to make sure your code is always compatible. I think they are 99% compatible but don't box yourself into a corner in case it's not. Then for "release" quality binaries you can use the one that is fastest, whichever that might be at the time.

[spambanane]

I just noticed I posted a wrong hyperlink. The other (bitboard based) chess program written in Go is located here:

https://github.com/lorenzo-stoakes/weak