Go language

[rreagan]

How does the Go language compare performance wise to C/C++ for writing a chess engine?

http://golang.org/

[Ron Murawski]

Go compiles really quickly but performance is not good at all. It is one of the slowest of the compiled languages. There have been promises made to improve Go performance, but these changes have not been implemented yet.

Go vs C
http://shootout.alioth.debian.org/u64/b ... &lang2=gcc

Go vs C++
http://shootout.alioth.debian.org/u64/b ... &lang2=gpp

[Don]

Go compiles really quickly but performance is not good at all. It is one of the slowest of the compiled languages. There have been promises made to improve Go performance, but these changes have not been implemented yet.

Go vs C
http://shootout.alioth.debian.org/u64/b ... &lang2=gcc

Go vs C++
http://shootout.alioth.debian.org/u64/b ... &lang2=gpp

It's not so clear to me. A lot of the speed issues have to do with inefficient libraries that could be much better optimized and benchmarks that rely on those libraries. Another major issue is garbage collection which can be worked around.

I think it may be the case that Go is quite fast if you become an expert in writing fast go code - but that remains to be proved.

There is an example of a benchmark that showed Go being really slow but some simple analysis showed that the code was poorly written - or at least that it was not written well. The code was fixed up appropriate and a fair comparison was made (where both C and Go were doing the same thing) and it was very close to C in performance. And it turned out that the Java implementation already had those enhancements and would have been obscenely slow too. So one has to be extremely skeptical of any benchmark.

I'm not defending Go, it may indeed still be very slow but I'm reserving judgement for now. C code is usually fast because we know how to write C code and we are often forced to do things manually that some languages do automatically at a cost - but we don't have to use those language features.

One issue for me is "what is the point" if I have to go too far out of my way to write "pedal to the metal" fast code. I guess the point is that if you find a good language you can use it for more things. The idea of being able to use Go for high performance things as well as quick scripts without the pain of C is appealing - even if I still have to work harder to write "seriously fast" code. Is Go than language? I don't know.

[Ron Murawski]

Go compiles really quickly but performance is not good at all. It is one of the slowest of the compiled languages. There have been promises made to improve Go performance, but these changes have not been implemented yet.

Go vs C
http://shootout.alioth.debian.org/u64/b ... &lang2=gcc

Go vs C++
http://shootout.alioth.debian.org/u64/b ... &lang2=gpp

It's not so clear to me. A lot of the speed issues have to do with inefficient libraries that could be much better optimized and benchmarks that rely on those libraries. Another major issue is garbage collection which can be worked around.

I think it may be the case that Go is quite fast if you become an expert in writing fast go code - but that remains to be proved.

There is an example of a benchmark that showed Go being really slow but some simple analysis showed that the code was poorly written - or at least that it was not written well. The code was fixed up appropriate and a fair comparison was made (where both C and Go were doing the same thing) and it was very close to C in performance. And it turned out that the Java implementation already had those enhancements and would have been obscenely slow too. So one has to be extremely skeptical of any benchmark.

I'm not defending Go, it may indeed still be very slow but I'm reserving judgement for now. C code is usually fast because we know how to write C code and we are often forced to do things manually that some languages do automatically at a cost - but we don't have to use those language features.

One issue for me is "what is the point" if I have to go too far out of my way to write "pedal to the metal" fast code. I guess the point is that if you find a good language you can use it for more things. The idea of being able to use Go for high performance things as well as quick scripts without the pain of C is appealing - even if I still have to work harder to write "seriously fast" code. Is Go than language? I don't know.

Hi Don,

I think it may be the case that Go is quite fast if you become an expert in writing fast go code - but that remains to be proved.

The shootout benchmarks try to treat each language fairly. Advocates of the Go language are encouraged to submit more optimized Go code for any of the individual benchmark tests that they feel is poorly written. The implementation with the fastest time is the one displayed in the comparison charts that I linked to. Take a look here:
http://shootout.alioth.debian.org/u64/m ... hp?lang=go
As you can see, there have been several attempts to further optimize the Go code.

A lot of the speed issues have to do with inefficient libraries that could be much better optimized and benchmarks that rely on those libraries.

Improving the inefficient Go libraries is one of the promises that have been made, but not yet implemented. Go is a fully compiled language that, right now, runs at about the same speed as Java byte code running on its JIT.

The original question was this:

How does the Go language compare performance wise to C/C++ for writing a chess engine?

The performance of Go is plenty fast enough for most purposes, but it is not fast enough for top-level chess programs.

Best regards,
Ron

[Don]

Go compiles really quickly but performance is not good at all. It is one of the slowest of the compiled languages. There have been promises made to improve Go performance, but these changes have not been implemented yet.

Go vs C
http://shootout.alioth.debian.org/u64/b ... &lang2=gcc

Go vs C++
http://shootout.alioth.debian.org/u64/b ... &lang2=gpp

It's not so clear to me. A lot of the speed issues have to do with inefficient libraries that could be much better optimized and benchmarks that rely on those libraries. Another major issue is garbage collection which can be worked around.

I think it may be the case that Go is quite fast if you become an expert in writing fast go code - but that remains to be proved.

There is an example of a benchmark that showed Go being really slow but some simple analysis showed that the code was poorly written - or at least that it was not written well. The code was fixed up appropriate and a fair comparison was made (where both C and Go were doing the same thing) and it was very close to C in performance. And it turned out that the Java implementation already had those enhancements and would have been obscenely slow too. So one has to be extremely skeptical of any benchmark.

I'm not defending Go, it may indeed still be very slow but I'm reserving judgement for now. C code is usually fast because we know how to write C code and we are often forced to do things manually that some languages do automatically at a cost - but we don't have to use those language features.

One issue for me is "what is the point" if I have to go too far out of my way to write "pedal to the metal" fast code. I guess the point is that if you find a good language you can use it for more things. The idea of being able to use Go for high performance things as well as quick scripts without the pain of C is appealing - even if I still have to work harder to write "seriously fast" code. Is Go than language? I don't know.

Hi Don,

I think it may be the case that Go is quite fast if you become an expert in writing fast go code - but that remains to be proved.

The shootout benchmarks try to treat each language fairly. Advocates of the Go language are encouraged to submit more optimized Go code for any of the individual benchmark tests that they feel is poorly written. The implementation with the fastest time is the one displayed in the comparison charts that I linked to. Take a look here:
http://shootout.alioth.debian.org/u64/m ... hp?lang=go
As you can see, there have been several attempts to further optimize the Go code.

A lot of the speed issues have to do with inefficient libraries that could be much better optimized and benchmarks that rely on those libraries.

Improving the inefficient Go libraries is one of the promises that have been made, but not yet implemented. Go is a fully compiled language that, right now, runs at about the same speed as Java byte code running on its JIT.

The original question was this:

How does the Go language compare performance wise to C/C++ for writing a chess engine?

The shootout does not have a benchmark for chess. I have no expectations that there might be anything out there that is faster than C, otherwise I would be using it myself. But the benchmarks tend to be all over the place for any language which makes it difficult to do anything more than make a generalization. The real question as you point out is how fast is it for chess? I don't think there is any language that compares well to C for chess. I seriously considered D 2.0 as I think it's a seriously nice language but I'm still hedging - I want to see a bit more performance. I would not consider Go because I don't have any strong evidence that it's fast enough. I have been looking for something better than C for about 20 years now - something as fast (or very close) without nearly as many warts - and it still has not happened! I guess that is a pretty tall order.

The performance of Go is plenty fast enough for most purposes, but it is not fast enough for top-level chess programs.

Best regards,
Ron

[Ron Murawski]

Go compiles really quickly but performance is not good at all. It is one of the slowest of the compiled languages. There have been promises made to improve Go performance, but these changes have not been implemented yet.

Go vs C
http://shootout.alioth.debian.org/u64/b ... &lang2=gcc

Go vs C++
http://shootout.alioth.debian.org/u64/b ... &lang2=gpp

It's not so clear to me. A lot of the speed issues have to do with inefficient libraries that could be much better optimized and benchmarks that rely on those libraries. Another major issue is garbage collection which can be worked around.

I think it may be the case that Go is quite fast if you become an expert in writing fast go code - but that remains to be proved.

There is an example of a benchmark that showed Go being really slow but some simple analysis showed that the code was poorly written - or at least that it was not written well. The code was fixed up appropriate and a fair comparison was made (where both C and Go were doing the same thing) and it was very close to C in performance. And it turned out that the Java implementation already had those enhancements and would have been obscenely slow too. So one has to be extremely skeptical of any benchmark.

I'm not defending Go, it may indeed still be very slow but I'm reserving judgement for now. C code is usually fast because we know how to write C code and we are often forced to do things manually that some languages do automatically at a cost - but we don't have to use those language features.

One issue for me is "what is the point" if I have to go too far out of my way to write "pedal to the metal" fast code. I guess the point is that if you find a good language you can use it for more things. The idea of being able to use Go for high performance things as well as quick scripts without the pain of C is appealing - even if I still have to work harder to write "seriously fast" code. Is Go than language? I don't know.

Hi Don,

I think it may be the case that Go is quite fast if you become an expert in writing fast go code - but that remains to be proved.

The shootout benchmarks try to treat each language fairly. Advocates of the Go language are encouraged to submit more optimized Go code for any of the individual benchmark tests that they feel is poorly written. The implementation with the fastest time is the one displayed in the comparison charts that I linked to. Take a look here:
http://shootout.alioth.debian.org/u64/m ... hp?lang=go
As you can see, there have been several attempts to further optimize the Go code.

A lot of the speed issues have to do with inefficient libraries that could be much better optimized and benchmarks that rely on those libraries.

Improving the inefficient Go libraries is one of the promises that have been made, but not yet implemented. Go is a fully compiled language that, right now, runs at about the same speed as Java byte code running on its JIT.

The original question was this:

How does the Go language compare performance wise to C/C++ for writing a chess engine?

The shootout does not have a benchmark for chess. I have no expectations that there might be anything out there that is faster than C, otherwise I would be using it myself. But the benchmarks tend to be all over the place for any language which makes it difficult to do anything more than make a generalization. The real question as you point out is how fast is it for chess? I don't think there is any language that compares well to C for chess. I seriously considered D 2.0 as I think it's a seriously nice language but I'm still hedging - I want to see a bit more performance. I would not consider Go because I don't have any strong evidence that it's fast enough. I have been looking for something better than C for about 20 years now - something as fast (or very close) without nearly as many warts - and it still has not happened! I guess that is a pretty tall order.

The performance of Go is plenty fast enough for most purposes, but it is not fast enough for top-level chess programs.

Best regards,
Ron

I like the D language too. Last time I looked there was no support for Windows 64-bit builds so that disqualified it from my consideration.

Objective-C is a nice language (it is a super-set of the C language -- ie: C with objects), but I am leery that it might fade in popularity once the iPhone craze abates.

The best C alternative that I have found so far is Vala. I wrote my move generator in it and it was almost as fast as C (I got about 90% of the speed of C by avoiding Vala OO). But the Vala community is small and Linux-oriented and it's not easy to get help on Windows problems. Also, I couldn't find a decent IDE that supported the language.

If you ever find that ideal C replacement language, please be sure to let me know!

[Don]

I like the D language too. Last time I looked there was no support for Windows 64-bit builds so that disqualified it from my consideration.

Objective-C is a nice language (it is a super-set of the C language -- ie: C with objects), but I am leery that it might fade in popularity once the iPhone craze abates.

The best C alternative that I have found so far is Vala. I wrote my move generator in it and it was almost as fast as C (I got about 90% of the speed of C by avoiding Vala OO). But the Vala community is small and Linux-oriented and it's not easy to get help on Windows problems. Also, I couldn't find a decent IDE that supported the language.

If you ever find that ideal C replacement language, please be sure to let me know!

I like Vala too! Also, if you like Ruby you will like the version of Vala that has Ruby-like syntax. It's called genie and as far as I can tell it's just as fast - so it's like a super ruby but with some restrictions (because Ruby is too dynamic to have this much performance.)

Even though I am not into windows at all, my ideal language has to be cross-platform too, so Vala falls short in that area. I was very pleased that Go has been ported to windows in an official way. But Go is probably not that "perfect" language either for reasons we have talked about.

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.

[rreagan]

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

[Ron Murawski]

I like the D language too. Last time I looked there was no support for Windows 64-bit builds so that disqualified it from my consideration.

Objective-C is a nice language (it is a super-set of the C language -- ie: C with objects), but I am leery that it might fade in popularity once the iPhone craze abates.

The best C alternative that I have found so far is Vala. I wrote my move generator in it and it was almost as fast as C (I got about 90% of the speed of C by avoiding Vala OO). But the Vala community is small and Linux-oriented and it's not easy to get help on Windows problems. Also, I couldn't find a decent IDE that supported the language.

If you ever find that ideal C replacement language, please be sure to let me know!

I like Vala too! Also, if you like Ruby you will like the version of Vala that has Ruby-like syntax. It's called genie and as far as I can tell it's just as fast - so it's like a super ruby but with some restrictions (because Ruby is too dynamic to have this much performance.)

I used Genie syntax with the Vala compiler for my movegen. I'm particularly inaccurate typing punctuation, so I prefer Python/Ruby-like syntaxes.

Even though I am not into windows at all, my ideal language has to be cross-platform too, so Vala falls short in that area.

Send the Vala compiler the right switch and it generates portable C code for you. You can even do your Vala development on Windows:
https://code.google.com/p/vala-win32/downloads/list
The problem is not in the code-building, the problem is getting help for Windows-specific problems. The population of Genie developers on Windows is pretty close to zero.

I was very pleased that Go has been ported to windows in an official way. But Go is probably not that "perfect" language either for reasons we have talked about.

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.

Sometimes the perfect language isn't enough. I fell in love with the Scala language. It seemed absolutely perfect to me. I was willing to settle for Java-like speed instead of C-speed in order to use such an elegant language. I spent a lot of time studying the language. Armed with my new knowledge I started to write, you guessed it, yet another movegen. What I quickly discovered is that Scala compilation speed is awful. By the time I had 300 lines of code it was taking more than 15 seconds to compile into jvm byte-code. Also, the compiler error messages were quite mysterious.

The only ideal languages that conform to your wishes are D, Vala, or Objective-C. I don't know of any other languages that would meet your needs.

For myself, I use Python. If my code isn't fast enough I'll try to stay within Python by using PyPy (optimized Python vm that is 5x faster) or Shedskin (a cross-platform Python-to-C++ translator/compiler). And if my code still isn't fast enough, then I switch to C.

[Ron Murawski]

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!