Heikki, Yes, I like your approach of a library and using high level language.
One must be careful that it doesn't get in the way. Sometimes, the low level library imposes some constraints so that you still don't quite get the best of both worlds. For example it would be great if you could use inline-perl to do something like this, but it's not easy to use a C data structure with perl, or visa versa. So you might end up with a program that is pretty much a C program with just a few routines (like GTP) and the user interface written in perl or python or whatever high level language you use. They key is that you still want almost all the time (to get ultimate performance) spent in the C library. If 90% of the time is spent in the library, then 99% of the executed code must be in C! That' s because a routine that might be insignificant written in C, might not be so insignificant written in python. Here is an example. Let's say you have a fast C library that can make 80,000 play-outs per second. The python script could call the routine that makes the playouts, but what is overhead from those 80,000 calls? It's not just the calls, but the results must be converted to a python representation if the python program works with it. But if this is not much overhead, do you put the play-outs in the python code too? Perhaps you code the low level routines in C but a Python routine is driving the process of a single random play-out? My guess, is that most of the guts of the program still have to be written in C and that the Python wrapper won't do very much interesting stuff. It's probably fine to do it this way and may save you some time - but you are not really getting much of the benefit of the high level program - you are not doing anything really "important" in the Python code. Nevertheless, even if you only had a few low level C routines and let Python do a lot of work, you would having something MUCH faster than pure Python and could do most of your experimentation in Python once you had this library. Of course you wouldn't really have a high performance program. It's hard to say just how far you could take and still be able to benefit significantly from using Python or some other high level language. - Don Heikki Levanto wrote: > On Wed, Nov 21, 2007 at 12:07:03PM -0500, Don Dailey wrote: > >> My advice when this question comes up (which language for go programmer) >> is to first ask, what do you hope to achieve? If you want to build a >> high performance go program, anything other than C or assembler is like >> tying your hand behind your back. If you do this only as a hobby and >> have no aspirations (just for fun and pleasure) then by all means, you >> will be much happier in a high level language. >> > > Interesting approach. I like C myself, so even as an amateur just dabbling in > the field, I have used it, and will do so again. > > But of course teh choice is never so black and white. If I had unlimited > amount of time (or some student labour available ;-), I would make a good C > library available from higher-level languages, so that the parts that matter > could be fat and efficient C, and those that don't matter, or where lots of > experimentation is useful, could be done in (say) python. > > There just isn't much point in optimizing much out of the 'list_commands' > routine of the gtp interpreter, it is used at msot once per game, and > communicating teh result over a network is going to be much slower than what > ever is done to find the commands... > > > - Heikki > who does not plan to do much more in the language war... > > > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
