Re: [computer-go] Re: compiler optimizations
Dave Dyer wrote: Arguments about the quality of compiler optimizations vs. hand coding are pointless, because programmers optimize programs in ways that compilers are (correctly) forbidden to do; by changing the algorithm. I've heard of no such law or rule. There are several compilers or interpreters that change algorithms, to do essentially the same. The simplest example is SQL. Several engines have such good optimizers that it doesn't matter if you do a left join, a subset check on a subquery, or some other method, as at the low level the engine translates it to, it all turns into the fastest code that gives the same result. These things are comming fast to more general purpose languages, and they're comming first to the languages where the compiler has the most information about the algorithms and data structures: the very high level languages. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: compiler optimizations
Dave Dyer wrote: Languages like SQL and Prolog don't specify algorithms, they describe the desired result. I agree that the quality of compilers that turn these specifications into algorithms can improve dramatically, and that this kind of specification is a great way to increase the productivity of programming languages. Getting back to go In my dreams I could write select groups where safetyalpha and sizebeta and color=black At a company where I once worked we used sql-like commands to get information about the status of customers. The information was not in sql databases, we just used sql as an abstraction.I guess in a way, there WERE in sql databases because I don't believe the sql standard dictates how data is stored or represented internally. So what you propose, even if tongue in cheek, is certainly possible. You could wrap a sql parser around your go program and use sql to access it.We could use sql instead of GTP! Brilliant! Each program is like a little sql server. select move from current_position order by evaluation desc limit 1; The abstraction is that your little sql server, your go program, represent every legal position possible. So you could do any kind of query over all positions. - 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] Re: compiler optimizations
On Thu, 2007-11-22 at 10:10 -0800, Dave Dyer wrote: Getting back to go In my dreams I could write select groups where safetyalpha and sizebeta and color=black That is not that hard to implement, given a proper definition of safety. Subqueries are left as an exercise to the reader :-) AvK ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: compiler optimizations
Dave Dyer wrote: Languages like SQL and Prolog don't specify algorithms, they describe the desired result. What's the difference? The two are very much intermingled when you get to high-level optimizations. I agree that the quality of compilers that turn these specifications into algorithms can improve dramatically, and that this kind of specification is a great way to increase the productivity of programming languages. Getting back to go In my dreams I could write select groups where safetyalpha and sizebeta and color=black As I said before, perhaps we /need/ a domain specific language for go AIs. It would be wonderful if a compiler knew the best algorithm for a specific need, and could see through a whole program and see what needs overlap and what data can be shared between algorithms. This is the biggest stumbling block for me when implementing things in an OO language; if you share information, you decrease maintainability, and make things harder to unravel later, but if you don't, you lose performance because the compiler isn't *quite* smart enough to see the common parts yet. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: compiler optimizations
Dave Dyer [EMAIL PROTECTED] writes: Languages like SQL and Prolog don't specify algorithms, they describe the desired result. Take a look as Haskell -- it's a very high level language but functional, so you are describing algorithms in it. Yet the compiler has so much knowledge (because of a real type system, not so simple things like in Java et al), that it is possible to do quite some complex code transformations and still guarantee the correctness of the result (as in SQL or Prolog). -- Until the next mail..., Stefan. pgp49KRIdeman.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: compiler optimizations
Why should a super-sophisticated compiler with algebraic type inference not be able to do this one day? On Nov 22, 2007 12:36 AM, Dave Dyer [EMAIL PROTECTED] wrote: Arguments about the quality of compiler optimizations vs. hand coding are pointless, because programmers optimize programs in ways that compilers are (correctly) forbidden to do; by changing the algorithm. For example, if I happen to know x will always be an integer from 0 to 359, I can replace sin(x) with a table lookup. No compiler can ever do that, even if I include assert(x=0 x360) in the code somewhere (which would be a good idea even if I know it). ___ 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: compiler optimizations
Because many optimizations take exponential or worse time to figure out if they apply. This means that the sun would explode before your compile would finish. Yes, compilers will get more sophisticated over time. No, they will not replace any algorithms or data structures. Michael Wing Why should a super-sophisticated compiler with algebraic type inference not be able to do this one day? On Nov 22, 2007 12:36 AM, Dave Dyer [EMAIL PROTECTED] wrote: Arguments about the quality of compiler optimizations vs. hand coding are pointless, because programmers optimize programs in ways that compilers are (correctly) forbidden to do; by changing the algorithm. For example, if I happen to know x will always be an integer from 0 to 359, I can replace sin(x) with a table lookup. No compiler can ever do that, even if I include assert(x=0 x360) in the code somewhere (which would be a good idea even if I know it). ___ 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] Re: compiler optimizations
Arguments about the quality of compiler optimizations vs. hand coding are pointless, because programmers optimize programs in ways that compilers are (correctly) forbidden to do; by changing the algorithm. For example, if I happen to know x will always be an integer from 0 to 359, I can replace sin(x) with a table lookup. No compiler can ever do that, even if I include assert(x=0 x360) in the code somewhere (which would be a good idea even if I know it). Unless the assert is part of the language, such as in Eiffel and other languages with contracts. (Though I'm not aware of any language that uses contracts in the optimization stage.) I tried (not hard enough, and failed) to push for design-by-contract extensions into C++ TR2, and even the author of the proposal seemed surprised when I said better optimization was a key feature: it seems everybody sees design by contract as all about safety. But it is about describing the problem more accurately to the computer so that it can not just find more bugs at compile-time but also so it can generate better code at compile-time. 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/
Re: [computer-go] Re: compiler optimizations
I agree with you 100%. You embody the methodology behind C++. The only problem I can see with adding something like that to C++ is that many times the compiler can't determine at compile time if a value is violating the contract. If the feature were added to C++, the programmer would have to be able to implicitly cast a value to the contract value datatype without having the compiler generate any actual checks. That is then a you don't pay for what you don't use way of doing things... the C++ way. On Nov 22, 2007 6:40 PM, Darren Cook [EMAIL PROTECTED] wrote: Arguments about the quality of compiler optimizations vs. hand coding are pointless, because programmers optimize programs in ways that compilers are (correctly) forbidden to do; by changing the algorithm. For example, if I happen to know x will always be an integer from 0 to 359, I can replace sin(x) with a table lookup. No compiler can ever do that, even if I include assert(x=0 x360) in the code somewhere (which would be a good idea even if I know it). Unless the assert is part of the language, such as in Eiffel and other languages with contracts. (Though I'm not aware of any language that uses contracts in the optimization stage.) I tried (not hard enough, and failed) to push for design-by-contract extensions into C++ TR2, and even the author of the proposal seemed surprised when I said better optimization was a key feature: it seems everybody sees design by contract as all about safety. But it is about describing the problem more accurately to the computer so that it can not just find more bugs at compile-time but also so it can generate better code at compile-time. 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/
