Author: Robert Hyatt
Date: 12:31:03 02/16/04
Go up one level in this thread
On February 16, 2004 at 15:08:42, Uri Blass wrote: >On February 16, 2004 at 14:38:44, Robert Hyatt wrote: > >>On February 16, 2004 at 14:25:10, Tord Romstad wrote: >> >>>On February 16, 2004 at 14:03:11, Robert Hyatt wrote: >>> >>>>Please re-read my statement. Look at the date. Then re-read yours. >>>> >>>>My statement was written in 1997. In general Lisp _was_ interpreted. >>> >>>No, it wasn't. Lisp has been a compiled language for *decades*. If you >>>look at the ANSI Common Lisp standard (from 1991, if I recall correctly), >>>you will see that the standard even *requires* a compiler. There is >>>one implementation (CLISP) which compiles only to bytecode, all other >>>major Lisp implementations have compiled to machine code since a very >>>long time. >>> >>>>Of >>>>course, so was BASIC. Yet there were basic compilers as well. My primary point >>>>was speed. Lisp is slow. It always was slow. It always will be slow. >>> >>>It *isn't* necessarily slow. I have even provided one data point (from >>>1999, just two years after your statement was written) to illustrate that >>>Lisp in practice often enables you to write *faster* programs in *less* >>>time compared to C/C++. >> >>Personally, I would take _any_ challenge to compete with a lisp program, when >>the goal is performance. Granted, high-level languages may reduce the >>_development_ time. > >I know nothing about lisp but >remember that you have not unlimited developement time and it is possible that >in limited time lisp is better for speed because you can also write code for >solving the same problem in C with limited time but the code will be slower >because you have not enough time to write the algorithm that you can write in >lisp and you need to use inferior algorithm. > >It is only a possibility and I may be wrong because I know nothing about lisp. > >Uri The main purpose of "higher level languages" is to reduce development time, at the expense of execution time (usually). But in chess, this is different. IE the lifetime of a chess engine is not measured in weeks or months, but in years. This means that the programmer has a lot of opportunity to spend many hours on efficiency issues as the program evolves and parts of it become "static" (or as static as they can become, maybe). So you always have to factor in this extra "tweaking" time if efficiency is important, because it is always necessary. If you give me 5 minutes to write a program to parse a text command, I'm picking snobol, for example. I can't even write it in assembly that quickly. Nor in C if the syntax is not very simple for what I have to parse. But give me enough time and the assembly version will run faster than any other implementation. That is where we are in this discussion. It is one thing to produce code fast, it is something else to produce fast code. Lisp is reasonable for the former, C or ASM is far better for the latter. Only if you believe that speed doesn't matter, should you tackle chess with a very high level language. It still has to search quickly enough to not get burned by the opponent...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.