Re: [computer-go] programming (languages) light-simulation contest
Claus Reinke wrote: As for me, i'm really NOT interested in knowing what langage is good for go programming. That's simply not a question i can ask myself, nor anyone else. This question doesn't make any sense for me. Still if someone can get the standard light playout right in less than 10 code line, and they are very understandable lines. I would be very happy to see it. But it would never mean for me that, this language is BEST. Even if the peformances are optimal there. I think 90% of the this language is the best debate gets it's root in some affective part of the people engaged with it. If, instead of asking what is the best language for writing a strong Go playing program, we ask what is the best language for clealry expressing the rules of Go (recognizing and scoring legal games), then I think Haskell (http://www.haskell.org/) deserves some consideration. See my attempt at http://www.cwi.nl/~tromp/go/Go.hs Such programs go a long way toward removing all ambiguity from informal (e.g. English language) rule statements. regards, -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming (languages) light-simulation contest
On Mon, 2008-10-20 at 16:57 -0400, John Tromp wrote: Claus Reinke wrote: As for me, i'm really NOT interested in knowing what langage is good for go programming. That's simply not a question i can ask myself, nor anyone else. This question doesn't make any sense for me. Still if someone can get the standard light playout right in less than 10 code line, and they are very understandable lines. I would be very happy to see it. But it would never mean for me that, this language is BEST. Even if the peformances are optimal there. I think 90% of the this language is the best debate gets it's root in some affective part of the people engaged with it. If, instead of asking what is the best language for writing a strong Go playing program, we ask what is the best language for clealry expressing the rules of Go (recognizing and scoring legal games), then I think Haskell (http://www.haskell.org/) deserves some consideration. See my attempt at http://www.cwi.nl/~tromp/go/Go.hs Such programs go a long way toward removing all ambiguity from informal (e.g. English language) rule statements. That's another question of course, but a good one. Haskell is probably one the better languages for expressing an algorithm like this. It would require each entrant to be judged of course. To answer Denis whom you quote above, I'm not REALLY asking which language is best, or good, for go. I realize that is fruitless and that there is no correct answer. It's more of a contest to see who can write the highest performing conforming version of this bot and to see what language they choose to write it in. You are free to write it any way you want as long as I cannot prove (empirically) that something is wrong with it, i.e. that it has different behavior than a trusted reference bot. - Don regards, -John ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming (languages) light-simulation contest
Hi, On Wed, Oct 15, 2008 at 02:51, Claus Reinke [EMAIL PROTECTED] wrote: So, once you've got your representations (sets/bitmaps, arrays/hashtables, etc.) implemented in libraries, the programming language itself may not matter much any more (recursion simplifies things, but whether one recursively collects sets of liberties in imperative, functional, logic, or object-oriented code may not make much difference - even assembler might be manageable, given such libraries, just that it might doom your code when you move to a different machine in future). Good points (even those I didn't quote). I'd just like to point out that once the representations and libraries above are implemented, one effectively has implemented a go-specific language! One could in principle give it a concrete syntax different than the one of the host language, but it's not certain it would be worth it. best regards, Vlad ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming (languages) light-simulation contest
As for me, i'm really NOT interested in knowing what langage is good for go programming. That's simply not a question i can ask myself, nor anyone else. This question doesn't make any sense for me. Still if someone can get the standard light playout right in less than 10 code line, and they are very understandable lines. I would be very happy to see it. But it would never mean for me that, this language is BEST. Even if the peformances are optimal there. I think 90% of the this language is the best debate gets it's root in some affective part of the people engaged with it. As someone interested in programming languages, I cannot resist to comment. True, language advocacy tends to be boring at best, and -in its extreme forms- tends to be pursued not by the language designers themselves. If they have any experience at all, they are quite willing to let their language speak for itself, and quite open-minded, both toward other languages having good points and toward their own language having weak points. Converts turned evangelists are often as embarrassing to their community as they are to their target audience. You might get a little more out of the question if you change your perspective a little: ask what language is good for Go programming? not with a view on what general- or specific-purpose languages are out there, but with a view on how you would like to express your thoughts about Go. In this particular case, representations seem to play a fundamental role: I didn't want to think about details or optimizations too early, but I found it impossible to think about the algorithms without choosing suitable data representations (too many details to keep in mind if the representations were unsuitable); once I got the right representations, the algorithms were straightforward, and whenever added algorithms started to get complicated, it indicated a need to switch to a better representation. So, once you've got your representations (sets/bitmaps, arrays/hashtables, etc.) implemented in libraries, the programming language itself may not matter much any more (recursion simplifies things, but whether one recursively collects sets of liberties in imperative, functional, logic, or object-oriented code may not make much difference - even assembler might be manageable, given such libraries, just that it might doom your code when you move to a different machine in future). But in thinking about a consistent set of representations suitable for Go programming, you're effectively deciding on a language to use when talking about Go programming issues. Being aware of this, the question what language is good for Go programming? may turn out to be a little more useful and interesting. An unsuitable answer results in complicated code, which is hard to think about and even harder to get correct; a suitable answer results in simple code, which can then be embedded into many of the popular general purpose languages. Claus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Oct 10, 2008, at 2:10 PM, Stuart A. Yeates wrote: On Sat, Oct 11, 2008 at 10:05 AM, terry mcintyre [EMAIL PROTECTED] wrote: I like the idea of a contest to determine the best ways to implement a particular problem ( generating light playouts ) in various languages. The Language Shootout is probably not the best forum, since they require the same algorithm, which defeats the purpose of comparing languages which tend to do different things well by design; a good programmer/advocate would play to the strengths of each language. The Language shootout has a class of contests which do not require the same algorithm, i.e. http://shootout.alioth.debian.org/u32q/benchmark.php? test=meteorlang=all cheers stuart The Alioth site is centrally administrated, so the bureaucracy to add a task is formidable. On the other hand, they've just added a multicore test platform and already have a performance measuring framework. Might I suggest again the Rosetta Code wiki at http:// www.rosettacode.org/? Anyone can contribute at any time, since it's uses MediaWiki, like Wikipedia. They have active participants for many compiled languages, and have just been discussing adding a game category. I would especially like to see what the J and Haskell folks make of this task. For a larger project like this, they recommend making a single task page with a sub page for each language (like RCBF). Ian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Oct 9, 2008, at 10:39 PM, Don Dailey wrote: On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote: Computers + random = can of worms. What if I get a fast benchmark by implementing the fastest, most awful, random number generator imaginable? What if every one of my random playouts looks the disturbingly similar? As to the relevance, the time-eaters in my heavy playouts are different from the time-eaters in my light playouts. This is true, but it goes back to the well understood fact that you cannot have a perfect benchmark. I think this would be very useful and very relevant, just not perfect. Random numbers IS an issue. I required transparency so that any issue like this can be observed, reviewed, criticized, etc. However, there is a solution. I don't think this solution is necessary, but it is possible: George Marsaglia published a set of very high quality random number generators that can be implemented with just a couple of lines of code. We could specify that a specific random number generator be used. After all, this is only a benchmark. But these are fast generators. The final step, which I don't personally support because I think it's too restrictive but is also possible is to require these programs to be deterministic.So you could SPECIFY the exact starting seed for a random number generator as well as the specific method (or equivalent) to be used to select moves randomly. I don't really like that idea, but it makes it possible to perfectly verify the implementations. I don't like it simply because it places additional constraints on creativity and flexibility. You might come up with a very clever and fast way to generate uniformly random moves for instance that doesn't work within the framework. Or you may want to benchmark some language that doesn't like 32 bit data types (perhaps 31 bit types for instance.) A lack of flexibility here would unduly punish you. So I'm happy to allow some leeway at the expense of perfect verification as long as we have transparency, anybody who wants can see the code and criticize it or find flaws. (His implementation is FAST, but he cheated a little on the random numbers.) It's also pretty easy to not pick moves uniformly random - I think some on this group may have made that mistake. This should show up if we have good benchmarks. Someone will notice something slightly off in the statistics reported and it will be examined or seen to be flawed. hi, i hate usually replies to my post that zoom in into 1 tiny detail, apologies for doing that. However i'd like to zoom in on the uniformity of RNG's. Of course we all do effort to get uniform RNG's. In fact the net is overloaded with them. Years ago i googled and i stumbled upon ranrot from Agner Fog. http://www.agner.org/random/theory/ Like all fibonacci based RNG's it's completely uniform spreaded. Now THAT has a few problems. When i did do some work a year or 8 ago for a guy called Avery Cardoza, he released a game called Casino2000. Obviously it also has roulette also. Now if we take the European roulette version that has a single zero (US casino's have 2 zero's, a 0 and 00, which makes odds quite bigger for casino), there is on paper 1 strategy that might deliver money. Might, because playing with a system is forbidden of course. On paper there is 1 system that wins. You put 1 fiche, then if you lose that bet you double, if you lose again you double again. So you bet 1,2,4,8,16,32,64,128,256,512,1000 Hah, why 1000? Because usually you won't get further than doubling 10 times. Each table has a max bet. So let's limit the number of bets to 8. 7 doublings in short. Not a single RNG that is considered to be 'good' and 'well'. Yes not even Mersenne twister, is *approaching* reality there that happens in casino's. Now i do not mean the 'bad' casino's, but simply that the profit you make on paper is a lot higher than in reality (other than that they'll kick you out of the casino). The freakin nature of all those bitflippers is such that i'm *assuming* nowadays in some algorithms that they can produce a field for me in O ( n log n ). So not only they are too uniform, they also can produce an entire field, covering every element in O ( n log n), without a single failure. Now THAT'S interesting :) - Don - Dave Hillis -Original Message- From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thu, 9 Oct 2008 2:44 pm Subject: Re: [computer-go] programming languages On Thu, 2008-10-09 at 14:17 -0400, [EMAIL PROTECTED] wrote: The http://shootout.alioth.debian.org/ site, ... If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. Many potential ways to speed up light playouts involve
Re: [computer-go] programming languages
Sure,
A lot faster is ranrot in 64 bits, at K8 2.2ghz with old GCC it is
about 3.3 ns for each number,
so i assume it's quite a tad faster than that for core2. Note it's
quite slow at itanium,
about 9-10 nanoseconds a number, as it appeared later itanium has no
rotate hardware instructions :)
Here is how i rewrote it:
/* define parameters (R1 and R2 must be smaller than the integer
size): */
#define KK 17
#define JJ 10
#define R1 5
#define R2 3
#define BITBOARD (unsigned long long)
/* global variables Ranrot */
BITBOARD randbuffer[KK+3] = { /* history buffer filled with some
random numbers */
0x92930cb295f24dab,
0x0d2f2c860b685215,0x4ef7b8f8e76ccae7,0x03519154af3ec239,0x195e36fe715fa
d23,
0x86f2729c24a590ad,0x9ff2414a69e4b5ef,
0x631205a6bf456141,0x6de386f196bc1b7b,0x5db2d651a7bdf825,
0x0d2f2c86c1de75b7,0x5f72ed908858a9c9,0xfb2629812da87693,0xf3088fedb657f
9dd,0x00d47d10ffdc8a9f,
0xd9e323088121da71,0x801600328b823ecb,
0x93c300e4885d05f5,0x096d1f3b4e20cd47,0x43d64ed75a9ad5d9
/*0xa05a7755512c0c03,0x960880d9ea857ccd,0x7d9c520a4cc1d30f,
0x73b1eb7d8891a8a1,0x116e3fc3a6b7aadb*/
};
int r_p1, r_p2; /* indexes into history buffer */
/ AgF
1999-03-03 *
* Random Number generator 'RANROT' type
B *
* by Agner
Fog *
*
*
* This is a lagged-Fibonacci type of random number generator
with *
* rotation of bits. The algorithm
is: *
* X[n] = ((X[n-j] rotl r1) + (X[n-k] rotl r2)) modulo
2^b *
*
*
* The last k values of X are stored in a circular buffer
named *
*
randbuffer. *
*
*
* This version works with any integer size: 16, 32, 64 bits
etc.*
* The integers must be unsigned. The resolution depends on the
integer *
*
size. *
*
*
* Note that the function RanrotAInit must be called before the
first*
* call to RanrotA or
iRanrotA *
*
*
* The theory of the RANROT type of generators is described
at *
* www.agner.org/random/
ranrot.htm *
*
*
*/
FORCEINLINE BITBOARD rotl(BITBOARD x,int r) {return(xr)|(x(64-r));}
/* returns a random number of 64 bits unsigned */
FORCEINLINE BITBOARD RanrotA(void) {
/* generate next random number */
BITBOARD x = randbuffer[r_p1] = rotl(randbuffer[r_p2],R1) + rotl
(randbuffer[r_p1], R2);
/* rotate list pointers */
if( --r_p1 0)
r_p1 = KK - 1;
if( --r_p2 0 )
r_p2 = KK - 1;
return x;
}
/* this function initializes the random number generator. */
void RanrotAInit(void) {
int i;
/* one can fill the randbuffer here with possible other values
here */
randbuffer[0] = 0x92930cb295f24000 | (BITBOARD)ProcessNumber;
randbuffer[1] = 0x0d2f2c860b000215 | ((BITBOARD)ProcessNumber12);
/* initialize pointers to circular buffer */
r_p1 = 0;
r_p2 = JJ;
/* randomize */
for( i = 0; i 300; i++ )
(void)RanrotA();
}
Please note there is faster RNG's than ranrot, with some shifting
here and there.
But maybe ranrot is what is sufficient. You won't search enough nodes
coming 10
years to get in trouble with it :)
Note that the parameter 'processnumber' is the process number of each
process (or thread)
of search. Safely works up to 4096 cores :)
On Oct 10, 2008, at 12:36 AM, Don Dailey wrote:
On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote:
Computers + random = can of worms.
Has anyone seen this:
http://home.southernct.edu/~pasqualonia1/ca/report.html#files
They are claiming impressive speed and high quality for a random
number
generator. The code is compact and small, much nicer than mt19937
and
the speed seems to blow mt19937 out of the water.
I haven't looked at any papers on this and I'm wondering how good
it is.
Here is quote:
The cellular automaton outperforms the GSL random number
generators, being more than three times as fast as the GSL
generators.
The following table shows the mean time for 10 runs of each
generator, with each run producing 10 million integers. Source
code for both the GSL generators and the cellular
Re: [computer-go] programming languages
The http://shootout.alioth.debian.org/ site, ... If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. This is an excellent idea. Go for it! I suspect that detailing the algorithm sufficiently for non-go players to implement may be surprising challenging. I think as long as you supply a reference C (or C++ or java) implementation it is okay. You cannot beat working code for a tech spec :-). My concern is that to include all the rules of go, including capture logic, you need a few hundred lines of code, which might put some people off. Perhaps some game with similar game tree properties but less complex logic would be a better choice. (I'm wondering about Amazons?) Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Thu, 2008-10-09 at 19:05 +0900, Darren Cook wrote: The http://shootout.alioth.debian.org/ site, ... If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. This is an excellent idea. Go for it! I suspect that detailing the algorithm sufficiently for non-go players to implement may be surprising challenging. I think as long as you supply a reference C (or C++ or java) implementation it is okay. You cannot beat working code for a tech spec :-). My concern is that to include all the rules of go, including capture logic, you need a few hundred lines of code, which might put some people off. You can code up a basic MC player in less than a day. I don't think non-go programmers are very likely to provide an implementation anyway but they are free to. We can provide support for anyone that wants to and we can advertise this. A real simple reference implementation should be provided. It should not be written to be fast, but real clear and easy to understand at a glance and well commented. - Don Perhaps some game with similar game tree properties but less complex logic would be a better choice. (I'm wondering about Amazons?) Darren signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
The topic of which programming language to use has been raised innumerable times in the 5 years I've been on this list and I've been backward about coming forward with an opinion because the conversation seems to generate great deals of heat without much light. The http://shootout.alioth.debian.org/ site, however, has lead me to an interesting idea. The site itself is a set of fully described algorithms, implementations of the algorithms and a test and reporting harness. If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. I suspect that detailing the algorithm sufficiently for non-go players to implement may be surprising challenging. cheers stuart On Thu, Oct 9, 2008 at 12:12 PM, Darren Cook [EMAIL PROTECTED] wrote: ATS does the binary-trees test 6.2 times quicker than C++ but 2.7 times slower on k-nucleotide (which seems to be about making hash tables): Prompted by Isaac, I found the single-core benchmarks (change the u64q to u32 in the URLs I posted before to get them, or start at http://shootout.alioth.debian.org/u32/ ), ATS does binary trees 1.9 times quicker, and k-nucleotide 1.4 times slower. Darren http://shootout.alioth.debian.org/u64q/benchmark.php?test=alllang=atslang2=gpp http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotidelang=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotidelang=gppid=1 -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
I have considered the very same thing and I think it's a great idea! In fact I implemented the same exact algorithm for a simple go program in C and D for the exact purpose of evaluating D. I even used the same data representation and algorithms for doing things so that it was mostly apples to apples. I think it's easy to describe and code up a simple algorithm. Uniform random play-outs. For the purpose of the benchmark we could avoid using AMAF or else we would have to make sure it was carefully specified. We could specify the simple eye rule that almost all of us use and make sure all of these things are precisely defined. And then we would need a simple test harness to verify that the program was correct. We could do things like measure the average game length and average win percentage in one or more specified positions. We could create a couple extra GTP commands for reporting these numbers. And we could specify that the programs are ready to play complete games so that they could be tested in real games. But I would suggest that this is not just a language contest, but a programming context too. We should not have just one implementation per language but users would be free to submit their own entry for any language because no two implementations would be the same. The only rule is that it must conform and pass the specified tests and the source code is published with each entry for external verification. Users would be free to take an existing entry, improve it, and then resubmit a new entry based on it.In this way we can probably be more likely to get good implementations represented for each language. We have to make sure we have the details exactly correct. Do we detect ko in the play-outs? Superko or just simple ko? Stuff like that. If we did it language shootout style, we would have to post the source code. And have some rules, such as no assembly modules, etc. - Don On Thu, 2008-10-09 at 22:15 +1300, Stuart A. Yeates wrote: The topic of which programming language to use has been raised innumerable times in the 5 years I've been on this list and I've been backward about coming forward with an opinion because the conversation seems to generate great deals of heat without much light. The http://shootout.alioth.debian.org/ site, however, has lead me to an interesting idea. The site itself is a set of fully described algorithms, implementations of the algorithms and a test and reporting harness. If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. I suspect that detailing the algorithm sufficiently for non-go players to implement may be surprising challenging. cheers stuart On Thu, Oct 9, 2008 at 12:12 PM, Darren Cook [EMAIL PROTECTED] wrote: ATS does the binary-trees test 6.2 times quicker than C++ but 2.7 times slower on k-nucleotide (which seems to be about making hash tables): Prompted by Isaac, I found the single-core benchmarks (change the u64q to u32 in the URLs I posted before to get them, or start at http://shootout.alioth.debian.org/u32/ ), ATS does binary trees 1.9 times quicker, and k-nucleotide 1.4 times slower. Darren http://shootout.alioth.debian.org/u64q/benchmark.php?test=all〈=atslang2=gpp http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotide〈=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotide〈=gppid=1 -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Oct 9, 2008, at 5:52 AM, Don Dailey wrote: On Thu, 2008-10-09 at 19:05 +0900, Darren Cook wrote: The http://shootout.alioth.debian.org/ site, ... If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. This is an excellent idea. Go for it! I suspect that detailing the algorithm sufficiently for non-go players to implement may be surprising challenging. I think as long as you supply a reference C (or C++ or java) implementation it is okay. You cannot beat working code for a tech spec :-). My concern is that to include all the rules of go, including capture logic, you need a few hundred lines of code, which might put some people off. You can code up a basic MC player in less than a day. I don't think non-go programmers are very likely to provide an implementation anyway but they are free to. We can provide support for anyone that wants to and we can advertise this. A real simple reference implementation should be provided. It should not be written to be fast, but real clear and easy to understand at a glance and well commented. - Don Rosetta Code (http://www.rosettacode.org/) would welcome this kind of language comparison task. Ian ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Thu, Oct 9, 2008 at 5:05 AM, Darren Cook [EMAIL PROTECTED] wrote: My concern is that to include all the rules of go, including capture logic, you need a few hundred lines of code... [snip] Don't be so sure... ;) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
Zach Wegner wrote: On Thu, Oct 9, 2008 at 5:05 AM, Darren Cook [EMAIL PROTECTED] wrote: My concern is that to include all the rules of go, including capture logic, you need a few hundred lines of code... [snip] Don't be so sure... ;) Or use Perl. ;) On a more serious note, a while back I wrote some sample code for the few hundred lines of code required for the basic rules. It was part of a Computer Go wikibook project that I haven't touched since getting that basic part done, but hopefully it has enough information that anybody could code up the basic rules in any language very simply: http://en.wikibooks.org/wiki/Computer_Go/Writing_a_Go_Engine The next part of my project was going to be writing a random bot that just played random, legal moves. Extending this to use random playout would be even more interesting, and could provide enough information for people to easily code up the algorithm in whatever language they chose. If anyone is interested in collaborating on this sort of project, please feel free to let me know. ~ Ross ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
The http://shootout.alioth.debian.org/ site, ...? ? If we, as a community, could come up with a sufficiently detailed? description of light playouts algorithm (see the current Light? simulation : Characteristic values thread), there is no reason that? this algorithm couldn't join them.? Many potential ways to speed up light playouts involve taking some liberties regarding the uniform distribution of moves. Specifying and verifying the rules here, looks messy to me. Also, light playouts are more of an intermediate step than an end goal for engines. Is making them faster all that relevent anymore? - Dave Hillis ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Thu, 2008-10-09 at 14:17 -0400, [EMAIL PROTECTED] wrote: The http://shootout.alioth.debian.org/ site, ... If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. Many potential ways to speed up light playouts involve taking some liberties regarding the uniform distribution of moves. Specifying and verifying the rules here, looks messy to me. Also, light playouts are more of an intermediate step than an end goal for engines. Is making them faster all that relevent anymore? I think you're missing the point. This would be nothing more than just a benchmark. You would be free to implemented it any way you like as long as it conforms to the general guidelines, so all programs should be equivalent. However one program might use a totally different board representation than another. Specifying the rules is probably not too hard but verifying them would be trickier. The simplest way to verify is: 1. benchmarks that provide strong empirical evidence. 2. Source code is available for all to inspect. I agree that this is far from the best way to implement a program but it would really be useful as a benchmark for board games. I would trust the results of this shootout way beyond the computer language shootout. This is because it's an actual program that should also be able to play a real game. John Tromp did something along the same lines with connect-4. He had a java and C implementation that were equivalent in output. I actually didn't trust his benchmark because he wrote C code generic and simple, not like a high performance guru would write C code.I can't really be too critical unless I actually were to try to improve on the C version. To me the advantage of C is that you can write code that you wouldn't write in Java. There is very little advantage of C over Java otherwise. If you start with the best Java program you can and then port it to C as faithfully as possible, you get a different result than if you take the best possible C program you can write and try to port it to Java. For each language, you would probably write fast code differently. I think the right way to do John's benchmark is to get each language zealot in competition with each other. Let the C programmer prove he can do it much faster. And the Java programmer can respond if he wants to. - Don - Dave Hillis __ McCain or Obama? Stay updated on coverage of the Presidential race while you browse - Download Now! ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Thu, 2008-10-09 at 14:44 -0400, Don Dailey wrote: I agree that this is far from the best way to implement a program but it would really be useful as a benchmark for board games. I would trust the results of this shootout way beyond the computer language shootout. This is because it's an actual program that should also be able to play a real game. Let me clarify. What I meant is that I would trust this for the kind of programs I'm interested in, high performance board game programs like Chess and Go. - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
Computers + random = can of worms. What if I get a fast benchmark by implementing the fastest, most awful, random number generator imaginable? What if every one of my random playouts looks the disturbingly similar? As to the relevance, the time-eaters in my heavy playouts are different from the time-eaters in my light playouts. - Dave Hillis -Original Message- From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thu, 9 Oct 2008 2:44 pm Subject: Re: [computer-go] programming languages On Thu, 2008-10-09 at 14:17 -0400, [EMAIL PROTECTED] wrote: The http://shootout.alioth.debian.org/ site, ... If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. Many potential ways to speed up light playouts involve taking some liberties regarding the uniform distribution of moves. Specifying and verifying the rules here, looks messy to me. Also, light playouts are more of an intermediate step than an end goal for engines. Is making them faster all that relevent anymore? I think you're missing the point. This would be nothing more than just a benchmark. You would be free to implemented it any way you like as long as it conforms to the general guidelines, so all programs should be equivalent. However one program might use a totally different board representation than another. Specifying the rules is probably not too hard but verifying them would be trickier. The simplest way to verify is: 1. benchmarks that provide strong empirical evidence. 2. Source code is available for all to inspect. I agree that this is far from the best way to implement a program but it would really be useful as a benchmark for board games. I would trust the results of this shootout way beyond the computer language shootout. This is because it's an actual program that should also be able to play a real game. John Tromp did something along the same lines with connect-4. He had a java and C implementation that were equivalent in output. I actually didn't trust his benchmark because he wrote C code generic and simple, not like a high performance guru would write C code.I can't really be too critical unless I actually were to try to improve on the C version. To me the advantage of C is that you can write code that you wouldn't write in Java. There is very littl e advantage of C over Java otherwise. If you start with the best Java program you can and then port it to C as faithfully as possible, you get a different result than if you take the best possible C program you can write and try to port it to Java. For each language, you would probably write fast code differently. I think the right way to do John's benchmark is to get each language zealot in competition with each other. Let the C programmer prove he can do it much faster. And the Java programmer can respond if he wants to. - Don - Dave Hillis __ McCain or Obama? Stay updated on coverage of the Presidential race while you browse - Download Now! ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
--- Don Dailey [EMAIL PROTECTED] wrote: -snip- I think the right way to do John's benchmark is to get each language zealot in competition with each other. Let the C programmer prove he can do it much faster. And the Java programmer can respond if he wants to. At which point we would have /a contest between individuals/ and we should suspect the results would depend quite strongly on how much time those individuals choose to waste on the contest. The benchmarks game does show /a contest/ http://shootout.alioth.debian.org/u32/benchmark.php?test=meteorlang=all ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote: Computers + random = can of worms. What if I get a fast benchmark by implementing the fastest, most awful, random number generator imaginable? What if every one of my random playouts looks the disturbingly similar? As to the relevance, the time-eaters in my heavy playouts are different from the time-eaters in my light playouts. This is true, but it goes back to the well understood fact that you cannot have a perfect benchmark. I think this would be very useful and very relevant, just not perfect. Random numbers IS an issue. I required transparency so that any issue like this can be observed, reviewed, criticized, etc. However, there is a solution. I don't think this solution is necessary, but it is possible: George Marsaglia published a set of very high quality random number generators that can be implemented with just a couple of lines of code. We could specify that a specific random number generator be used. After all, this is only a benchmark. But these are fast generators. The final step, which I don't personally support because I think it's too restrictive but is also possible is to require these programs to be deterministic.So you could SPECIFY the exact starting seed for a random number generator as well as the specific method (or equivalent) to be used to select moves randomly. I don't really like that idea, but it makes it possible to perfectly verify the implementations. I don't like it simply because it places additional constraints on creativity and flexibility. You might come up with a very clever and fast way to generate uniformly random moves for instance that doesn't work within the framework. Or you may want to benchmark some language that doesn't like 32 bit data types (perhaps 31 bit types for instance.) A lack of flexibility here would unduly punish you. So I'm happy to allow some leeway at the expense of perfect verification as long as we have transparency, anybody who wants can see the code and criticize it or find flaws. (His implementation is FAST, but he cheated a little on the random numbers.) It's also pretty easy to not pick moves uniformly random - I think some on this group may have made that mistake. This should show up if we have good benchmarks. Someone will notice something slightly off in the statistics reported and it will be examined or seen to be flawed. - Don - Dave Hillis -Original Message- From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thu, 9 Oct 2008 2:44 pm Subject: Re: [computer-go] programming languages On Thu, 2008-10-09 at 14:17 -0400, [EMAIL PROTECTED] wrote: The http://shootout.alioth.debian.org/ site, ... If we, as a community, could come up with a sufficiently detailed description of light playouts algorithm (see the current Light simulation : Characteristic values thread), there is no reason that this algorithm couldn't join them. Many potential ways to speed up light playouts involve taking some liberties regarding the uniform distribution of moves. Specifying and verifying the rules here, looks messy to me. Also, light playouts are more of an intermediate step than an end goal for engines. Is making them faster all that relevent anymore? I think you're missing the point. This would be nothing more than just a benchmark. You would be free to implemented it any way you like as long as it conforms to the general guidelines, so all programs should be equivalent. However one program might use a totally different board representation than another. Specifying the rules is probably not too hard but verifying them would be trickier. The simplest way to verify is: 1. benchmarks that provide strong empirical evidence. 2. Source code is available for all to inspect. I agree that this is far from the best way to implement a program but it would really be useful as a benchmark for board games. I would trust the results of this shootout way beyond the computer language shootout. This is because it's an actual program that should also be able to play a real game. John Tromp did something along the same lines with connect-4. He had a java and C implementation that were equivalent in output. I actually didn't trust his benchmark because he wrote C code generic and simple, not like a high performance guru would write C code.I can't really be too critical unless I actually were to try to improve on the C version. To me the advantage of C is that you can write code that you wouldn't write in Java. There is very little advantage of C over Java otherwise. If you start with the best Java program you can and then port it to C as faithfully as possible, you get a different result than if you take the best possible C program you can write and try to port it to Java. For each language, you
Re: [computer-go] programming languages
On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote: Computers + random = can of worms. Has anyone seen this: http://home.southernct.edu/~pasqualonia1/ca/report.html#files They are claiming impressive speed and high quality for a random number generator. The code is compact and small, much nicer than mt19937 and the speed seems to blow mt19937 out of the water. I haven't looked at any papers on this and I'm wondering how good it is. Here is quote: The cellular automaton outperforms the GSL random number generators, being more than three times as fast as the GSL generators. The following table shows the mean time for 10 runs of each generator, with each run producing 10 million integers. Source code for both the GSL generators and the cellular automaton was compiled using GCC version 4.1.0 with the -O2 optimization flag. RNG: Mean time to produce 10 million integers: cellular automaton0.062000 seconds gsl_rng_taus 0.20 seconds gsl_rng_gfsr4 0.20 seconds gsl_rng_mt19937 0.223000 seconds gsl_rng_ranlxd1 2.652000 seconds - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
If there is a catch, it might be this: Although the Diehard test results are a strong indication of randomness, it remains to be proved that the cellular automaton has a period of adequate length. Proofs regarding the period and other characteristics of cellular automata have been demonstrated in previous research; see for example [4] and [5]. Proof and analysis of this particular automaton's characteristics is a task for future research. - Don On Thu, 2008-10-09 at 18:36 -0400, Don Dailey wrote: On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote: Computers + random = can of worms. Has anyone seen this: http://home.southernct.edu/~pasqualonia1/ca/report.html#files They are claiming impressive speed and high quality for a random number generator. The code is compact and small, much nicer than mt19937 and the speed seems to blow mt19937 out of the water. I haven't looked at any papers on this and I'm wondering how good it is. Here is quote: The cellular automaton outperforms the GSL random number generators, being more than three times as fast as the GSL generators. The following table shows the mean time for 10 runs of each generator, with each run producing 10 million integers. Source code for both the GSL generators and the cellular automaton was compiled using GCC version 4.1.0 with the -O2 optimization flag. RNG: Mean time to produce 10 million integers: cellular automaton0.062000 seconds gsl_rng_taus 0.20 seconds gsl_rng_gfsr4 0.20 seconds gsl_rng_mt19937 0.223000 seconds gsl_rng_ranlxd1 2.652000 seconds - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
--- Don Dailey [EMAIL PROTECTED] wrote: On Thu, 2008-10-09 at 13:04 -0700, Isaac Gouy wrote: --- Don Dailey [EMAIL PROTECTED] wrote: -snip- I think the right way to do John's benchmark is to get each language zealot in competition with each other. Let the C programmer prove he can do it much faster. And the Java programmer can respond if he wants to. At which point we would have /a contest between individuals/ and we should suspect the results would depend quite strongly on how much time those individuals choose to waste on the contest. Exactly. That is what I propose, not just a contest between language implementation but between language advocates. The shootout works that way anyway, people constantly tweaking their language or their implementation. No, the benchmarks game does not work that way. FAQ http://shootout.alioth.debian.org/u32q/faq.php#contest I don't see anything more fair than that. There is no way to really get a perfect comparison because there are too many variables not to mention which platform and OS you are on and how you set compiler options, which language implementation, etc. So it seems best to me to let each language advocate go to bat for his language of choice - a kind of put up or shut up contest. You can claim your language is better but you also get every chance to back it up with real numbers. - Don The benchmarks game does show /a contest/ http://shootout.alioth.debian.org/u32/benchmark.php?test=meteorâ©=all ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On 9-okt-08, at 17:39, Don Dailey wrote: On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote: Computers + random = can of worms. What if I get a fast benchmark by implementing the fastest, most awful, random number generator imaginable? What if every one of my random playouts looks the disturbingly similar? As to the relevance, the time-eaters in my heavy playouts are different from the time-eaters in my light playouts. This is true, but it goes back to the well understood fact that you cannot have a perfect benchmark. I think this would be very useful and very relevant, just not perfect. Random numbers IS an issue. I required transparency so that any issue like this can be observed, reviewed, criticized, etc. Random numbers may just be one of the issues. There could be other tricks that speed things up but deteriorate play in a way that's hard to detect. What could be an interesting way to tackle is to have a robot player that plays a fixed number of playouts according to a known algorithm. As benchmark you can use the computing time another algorithm (or language) needs to attain a 50% score against it. But it may be a bit too academic to actually realize a benchmark like this. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
SIMD version of SFMT is 3 to 7 time faster than MT. See http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/speed.html for detail. Hideki Don Dailey: [EMAIL PROTECTED]: On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote: Computers + random = can of worms. Has anyone seen this: http://home.southernct.edu/~pasqualonia1/ca/report.html#files They are claiming impressive speed and high quality for a random number generator. The code is compact and small, much nicer than mt19937 and the speed seems to blow mt19937 out of the water. I haven't looked at any papers on this and I'm wondering how good it is. Here is quote: The cellular automaton outperforms the GSL random number generators, being more than three times as fast as the GSL generators. The following table shows the mean time for 10 runs of each generator, with each run producing 10 million integers. Source code for both the GSL generators and the cellular automaton was compiled using GCC version 4.1.0 with the -O2 optimization flag. RNG: Mean time to produce 10 million integers: cellular automaton0.062000 seconds gsl_rng_taus 0.20 seconds gsl_rng_gfsr4 0.20 seconds gsl_rng_mt19937 0.223000 seconds gsl_rng_ranlxd1 2.652000 seconds - Don inline file ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
It's impressive, but I'm always interested in a general purpose algorithm that is fast, can be used on any processor, any language without pain and agony. - Don On Fri, 2008-10-10 at 07:28 +0800, Hideki Kato wrote: SIMD version of SFMT is 3 to 7 time faster than MT. See http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/speed.html for detail. Hideki Don Dailey: [EMAIL PROTECTED]: On Thu, 2008-10-09 at 15:20 -0400, [EMAIL PROTECTED] wrote: Computers + random = can of worms. Has anyone seen this: http://home.southernct.edu/~pasqualonia1/ca/report.html#files They are claiming impressive speed and high quality for a random number generator. The code is compact and small, much nicer than mt19937 and the speed seems to blow mt19937 out of the water. I haven't looked at any papers on this and I'm wondering how good it is. Here is quote: The cellular automaton outperforms the GSL random number generators, being more than three times as fast as the GSL generators. The following table shows the mean time for 10 runs of each generator, with each run producing 10 million integers. Source code for both the GSL generators and the cellular automaton was compiled using GCC version 4.1.0 with the -O2 optimization flag. RNG: Mean time to produce 10 million integers: cellular automaton0.062000 seconds gsl_rng_taus 0.20 seconds gsl_rng_gfsr4 0.20 seconds gsl_rng_mt19937 0.223000 seconds gsl_rng_ranlxd1 2.652000 seconds - Don inline file ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- [EMAIL PROTECTED] (Kato) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
--- Don Dailey [EMAIL PROTECTED] wrote: On Thu, 2008-10-09 at 15:47 -0700, Isaac Gouy wrote: Exactly. That is what I propose, not just a contest between language implementation but between language advocates. The shootout works that way anyway, people constantly tweaking their language or their implementation. No, the benchmarks game does not work that way. FAQ http://shootout.alioth.debian.org/u32q/faq.php#contest Are you referring to the requirement that that same algorithm be used? Yes. I think what I would personally like to see is as much leeway as possible so that you can explore the full potential of your language, which to me is much more fair that specifying EXACTLY how each line of code should be written. I would personally like to see you stop spreading misinformation about the benchmarks game. You were wrong about there being no single processor comparison. You were wrong about it being the kind of contest you describe. You are wrong to imply it specifies exactly how each line of code should be written. So I think it's fair to simply specify what is required to be functionally identical to a reference implementation. You can even cheat if you can figure out how to. To be sure, you would have to be able to pass a stringent battery of tests. If it cannot be proved that your black box is different from the reference black box, then your implementation is legal. We have noticed that even minor eye rule changes are easily detected by the output statistics. Of course the source code is always available and others can steal any good ideas. Also, if someone finds a clever cheat it should be possible to create a test to reveal it. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
From: Don Dailey [EMAIL PROTECTED] It's impressive, but I'm always interested in a general purpose algorithm that is fast, can be used on any processor, any language without pain and agony. All good things to hope for, but languages vary enough that some things must be expressed differently than in other languages; and some features of modern processors are not exposed by most languages; for speed-critical inner loops, as random number generation in very lightweight playout loops might be, hand-crafted assembler may be the best way to go. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On 7-okt-08, at 21:40, Don Dailey wrote: On Wed, 2008-10-08 at 08:25 +0900, Darren Cook wrote: And now I look at the ATS implementation of binary-trees, it is using threads, while the C++ version is single-threaded. Lots of apples and oranges comparisons here :-). And there is no single processor comparison number.I wonder why they don't do a Pentium 4 version just to eliminate that from consideration? That's because those people advocating a certain language always have a vested interest in it looking faster than something else. So they distort the truth as much as a politician running for president. There are a lot of factors involved that make a programming language suitable for particular tasks. I think it's very possible that I'd not recognise the best programming language for Go if it's staring me in the face, simply because I wouldn't be able to see the paradigm- shift necessary to make full use of the new language. In the past, the more expressive languages like Lisp and Prolog have always turned out too slow. So what most languages are now settling for is a language with C-like performance but with OO capabilities. What could make a difference is good support for parallel and distributed programming. But a lot of that can be handled by libraries. C# and Java have some nice native constructs to make parallel programming a little easier, but I don't think it's a game- changer. Who knows we'll see something revolutionary appear yet. Something like Prolog with automatic scalability over multiple processors. Who knows, when processors really start to come in the hundreds or thousands in a single PC. Then we might need something that moves away from the serial statement type languages with functions, if-then- else and loops . Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
ATS does the binary-trees test 6.2 times quicker than C++ but 2.7 times slower on k-nucleotide (which seems to be about making hash tables): Prompted by Isaac, I found the single-core benchmarks (change the u64q to u32 in the URLs I posted before to get them, or start at http://shootout.alioth.debian.org/u32/ ), ATS does binary trees 1.9 times quicker, and k-nucleotide 1.4 times slower. Darren http://shootout.alioth.debian.org/u64q/benchmark.php?test=alllang=atslang2=gpp http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotidelang=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotidelang=gppid=1 -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
What do you mean by appeared? When were the languages inteoduced? Is the speed and memory stuff just a claim? Or are there real benchmarks? Sent from my iPhone On Oct 7, 2008, at 2:38 PM, Don Dailey [EMAIL PROTECTED] wrote: I have noticed there are 3 more languages that have appeared that seem to promise the speed and memory benefits of C and yet are higher level languages: Has anyone looked at lisaac, Vala, or Genie? Lisaac is claimed to be just as fast as C and was designed to be used to write operating systems just like C was. It looks extremely interesting but there appears to be little or no activity with it for quite a while. Vala is a C#/Java type of language that compiles to C code and also is claimed to give the advantages of C#/Java but the low level speed and control of C.You can compile stand-alone executable programs with it, unlike most other interesting languages. Genie is a brother to Vala and looks more like a static Python. The web page blurb goes like this: The syntax of Genie is designed to be clean, clear and concise. In some ways its cleaner than Python and is certainly a lot more concise than C#/Java. Genie of course has all the advantages of Vala and you can seamlessly use Vala code and bindings with it too just like a CLR. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
I've found some general benchmarks for Vala here. http://code.google.com/p/vala-benchmarks/wiki/BenchResults --josh On Tue, Oct 7, 2008 at 3:38 PM, Don Dailey [EMAIL PROTECTED] wrote: On Tue, 2008-10-07 at 14:52 -0400, Jason House wrote: What do you mean by appeared? When were the languages inteoduced? Is the speed and memory stuff just a claim? Or are there real benchmarks? They are relatively new language. When I say appeared I mean that I never noticed them until recently.Even languages we think are new usually took at least a year or two to reach some usable version level. Lisaac has numbers appearing in the language shootout that are extremely impressive. Vala is statically typed and based on gnome. It translates to C code but of course that doesn't guarantee that it will be fast. I don't have numbers on Vala but it would be simple to make up your own test. - Don Sent from my iPhone On Oct 7, 2008, at 2:38 PM, Don Dailey [EMAIL PROTECTED] wrote: I have noticed there are 3 more languages that have appeared that seem to promise the speed and memory benefits of C and yet are higher level languages: Has anyone looked at lisaac, Vala, or Genie? Lisaac is claimed to be just as fast as C and was designed to be used to write operating systems just like C was. It looks extremely interesting but there appears to be little or no activity with it for quite a while. Vala is a C#/Java type of language that compiles to C code and also is claimed to give the advantages of C#/Java but the low level speed and control of C.You can compile stand-alone executable programs with it, unlike most other interesting languages. Genie is a brother to Vala and looks more like a static Python. The web page blurb goes like this: The syntax of Genie is designed to be clean, clear and concise. In some ways its cleaner than Python and is certainly a lot more concise than C#/Java. Genie of course has all the advantages of Vala and you can seamlessly use Vala code and bindings with it too just like a CLR. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Tue, 2008-10-07 at 21:25 +0200, Vincent Diepeveen wrote: hi Don, what's the advantage of lisaac over c++? If it's just as fast as C (or within a few percent) and it's a higher level language, you can write a stronger program because you can try things faster and experiment more easily. I don't really know if it has those things - but I'm interested to keep my eyes open. Vala claims need to get substantiated, to be honest if we look to c++ compilers from a year or 10+ ago, they also first printed to C. Yet the fact that it is similar to C# means it is object oriented, which by definition is one of the slowest things on our machine. Vala doesn't require you to write object oriented code. Again, I have no reason to believe that a better C is not possible. Don't know if this is it. D also comes close but is a bit too slow for me. I've been trying to get away from C for years but feel like Al Pacino in the Godfather when he says, “Every time I try to get out, they keep pulling me back in!” I hoped you forgive me i skipped taking a look at Genie :) I don't care what you do. What is interesting is a language that's similar to C, so that can work on tiny processors, think of the 1024+ core processors we're gonna get not that long from now where code needs to be tiny and fast on each core, yet having the advantages of a few features handy for big companies. Yes, that would really be interesting. Companies want to know which module is to blame for something, and prefer something that has the support of some major company, say Sun or Microsoft. A language is as good as its compiler and also in C and C++ and Fortran we can see huge differences there of commercial compilers totally kicking butt of GCC in manners that's just not normal. I agree, it's more about the compiler and the fact is that so far enormous efforts have gone into C compiler and executable performance, and much less in any other language. - Don Vincent On Oct 7, 2008, at 8:38 PM, Don Dailey wrote: I have noticed there are 3 more languages that have appeared that seem to promise the speed and memory benefits of C and yet are higher level languages: Has anyone looked at lisaac, Vala, or Genie? Lisaac is claimed to be just as fast as C and was designed to be used to write operating systems just like C was. It looks extremely interesting but there appears to be little or no activity with it for quite a while. Vala is a C#/Java type of language that compiles to C code and also is claimed to give the advantages of C#/Java but the low level speed and control of C.You can compile stand-alone executable programs with it, unlike most other interesting languages. Genie is a brother to Vala and looks more like a static Python. The web page blurb goes like this: The syntax of Genie is designed to be clean, clear and concise. In some ways its cleaner than Python and is certainly a lot more concise than C#/Java. Genie of course has all the advantages of Vala and you can seamlessly use Vala code and bindings with it too just like a CLR. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
Don Dailey skrev: I have looked at Lisaac a bit. It does seem to be pretty close to C/C++ in performance. I'm all for a prototype based OO that fits the systems programming niche. It seems heavily influences by Eiffel and Self/Smalltalk. Since it actually emits C code it's not truly faster than C :) There is however a new kid on the block that is pretty impressive and manages to beat C/C++. ATS (Applied Type System) also emits C but due to the structure and type system the code is pretty specialized and optimized to beat any sane and optimized C program. /Dan I have noticed there are 3 more languages that have appeared that seem to promise the speed and memory benefits of C and yet are higher level languages: Has anyone looked at lisaac, Vala, or Genie? Lisaac is claimed to be just as fast as C and was designed to be used to write operating systems just like C was. It looks extremely interesting but there appears to be little or no activity with it for quite a while. Vala is a C#/Java type of language that compiles to C code and also is claimed to give the advantages of C#/Java but the low level speed and control of C.You can compile stand-alone executable programs with it, unlike most other interesting languages. Genie is a brother to Vala and looks more like a static Python. The web page blurb goes like this: The syntax of Genie is designed to be clean, clear and concise. In some ways its cleaner than Python and is certainly a lot more concise than C#/Java. Genie of course has all the advantages of Vala and you can seamlessly use Vala code and bindings with it too just like a CLR. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
Don, Have you tried LLVM with D? I don't know how hard it would be to graft the two together, but I have seen posts from folks doing so with Erlang and other languages. http://www.cocoageek.com/2008/08/llvm-gcc-benchmarks/ is an interesting benchmark of LLVM vs GCC - for some applications, it gives 20-30% improvement. ( You may recall LLVM from the recent hype regarding Apple's next-gen Snow Leopard ) Terry McIntyre [EMAIL PROTECTED] We must stop dressing up the slaughter of foreigners as a great national cause. -- Sheldon Richman ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
From: Dan Andersson [EMAIL PROTECTED] There is however a new kid on the block that is pretty impressive and manages to beat C/C++. ATS (Applied Type System) also emits C but due to the structure and type system the code is pretty specialized and optimized to beat any sane and optimized C program. I took a quick look at the www site http://www.ats-lang.org/ This is a very interesting idea: imperative programming in ATS is firmly rooted in the paradigm of programming with theorem proving. Good optimization, in my opinion, would depend on provably-correct theorems specifically adapted to the code. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
LLVMDC is a project to make a D compiler for LLVM. Supposedly, it is nearly ready for prime time. I have not experimented with it yet. My D-based bot gets 10kpps right now using gdc (D compiler for gcc). That's fast enough to be within ~50 ELO of the best light playout bots I've seen on CGOS. I'm sure I could make it faster, but I'm more interested in heavy playouts right now. Sent from my iPhone On Oct 7, 2008, at 4:16 PM, terry mcintyre [EMAIL PROTECTED] wrote: Don, Have you tried LLVM with D? I don't know how hard it would be to graft the two together, but I have seen posts from folks doing so with Erlang and other languages. http://www.cocoageek.com/2008/08/llvm-gcc-benchmarks/ is an interesting benchmark of LLVM vs GCC - for some applications, it gives 20-30% improvement. ( You may recall LLVM from the recent hype regarding Apple's next- gen Snow Leopard ) Terry McIntyre [EMAIL PROTECTED] We must stop dressing up the slaughter of foreigners as a great national cause. -- Sheldon Richman ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
There is however a new kid on the block that is pretty impressive and manages to beat C/C++. ATS (Applied Type System) also emits C but due to the structure and type system the code is pretty specialized and optimized to beat any sane and optimized C program. ATS does the binary-trees test 6.2 times quicker than C++ but 2.7 times slower on k-nucleotide (which seems to be about making hash tables): http://shootout.alioth.debian.org/u64q/benchmark.php?test=alllang=atslang2=gpp Ah, looking at the CPU load column it seems the C++ version of k-nucleotide uses multiple cores... http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotidelang=all Yes, it uses #pragma omp parallel sections default(shared): http://shootout.alioth.debian.org/u64q/benchmark.php?test=knucleotidelang=gppid=1 And now I look at the ATS implementation of binary-trees, it is using threads, while the C++ version is single-threaded. Lots of apples and oranges comparisons here :-). Darren -- Darren Cook, Software Researcher/Developer http://dcook.org/mlsn/ (English-Japanese-German-Chinese-Arabic open source dictionary/semantic network) http://dcook.org/work/ (About me and my work) http://dcook.org/blogs.html (My blogs and articles) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] programming languages
On Wed, 2008-10-08 at 08:25 +0900, Darren Cook wrote: And now I look at the ATS implementation of binary-trees, it is using threads, while the C++ version is single-threaded. Lots of apples and oranges comparisons here :-). And there is no single processor comparison number.I wonder why they don't do a Pentium 4 version just to eliminate that from consideration? - Don signature.asc Description: This is a digitally signed message part ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
