[computer-go] CGOS 19x19
Cgos 19x19 is back. I hope electricity is stable :-) Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Hall of fame for CGOS
I, first, noticed that I might have readers especially Don misleading with my previous mail. I used "we" for the participants of cgos not "I and Don". I'm sorry if any. Has "Hall of fame" with incorrect ratings any sense? Rather, it may wrongly leads pepole, isn't it? I won't discuss farther as Don seems never change his mind with any discussion but I'd like to point out that Don should have many prior things to do than builiding such meaningless HoF. -Hideki Don Dailey: <[EMAIL PROTECTED]>: >Don't worry Hideki, > >Nothing has changed on CGOS, only something has been added and it has >no affect on what is already there. > >The standard current standings page also stays the same. No change I >promise. > >Different versions of a program running on CGOS has never been an issue >before, and nothing has changed in that regard either. > >Right now if you have 2 programs running on CGOS they might occasionally >play each other. They each get their own rating independent of the >other.That's how it's always been and that has not changed nor is it >broken. > >Bu that is the ONLY thing we might actually change later. But no >matter how you look at it, you cannot ENFORCE that change. > >Also, even though we can ask people to never change their program unless >they give it a new login name, we can't enforce that, nor is it >reasonable to try. I might have a program with an on-line learning >algorithm which improves itself over time - it would be unreasonable to >ask me not to put that on CGOS. > >Are you bothered by the fact that the "all time list" will have some >programs suffer that have improved over time but will always have the >prior bad results go against it? Don't worry about that.I will >probably put a time-limit on the games - perhaps I will only include the >games of the previous 12 months. This is going to be a list that is >updated every month. > >Also, there is no "Hall of Fame." It's only a list to show ALL >players over time and it uses bayeselo instead of the standard CGOS elo >system (which doesn't change.) > >- Don > > > > >Hideki Kato wrote: >> Your sentences make me strongly believe it's too early. >> >> I won't be against your idea. Again, just claiming it's too early. >> Following your analogy to sports, there should be some gurantee of >> fairness and agreement of participants. >> >> Our presupposition was that only recent results were important. Any >> temporal confusion of ratings would be fixed soon. So I could ignore >> or didn't mind wrong scored games. You are, however, changing it >> without any notification nor agreement. >> >> I think the problem of different versions are running with the same >> login names cannot be ignored. We have to announce and make sure >> almost all perticipants won't do it. >> >> Yes, network troubles are out of our control, some other troubles >> and/or accidents will happen. That's why we have to have some >> experiments before using the name of 'Hall of fame'. >> >> -Hideki >> >> Don Dailey: <[EMAIL PROTECTED]>: >> >>> Hideki Kato wrote: >>> Why don't you mention the several versions on one login name problem? >>> I don't consider it a major problem. The theory is that a big >>> improvement against versions of the same program might not translate to >>> equivalent improvements vs other programs.I want to see that proven >>> convincingly before I buy into it, it would take thousands of games to >>> prove this unless the effect was quite large so I won't accept anecdotal >>> evidence.I'm not saying this doesn't happen, but it's a >>> superstition until proven otherwise. >>> >>> Still, I would prefer to not rate games between members of the same >>> family just for the sake of appearance and accusations of nepotism. >>>(Although you can't really prevent nepotism.) >>> >>> And, I considered CGOS is not the Nascar type commercial races but a field to help developers to improve their progrms, say, in some academic sense. >>> I think it is an appropriate analogy. It's part of your equipment. >>> Every sport or field of endeavor has these variables beyond your control. >>> >>> But more to the point, if I could take this variable out of the >>> equation I would gladly do so. But I cannot detect the difference >>> between a network outage and cheating. >>> >>> What is your reason to name it as 'Hall of fame'? I'm not Western and can just estimate the value of the name but it's so heavy and important, isn't it? >>> Hall of fame is not a good name and it's not really called that. It's >>> the "9x9 all time ratings" but I almost called it hall of fame because >>> originally I intended to only include the top 50 players.I chose not >>> to for 3 reasons: >>> >>> 1. Many players are represented multiple times. >>> 2. It's more useful to be
Re: [computer-go] Python bindings for libego?
Darren Cook wrote: > I wonder if you had anything to say on how the development was? I'm > especially interested if you think if there was some aspect of the way > libego is written that made it either hard work for you, or made it > inefficient to wrap? I don't think so, beyond being written in C++ in the first place. C++ code is harder to wrap than C code just because C++ interfaces are that much richer, and because Pyrex isn't really designed for C++. (Well, there was one thing: I didn't find a nice way to wrap the functions that use iostreams in their interfaces. But that's not very interesting, because those are the text-manipulation bits that you wouldn't write in C++ if you were making a hybrid program). A lot of the inefficiency comes because I was aiming for a Python extension with pretty much the same interface as libego. For real work it would be better to start with the attitude "let's make a decent Python extension for working with go boards, and use libego to build it". I suppose you'd have functions for looping over each point in the board, for example, which would avoid constructing a silly Python Vertex object for each point. A real hybrid program would be more efficient again, because you could have C++ code implementing exactly what the interpreted code happens to need, and you could do away with the expectation that you shouldn't be able to crash the Python interpreter by passing bad parameters to an extension module. I still suspect that Python would be too slow to use for anything that happens as frequently as once per playout. > In notes.txt you say the speed dropped from 70-75 kpps to 43 kpps when > used in the wrapper (compared to 1 or 2.5 kpps in native python). And > you say this is due to the overhead of converting and checking > parameters? If you increase the number of playouts by a factor of 10 > does it close in to 70kpps? That drop happens because the Python code for running the benchmark itself is slower than the C++ code for doing so. That is, (I think) we lose so much speed because each iteration of the Python code in this loop for i in xrange(playout_count): working_board = start_board.copy() playout = Playout_cls(working_board, first_player) status = runner(playout) if status == pyego.PLAYOUT_OK: wins[working_board.winner()] += 1 elif status == pyego.PLAYOUT_MERCY: wins[working_board.approx_winner()] += 1 takes similar time to the single 9x9 libego playout that it runs. Increasing the number of playouts doesn't change things. But if I try it on a 19x19 board the penalty is rather lower, because the C++ code takes more time. > I wondered if it might be possible that some compiler optimization got > missed, or is just not possible, when built as an extension? The drop from ~75 to ~70 kpps is because of poorer compiler output when building as an extension (that is: I changed 'always_inline' to plain 'inline' everywhere to get the extension to compile; I presume it would be possible to put always_inline back and have separate entry points for the Python code marked plain 'inline', and I should think this would regain that 7%). -M- ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Hall of fame for CGOS
Gunnar Farnebäck wrote: > Don Dailey wrote: >> Also, even though we can ask people to never change their program unless >> they give it a new login name, we can't enforce that, nor is it >> reasonable to try. I might have a program with an on-line learning >> algorithm which improves itself over time - it would be unreasonable to >> ask me not to put that on CGOS. > > MonteGNU is doing on-line learning of its fuseki database. Excellent - that is the kind of thing I want to support on CGOS. - Don > > /Gunnar > ___ > 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] Lisp time
Yes, I agree with all your points. FFTW works by building test cases and testing them on the specific processor it runs on. In other words, under program control, many versions are produced just to see which one actually runs fastest.I know the inventer of FFTW (Mateo Frigo of MIT) who also contributed a little bit to my chess program.The code is produced in scheme or lisp but it's produced FOR C. This may not be the case any more, I haven't kept up with FFTW, but I can imagine the same concept being applied with other languages. Mateo was interested in my move generator for chess. It was super fast because I was able to eliminate most of the branching and it was based on code that produced code which caught his interest. Although I didn't use Mateo's technology, we talked about it. It's my dream that something much better will replace C and I'm hopeful that this day will come.I think it will be something like C but much better. I call it a better C, but that doesn't mean it has to look like C, I just hope that it replaces C.To replace C it has to be more than just fast like C, it has to give you pretty much complete control over your code. It's more fun and productive (in the code writing sense) to program in a much higher level language but there are conflicting goals. It's hard to be both a high level and low level language.A true successor to C will probably still be a relatively low level language.My bet is currently on D, but it's too early to be able to predict. - Don Harald Korneliussen wrote: > Don Dailey wrote: > > >> By the way, I am no fan of C. I don't like C and have tried some of >> the languages on your list of languages that are supposedly faster than >> C. >> >> I think you must be getting your information from the web pages for >> those languages. As a general rule any reasonably fast language is >> going to claim to be faster than C but shame on you if you believe it. >> >> "In theory" all languages are equal. They can all be transformed to >> optimized machine code. I am not talking about the theoretical, I'm >> talking about the reality.And the reality is that right now C is the >> choice, whether I like it or not I accept it and hope something better >> will come along. >> > > You are right, but there are some cases where alternatives may make sense. > For instance, look at the paper Ian Osgood linked to: They used Haskell to > spit out highly optimized code for Monte Carlo-simulations. There is also > FFTW, which makes very fast FFT code with the help of OCaml. > Code generation is one area where using another language might be > considered. It doesn't have to be a functional one, or even C: I know of a > cryptographic algorithm (Serpent) that has an implementation based on > Perl-generated Ada code. > > Prototyping may also be an idea. Especially if one is experimenting > with novel approaches, wouldn't it make sense to make a prototype > in Haskell, for instance? Then you may reimplement it in C, very carefully, > comparing outputs regularly to check for the playing strength-killing bugs > Chess programmers always talk about... > > Occasionally there may be some language feature that makes up for the > performance cost. Like the distributed nature of Erlang, or the > software transactional memory libraries that GHC Haskell come with. > If you believe the hype, STM scales much better than locking-based > shared memory. > ___ > 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] MC-UCT and tactical information
> -Original Message- > From: Jason House <[EMAIL PROTECTED]> > To: computer-go > Sent: Fri, 14 Dec 2007 2:23 pm > Subject: Re: [computer-go] MC-UCT and tactical information So, what tactical information should be calculated, how should it be used, and yes how should it be stored? > Looking only at moves, I see the following basic needs: > 1. Forced move pairs (peeps, miai) > 2. Equivalent move classes (semeai) > 3. Move sequences (joseki, fuseki, tactical L&D, endgame) > I've wondered previously about only storing #1 for use in sims, and using #3 > to replenish the supply > of forced exchanges as long sequences get played > out. > There's also higher level strategic stuff such as ensuring groups survive.? > Things that encode actions > instead of literal moves.? If actions include > establishing a connection, forming an eye, or getting two > eyes, they may be > able to be treated in a similar fashion to normal moves. OK. Let's consider using move sequences from life and death tests and applying them to the external nodes. A synopsis of the heavy playout rules from the first Mogo paper, from memory: 1. If the previous move put a friendly string in atari and there are any moves that would get it out of atari, pick one at random. 2. If there are any acceptable moves within a 3x3 neighborhood of the previous move that match a nice pattern, pick one at random. 3. If there are any moves that would capture an enemy string, pick one at random. 4. Make a random move. These rules handle a lot of forced move pairs, like peeps, but they are myopic. Maybe we should use the life and death tests at the root node to form a list of "moves that must be answered" together with some appropriate?answers. Then we could add a new playout rule #0. 0. If the previous move was a "move that must be answered," pick an answering move at random. (Probably, by definition, an answering move would have to be available.) - Dave Hillis _ More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Hall of fame for CGOS
Many Faces does on-line learning of Fuseki, Joseki, and half-board patterns. David > -Original Message- > From: [EMAIL PROTECTED] [mailto:computer-go- > [EMAIL PROTECTED] On Behalf Of Gunnar Farnebäck > Sent: Friday, December 14, 2007 1:28 PM > To: computer-go > Subject: Re: [computer-go] Hall of fame for CGOS > > Don Dailey wrote: > > Also, even though we can ask people to never change their program > unless > > they give it a new login name, we can't enforce that, nor is it > > reasonable to try. I might have a program with an on-line > learning > > algorithm which improves itself over time - it would be unreasonable > to > > ask me not to put that on CGOS. > > MonteGNU is doing on-line learning of its fuseki database. > > /Gunnar > ___ > 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] Hall of fame for CGOS
Don Dailey wrote: Also, even though we can ask people to never change their program unless they give it a new login name, we can't enforce that, nor is it reasonable to try. I might have a program with an on-line learning algorithm which improves itself over time - it would be unreasonable to ask me not to put that on CGOS. MonteGNU is doing on-line learning of its fuseki database. /Gunnar ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] MC-UCT and tactical information
> From: Jason House <[EMAIL PROTECTED]> > I've done some dabbling (thought experiments) with how I'd like to cache search results and I'm not yet happy with any of them. Not taking into account miai and such logic could > > lead to excessive storage bloat. I'd love to enter a discussion talking just about how to store cached L&D search results. Many Faces does life and death search at the root before the main search. It typically allocates a few hundred nodes to life and death search. Since the search is best-first, it keeps the search trees from move to move. Later searches can extend earlier ones. The trees are small, so it doesn't cost much to keep them. During evaluation tactical search results are cached, but the search tree is not. During a main search to find the move to play, Many Faces does a few million nodes of tactical search, so it's too much to cache. David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC-UCT and tactical information
On Dec 14, 2007 12:43 PM, <[EMAIL PROTECTED]> wrote: > For purposes of discussion, let's say the bot takes a tactical snapshot > once at the root node and then uses that information to help pick a move. It > can apply it at the root, at internal nodes, at external nodes, or at the > very end (maybe it decides this is an UCT-deceptive position and calls > another algorithm). > I totally agree. > To keep a tight focus, I suggest ideas that involve calculating additional > tactical information during the playouts themselves go into the ladder > thread. > I agree with that too! So, what tactical information should be calculated, how should it be used, > and yes how should it be stored? > Looking only at moves, I see the following basic needs: 1. Forced move pairs (peeps, miai) 2. Equivalent move classes (semeai) 3. Move sequences (joseki, fuseki, tactical L&D, endgame) I've wondered previously about only storing #1 for use in sims, and using #3 to replenish the supply of forced exchanges as long sequences get played out. There's also higher level strategic stuff such as ensuring groups survive. Things that encode actions instead of literal moves. If actions include establishing a connection, forming an eye, or getting two eyes, they may be able to be treated in a similar fashion to normal moves. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] MC-UCT and tactical information
> -Original Message- > From: Jason House <[EMAIL PROTECTED]> > To: computer-go > Sent: Thu, 13 Dec 2007 6:30 pm > Subject: Re: [computer-go] MC-UCT and tactical information > ... > "Change for the better" seems to imply only a one-sided analysis.? I would > imagine any analysis would > have to include both sides.? There's also > important concepts that can some into play like the number > of moves that > can be ignored (or must be ignored) before something happens.? This can be > critical? > info for ko fights and semeai. > I've done some dabbling (thought experiments) with? how I'd like to cache > search results and I'm not > yet happy with any of them.? Not taking into > account miai and such logic could lead to excessive? > storage bloat.? I'd love to enter a discussion talking just about how to > store cached L&D search > results. > When I go down this road, I'd probably initially focus on maintaining > connections in playouts and then > extend it to maintaining life.? There's > some tricky parts about when severing a connection or giving > up a group is ok.? Deep in a random game, it may be ok to conservatively > protect stuff, giving a sort > of quiescence search. For purposes of discussion, let's say the bot takes a tactical snapshot once at the root node and then uses that information to help pick a move. It can apply it at the root, at internal nodes, at external nodes, or at the very end (maybe it decides this is an UCT-deceptive position and calls another algorithm). To keep a tight focus, I suggest ideas that involve calculating additional tactical information during the playouts themselves go into the ladder thread. So, what tactical information should be calculated, how should it be used, and yes how should it be stored? - Dave Hillis --- More new features than ever. Check out the new AIM(R) Mail ! - http://webmail.aim.com ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Lisp time
Don Dailey wrote: >By the way, I am no fan of C. I don't like C and have tried some of >the languages on your list of languages that are supposedly faster than >C. > >I think you must be getting your information from the web pages for >those languages. As a general rule any reasonably fast language is >going to claim to be faster than C but shame on you if you believe it. > >"In theory" all languages are equal. They can all be transformed to >optimized machine code. I am not talking about the theoretical, I'm >talking about the reality.And the reality is that right now C is the >choice, whether I like it or not I accept it and hope something better >will come along. You are right, but there are some cases where alternatives may make sense. For instance, look at the paper Ian Osgood linked to: They used Haskell to spit out highly optimized code for Monte Carlo-simulations. There is also FFTW, which makes very fast FFT code with the help of OCaml. Code generation is one area where using another language might be considered. It doesn't have to be a functional one, or even C: I know of a cryptographic algorithm (Serpent) that has an implementation based on Perl-generated Ada code. Prototyping may also be an idea. Especially if one is experimenting with novel approaches, wouldn't it make sense to make a prototype in Haskell, for instance? Then you may reimplement it in C, very carefully, comparing outputs regularly to check for the playing strength-killing bugs Chess programmers always talk about... Occasionally there may be some language feature that makes up for the performance cost. Like the distributed nature of Erlang, or the software transactional memory libraries that GHC Haskell come with. If you believe the hype, STM scales much better than locking-based shared memory. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Where and How to Test the Strong Programs?
On Dec 14, 2007 10:55 AM, Nick Wedd <[EMAIL PROTECTED]> wrote: > I'll bet that if someone ever does write a go-playing program that > adapts its play in the light of what happens in the games it plays, I'll > eventually be able to train it to make some _really_ bad moves. That trick works against humans too. I've stopped playing igowin for that very reason... ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Where and How to Test the Strong Programs?
In message <[EMAIL PROTECTED]>, terry mcintyre <[EMAIL PROTECTED]> writes - Original Message From: Rémi Coulom <[EMAIL PROTECTED]> For instance, against computers, I estimate that Crazy Stone improved about 3 stones between this summer and now. But it clearly did not improve 3 stones on KGS. I vaguely remember that Sylvain also noticed that MoGo could beat GNU go with a 4-stone handicap, but was only 2 stones stronger than GNU on KGS. We human players have a nasty habit of adapting to the weaknesses of programs, and patching our own. I played a program which totally does not know the Chinese opening. I always wind up playing five large fuseki points, as it slowly plays five stones all on one side of the board. No matter how often I beat it, it will not adapt. Whereas, if a human player gets hit on the head often enough, he'll try something different. I'll bet that if someone ever does write a go-playing program that adapts its play in the light of what happens in the games it plays, I'll eventually be able to train it to make some _really_ bad moves. Nick This may account for improving versus another program, but not so much versus humans. The weaknesses of your computer opponents are more consistent. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Lisp time
By the way, I am no fan of C. I don't like C and have tried some of the languages on your list of languages that are supposedly faster than C. I think you must be getting your information from the web pages for those languages. As a general rule any reasonably fast language is going to claim to be faster than C but shame on you if you believe it. "In theory" all languages are equal. They can all be transformed to optimized machine code. I am not talking about the theoretical, I'm talking about the reality.And the reality is that right now C is the choice, whether I like it or not I accept it and hope something better will come along. - Don Don Dailey wrote: > Stefan, > > Yes, in special cases you can outperform C. > > I don't claim that it might not be possible with better compiler > technology to outperform C. I'm keeping my eye on D because it > promises to be one of those languages. > > But the truth of the matter, despite the promises, C is the best > performing compiler right now. I would feel silly trying to sit here > and convince you of this if you don't already know it. Look at any > objective benchmark. > > Fortran does outperform C in some code and is no slouch in general - > but it's still going to be slower than C in most things such as Chess > and Go programs. > > - Don > > > Stefan Nobis wrote: > >> Don Dailey <[EMAIL PROTECTED]> writes: >> >> >> >>> I thinks it's very difficult to outperform C since C really is just >>> about at the level of assembly language. >>> >>> >> No, in special cases it's not that hard to outperform C, because the >> language spec dictates some not so efficient details. C has an ABI and >> it's specification is optimized for the general case. Nearly every >> design decision has advantages and disadvantages. So if you look at >> the spec it's clearly possible to construct cases that are >> exceptionally bad for this specific spec. If you have a language >> without these restriction it's quite possible to get better results in >> this constructed case. >> >> So yes, it may be difficult and maybe most or even all cases in which >> it's possible to outperform C with Lisp are unimportant for any >> practical purposes, but nevertheless it's possible. >> >> And by the way I don't think C is really the best language for maximum >> performance. Just think about Fortran. AFAIK in it's main domain it >> easily outperforms C. There are also languages like OCAML, Ada, Forth >> and quite some others with really capable compilers und language specs >> that leave more freedom to compiler writers and such leave more room >> for different kind of optimizations. >> >> So the claim that C is the single one high level language with which >> you can get the maximum performance is quite an urban legend and >> completly unjustified. >> >> >> >>> I think the right approach to a language faster than C is to simply >>> write a better C that is specifically designed to have more >>> opportunities for optimization. >>> >>> >> C is a really crappy language, especially from the performace point of >> view. It's so low level that you are able to get really good >> performance despite all the odds of the language. You have to program >> around all the performace pitfalls, you have to do all performance >> optimizations yourself. C is no help here. So why should C be a good >> starting point for a language striving to make high performance >> computing easy? >> >> BTW: No, Lisp is also not a very good starting point for this special >> goal, but I would say Lisp would make a much better start than C, >> because Lisp shows you how much a good language and compiler can easy >> the pain for the developer while in C he is all alone. >> >> >> >>> I really don't think a truly higher level language will ever beat C >>> or a performance improved C. >>> >>> >> Have you really any hints, done any scientific benchmarks with >> languages like OCAML, Oz, Forth, Fortran, Ada, Scheme, and many others >> to make your claim any more than pure guesswork? >> >> >> >>> There is some hope that a JIT can do some optimizations not possible >>> with a static compiler - but even if this is the case C could follow >>> this path too. >>> >>> >> It's not easy and maybe not even possible for C to follow this route >> because C code (source and object) don't have very much >> information. Higher level languages provide much more information >> about what's going on, what data is in the game and the like. Or they >> set much more restrictions (like restrictive type systems). All these >> additional informations and/or restrictions make some algorithms >> for inference tractrable or even fast. Without these you are lost. So >> no, there are no hints that C would ever get such optimizations. >> >> >> >> >>
Re: [computer-go] Re: Lisp time
Stefan, Yes, in special cases you can outperform C. I don't claim that it might not be possible with better compiler technology to outperform C. I'm keeping my eye on D because it promises to be one of those languages. But the truth of the matter, despite the promises, C is the best performing compiler right now. I would feel silly trying to sit here and convince you of this if you don't already know it. Look at any objective benchmark. Fortran does outperform C in some code and is no slouch in general - but it's still going to be slower than C in most things such as Chess and Go programs. - Don Stefan Nobis wrote: > Don Dailey <[EMAIL PROTECTED]> writes: > > >> I thinks it's very difficult to outperform C since C really is just >> about at the level of assembly language. >> > > No, in special cases it's not that hard to outperform C, because the > language spec dictates some not so efficient details. C has an ABI and > it's specification is optimized for the general case. Nearly every > design decision has advantages and disadvantages. So if you look at > the spec it's clearly possible to construct cases that are > exceptionally bad for this specific spec. If you have a language > without these restriction it's quite possible to get better results in > this constructed case. > > So yes, it may be difficult and maybe most or even all cases in which > it's possible to outperform C with Lisp are unimportant for any > practical purposes, but nevertheless it's possible. > > And by the way I don't think C is really the best language for maximum > performance. Just think about Fortran. AFAIK in it's main domain it > easily outperforms C. There are also languages like OCAML, Ada, Forth > and quite some others with really capable compilers und language specs > that leave more freedom to compiler writers and such leave more room > for different kind of optimizations. > > So the claim that C is the single one high level language with which > you can get the maximum performance is quite an urban legend and > completly unjustified. > > >> I think the right approach to a language faster than C is to simply >> write a better C that is specifically designed to have more >> opportunities for optimization. >> > > C is a really crappy language, especially from the performace point of > view. It's so low level that you are able to get really good > performance despite all the odds of the language. You have to program > around all the performace pitfalls, you have to do all performance > optimizations yourself. C is no help here. So why should C be a good > starting point for a language striving to make high performance > computing easy? > > BTW: No, Lisp is also not a very good starting point for this special > goal, but I would say Lisp would make a much better start than C, > because Lisp shows you how much a good language and compiler can easy > the pain for the developer while in C he is all alone. > > >> I really don't think a truly higher level language will ever beat C >> or a performance improved C. >> > > Have you really any hints, done any scientific benchmarks with > languages like OCAML, Oz, Forth, Fortran, Ada, Scheme, and many others > to make your claim any more than pure guesswork? > > >> There is some hope that a JIT can do some optimizations not possible >> with a static compiler - but even if this is the case C could follow >> this path too. >> > > It's not easy and maybe not even possible for C to follow this route > because C code (source and object) don't have very much > information. Higher level languages provide much more information > about what's going on, what data is in the game and the like. Or they > set much more restrictions (like restrictive type systems). All these > additional informations and/or restrictions make some algorithms > for inference tractrable or even fast. Without these you are lost. So > no, there are no hints that C would ever get such optimizations. > > > > > ___ > 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] Re: Lisp time
Darren, Thank you for posting the links. Very nice. It could be my lack of understanding the intention of each of the tests, but it looks like most of them are micro-benchmarks, meaning there is single or very few methods calls and a very well defined micro-space. I can understand how doing something more sophisticated might cause it to remain an apples to apples comparison. Jim - Original Message From: Darren Cook <[EMAIL PROTECTED]> To: computer-go Sent: Friday, December 14, 2007 2:44:56 AM Subject: Re: [computer-go] Re: Lisp time >> I thinks it's very difficult to outperform C since C really is just >> about at the level of assembly language. > > No, in special cases it's not that hard to outperform C, because the > language spec dictates some not so efficient details. C has an ABI and > it's specification is optimized for the general case. Stefan, judging by this site (which I posted some links from yesterday) your intuition is correct: http://shootout.alioth.debian.org/ Overall C comes in 2nd, 10% slower than C++ (due to extra hints to the compiler I assume). But C/C++ are not the top of every benchmark. E.g. http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol〈=all Darren -- Darren Cook http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary) http://dcook.org/work/ (About me and my work) http://dcook.org/work/charts/ (My flash charting demos) ___ 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] Cgos 19x19
Due to electricity shutdowns in our university, I will wait a few consecutive hours with constant electricity before starting the 19x19 cgos server again. Sorry for that. Be sure I am in bigger trouble than you with these electricity shutdowns :-) Olivier ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Lisp time
Darren Cook <[EMAIL PROTECTED]> writes: > Stefan, judging by this site (which I posted some links from > yesterday) your intuition is correct: > http://shootout.alioth.debian.org/ To clarify: I don't really like these non-scientific benchmarks (in many cases I assume no one or only really few people (not including me) really understand what each micro-benchmark is really measuring). And I don't hate C. :) C is a nice language with quite some disadvantages but also quite some advantages. I just don't like unjustified guesswork about language characteristics and I'm overall very disappointed by so many programmers knowing nearly nothing about their tools and alternatives (no personal offends especially to people here meant, it's just an overall disappointment about the IT industry as a whole). So I get easily upset by these things (like "you get best performance only with C"). Sorry for any overreaction. -- Until the next mail..., Stefan. pgp0PesesvEi7.pgp Description: PGP signature ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Lisp time
On 14/12/2007, Nick Apperson <[EMAIL PROTECTED]> wrote: > C++ is "faster" than C because the STL (and other generic code) allows the > programmer to spend their precious time optimizing the bottleneck and using > a very fast default for less critical places. For a sufficiently small > program however I will wager that given enough time, C will be exactly the > same speed as C++ if the programmers involved are both good. The C++ generics are also on the surface faster than (for example) the Java generics (which I use). This is because whereas C++ compiles and optimises a class for every instantiated generic, Java uses a single class and is thus unable optimise for specific cases. This makes C++ generics faster, except in the case where the bottleneck is how much can be fitted in the cache, which the fact that Java hasn't multiplied it's generic classes may give it the advantage. Yes, as you can tell, I'm bitter about this particular design decision. cheers stuart ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Lisp time
Look, I love C++ and I'd love to say look I told you all, C++ is the fastest, but frankly it just doesn't work like that. When we come to a point where every programmer writes the fastest possible code their language could create then we have some kind of a comparison. C++ has a philosophy that you don't pay for what you don't use, but there is not a single construct in C++ that can't be built in C with enough code (virtual functions are a grey area since the compiler can better optimizer them over direct function pointers... but that is irrelevant anyway). Sometimes the amount of code is rediculous and frequently to obtain the same speeds one has to sacrifice portability and reusability. In theory, and ONLY in theory, assembly is the fastest programming language. The fact is, in a sufficiently complex program, there will always be parts of the program left to further optimize. I would assert that for a complex program, an assembly programmer and a C++ programmer both writing the same program and spending the same amount of time will leave the assembly version slower always. It is not because assembly is a slower language, it is because if the assembly guy spends another 1000 hours optimizing, so will the C++ guy and certainly their are exceptions, but in general, for most problems and for reasonable amounts of time spent, the C++ code will be faster. C++ is "faster" than C because the STL (and other generic code) allows the programmer to spend their precious time optimizing the bottleneck and using a very fast default for less critical places. For a sufficiently small program however I will wager that given enough time, C will be exactly the same speed as C++ if the programmers involved are both good. When will you people learn the limits of benchmarks? They are only useful for showing how worthless Java is... nothing else. Got it? - Nick On Dec 15, 2007 2:44 AM, Darren Cook <[EMAIL PROTECTED]> wrote: > >> I thinks it's very difficult to outperform C since C really is just > >> about at the level of assembly language. > > > > No, in special cases it's not that hard to outperform C, because the > > language spec dictates some not so efficient details. C has an ABI and > > it's specification is optimized for the general case. > > Stefan, judging by this site (which I posted some links from yesterday) > your intuition is correct: > http://shootout.alioth.debian.org/ > > Overall C comes in 2nd, 10% slower than C++ (due to extra hints to the > compiler I assume). But C/C++ are not the top of every benchmark. E.g. > http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all > > Darren > > > -- > Darren Cook > http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary) > http://dcook.org/work/ (About me and my work) > http://dcook.org/work/charts/ (My flash charting demos) > ___ > 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] Re: Lisp time
>> I thinks it's very difficult to outperform C since C really is just >> about at the level of assembly language. > > No, in special cases it's not that hard to outperform C, because the > language spec dictates some not so efficient details. C has an ABI and > it's specification is optimized for the general case. Stefan, judging by this site (which I posted some links from yesterday) your intuition is correct: http://shootout.alioth.debian.org/ Overall C comes in 2nd, 10% slower than C++ (due to extra hints to the compiler I assume). But C/C++ are not the top of every benchmark. E.g. http://shootout.alioth.debian.org/gp4/benchmark.php?test=sumcol&lang=all Darren -- Darren Cook http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary) http://dcook.org/work/ (About me and my work) http://dcook.org/work/charts/ (My flash charting demos) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
