Re: [computer-go] Re: Lisp time
Getting back to the CL vs. Scheme question, I think starting with Scheme is a perfectly reasonable choice as it is much more student-friedy (as long as you don't look at continuations too soon). Personally, I now prefer CL because of the multiple namespaces for different things (I can have a variable, a function and a class od the same name without any trouble) and the dirty macros I'm more comformable with (maybe just because I'm used to it, many people prefer Scheme for the same thing). But anyways, once you're familiar with lispy languages it'll be very easy to change anyways, so you shouldn't really worry much about starting with the right one. Also, a discussion comparing CL to Scheme or maybe even Haskell, OCaML or F# is rather pointless, as all of these language give you so much more abstraction and flexibility compared to the C-family (including Java) that their differences should not really matter.. Cheers, Benjamin ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Lisp time
hey, something fun! keeping pipelines full and carefully scheduling when cache will be flushed is another. not as performance-killing as branching, perhaps, but equally tedious to do by hand. one very cool thing about the ultrasparc (and likely many other processors) is that it could schedule 4 instructions at once: an int op, a float op, a load and a store. of course, main memory access is terrible, but if you could figure out how to equally divide time between int and float ops, you could make a killing. also useful are the many different graphics ops that can be repurposed with some heavy-handed engineering. i *believe* that some sparc cpus from the wayback machine could renumber some of their registers with a single (quick) instruction. some cute tricks ca. 1991: use the 4x4 matrix multiplier (also known as the instruction that rotates and translates sets of points in 3-space) on an SGI to do arbitrary matrix calculations, in 4x4 chunks. i think that this is common now. for efficient graphics updating, there is usually a ginormous pile of very fast ram sitting around that can be manhandled into dealing with partial results. older sgi's have tons of ram like this. this should be commonly done, if it isn't. and of course: stare at the instruction list provided by the manufacturer for a long time to see if there are any weird instructions that could be used in not-quite-as-intended ways. some of these can be found on the GPU, if there is one. probably modern graphics cards on pc's should be busy doing anything other than graphics, since they're so overpowered and are connected to the cpu via such an extremely fast channel. your monitor might look weird for awhile (or not), but man, you should be able to calculate like a mofo. and just to reiterate the earlier branching comment: if you see an if anywhere in your code, just imagine that you're causing yourself a very painful slowdown if it's true on the order of 50% of the time, false 50% of the time. and if it's almost always true or false, think about how to get rid of it or minimize the number of times it gets evaluated (or at the very least, how to advise the compiler to advise the cpu that it will be true or false most of the time). s. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping___ 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 Sat, Dec 15, 2007 at 03:00:02AM +1800, Nick Apperson wrote: In theory, and ONLY in theory, assembly is the fastest programming language. I do agree with most of what you said, but I have to squeeze in a comment that assembly is not necessarily the most optimized way to write code, when it really comes to it. If you *really* have to go for it, you need to be aware of the binary expression of every instruction... I have (once!) - many many years ago - optimized some assembly code where I reused the same bytes as instructions, jump offsets, and data, carefully placing the code on the right address so that this trick would work. This might have been possible with a good assembler, but at that time I did no have one for that CPU, so I was working directly in hexadecimal. With modern processors, assemblers, and compilers, things are different. And today, nobody will take the time to optimize on that level - which is good enough. But in theory... - Heikki -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ 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=sumcollang=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/
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=sumcollang=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
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
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
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
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. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go
Re: [computer-go] Re: Lisp time
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. -- Until the next mail..., Stefan. pgpTH0sCBMMBD.pgp Description: PGP signature ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Lisp time
My program was written in lisp, so naturally I concur. I'm not actively using lisp any more, but I will offer various dialects of common lisp as the consensus choice of dialect. My favorite implementation is lispworks. The personal edition is free and ought to be adequate for research. The big caveat for using lispworks is that it's a closed universe - editor, compiler, debugger, GUI are all in the same executable. The integration is great, but the strength is also the weakness if you want to share components with any other language. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Lisp time
At 05:24 AM 12/12/2007, Don Dailey wrote: I've looked into this a bit. My preference would be scheme and it's my understanding that it may be a bit more efficient. If you're worried about efficient use of the machine, stay away from lisp and scheme. Despite the claims of it can be as fast as C, you have to work hard and perform unnatural (from the viewpoint of lisp) acts to get anywhere near there. There are deep architectural reasons why lisp is not as efficient as C when used as directed. Use lisp if you're concerned with promoting efficient use of your brain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Re: Lisp time
At 05:24 AM 12/12/2007, Don Dailey wrote: I've looked into this a bit. My preference would be scheme and it's my understanding that it may be a bit more efficient. If you're worried about efficient use of the machine, stay away from lisp and scheme. Despite the claims of it can be as fast as C, you have to work hard and perform unnatural (from the viewpoint of lisp) acts to get anywhere near there. There are deep architectural reasons why lisp is not as efficient as C when used as directed. Use lisp if you're concerned with promoting efficient use of your brain. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Lisp time
Dave Dyer wrote: At 05:24 AM 12/12/2007, Don Dailey wrote: I've looked into this a bit. My preference would be scheme and it's my understanding that it may be a bit more efficient. If you're worried about efficient use of the machine, stay away from lisp and scheme. Despite the claims of it can be as fast as C, you have to work hard and perform unnatural (from the viewpoint of lisp) acts to get anywhere near there. There are deep architectural reasons why lisp is not as efficient as C when used as directed. Use lisp if you're concerned with promoting efficient use of your brain. I've never seen the claim of C-like speed ever hold up.I believe this is for 2 reasons: 1. compiler technology - huge emphasis on make C fast. Years of work improving this. 2. CPU - I believe all modern general purpose processors are more or less designed to execute C code fast. - 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] Re: Lisp time
These are true, but not the underlying problem. The biggest underlying reason is the multiple constraints on memory management; a) since the data is typed rather than the pointers, every chunk of memory has to be self identifying, not just for the garbage collector, but also so (plus a b) can do the right thing. b) since garbage collection can occur, the compiler is strongly constrained about when and where it creates and destroys pointers to data that might be garbage collected. c) the layout of the stack is strongly constrained, for the garbage collector, the exception handling system, and also the return values system; any function can return zero or more values, and may not return at all. d) all array references have be bounds checked. All structure references have to be type checked. Another major pain (from the viewpoint of a compiler) is that any function can be redefined at any time, and can have it's fundamental contract changed. A lot of things might need attention at runtime, depending on what assumptions the compiler built into the code it produced. With clever design, and a few extra declarations, this kind of thing need not be horrendously expensive, but it all adds up. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Re: Lisp time
Dave Dyer [EMAIL PROTECTED] writes: The biggest underlying reason is the multiple constraints on memory management; But these constraints are not absolute truths. At least not in Common Lisp: The language spec is not as constrained as described here and the compilers add some additional freedom. For example it's easy to turn array bounds checks off for either some part(s) of the code or even globally for the whole code. You are right, it's not always easy to get maximum performance with Lisp (and sometimes even not possible), but it is possible to get really good performance and sometime it's even possible to outperform C code. -- Until the next mail..., Stefan. pgpSDfry0PNBf.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 Dec 12, 2007 2:32 PM, Stefan Nobis [EMAIL PROTECTED] wrote: [...] and sometime it's even possible to outperform C code. I just don't believe this. I propose a simple experiment to see who is right. You pick a simple algorithm which you claim Lisp can run faster, you propose the fastest Lisp implementation that you can think of, I'll propose the fastest C implementation that I can think of and we'll compare. Are you in? Álvaro. ___ 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. To beat C I think you would have to write a better compiler.It wouldn't be about the language but about the compiler.I'm sure a really good language compiler can already beat a crappy C compiler. 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. D is a language that claims to have this, but it is still well behind C in the performance of the resulting executables. I really don't think a truly higher level language will ever beat C or a performance improved C. 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. I noticed that GCC already supports optimizations that involve profiling the code FIRST so that a second compiler pass can be smarter. - Don Álvaro Begué wrote: On Dec 12, 2007 2:32 PM, Stefan Nobis [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: [...] and sometime it's even possible to outperform C code. I just don't believe this. I propose a simple experiment to see who is right. You pick a simple algorithm which you claim Lisp can run faster, you propose the fastest Lisp implementation that you can think of, I'll propose the fastest C implementation that I can think of and we'll compare. Are you in? Álvaro. ___ 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/
