Author: Robert Hyatt
Date: 07:46:25 02/17/04
Go up one level in this thread
On February 17, 2004 at 06:41:11, Tord Romstad 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. All the previous languages I have mentioned come to mind,
>>from Prolog, to APL, to Snobol. But when execution speed is the issue, I'll
>>take C _every_ time, and if I were unable to beat a lisp program at speed, for
>>the same functionality, I'd probably turn in my coding pad. :)
>>
>>Just as surely as I would take assembly over C if speed were the ultimate goal,
>>no matter how good the C optimizer is. A bad programmer can write bad C code.
>>A programmer that is not familiar with a computer (take a Cray) will probably
>>get beaten by the optimizer. But for a human that knows the architecture, I'll
>>take the lowest-level language every time, when raw NPS or whatever is the goal.
>
>The key point is the "knows the architecture" part. Just like an assembly
>language program doesn't automatically run faster than a C program just
>because it is written in assembly language, a C program doesn't automatically
>run faster than a Lisp program just because it is written in C. In both
>cases, you need some in-depth knowledge of the computer hardware to take
>advantage of the low-level features of C or assembly language. In both
>cases, the performance gain given by the lowest-level language isn't
>extremely big. Given optimizing compilers of the same quality, the
>performance difference between assembly language and C is probably
>comparable to the difference between C and Lisp.
Never said otherwise and I wouldn't disagree. My point was that a good C
programmer is going to be able to write code that runs faster than a good lisp
programmer. A good assembly language programmer will beat a good C programmer.
If you don't understand the language, and the architecture, then all bets are
off of course... However it is always easier to write a program with a
high-level language. And it is also easier to write a slow program by using
things that are "cute" but not "efficient"...
>
>>>For complicated programs, it sometimes requires somewhat more expertise
>>>to write fast code in Lisp compared to C. You will also need some
>>>familarity with the internals of your Lisp implementation.
>>>
>>>I know what I am talking about -- I am not making all of this up. I
>>>have been working as a full-time Lisp programmer for almost three years,
>>>and I have used Lisp extensively before and after that time as well
>>>(mostly for mathematical tasks). In most cases, I find it very hard
>>>to write a C program which performs as well as my Lisp solution to the
>>>same problem.
>>
>>
>>Perhaps that says more about your C programming than your Lisp programming.
>
>I've already conceded that point. If you read my last post again, you
>will see that I explicitly state that I am a much better Lisp programmer
>than C programmer. You are one of those who have detailed knowledge and
>lots of experience with low-level programming and computer hardware,
>and you are therefore able to squeeze out more performance from a C or
>assembly language program than I would ever manage. Without such
>knowledge (which, I think, most of us do not posess), C simply doesn't
>offer any significant performance advantage.
Again, I won't disagree. A programmer needs several "tools" in his sack.
(1) a good understanding of the architecture. Difficult at times, and with
Intel, where the rules change yearly, even more difficult than (say) learning
about the Cray, or the Fujitsu, or the Hitachi, or whatever.
(2) a good understanding of the compiler being used, and how it produces
assembly code for the various high-level constructs it supports. Without this,
(1) above is not very useful. Of course this implies a good knowledge of the
language being used at the same time. And what is good/bad within that
language.
(3) a good understanding of the algorithm to be implemented.
>
>>I've never seen anyone claim that a high-level language produces faster
>>executables than low-level languages. The normal claim is "reduced development
>>time" at the expense of "program performance". Claiming the opposite boggles my
>>imagination. IE do you also believe that a good LISP programmer can beat a good
>>assembly programmer, since he can beat a good C programmer?
>>
>>Not on my watch...
>
>There is noone who forces you to use the same language for the whole program,
>of course. Performance-critical parts of a Lisp program could be rewritten
>in C or assembly language. Mixing Lisp and assembly language tends to be
>much easier and more comfortable than mixing C and assembly language, because
>of the power of Lisp macros.
>
There really is zero problems in mixing C and assembly language. You just write
the assembly to look as though it were a C function, by naming it properly and
knowing how C passes arguments. I have mixed assembly with everything over the
years, from Fortran, to basic, to cobol, to pl/1, to pascal, and to C. The main
decision to make is "is it worthwhile"? IE an asm move generator makes little
sense when it uses less than 10% of the total search time.
>>>To a certain extent, the explanation of this is of course that I am
>>>a much better Lisp programmer than C programmer. But I am not a
>>>complete idiot in C either. After all, my chess engine, written in C,
>>>is stronger than most amateur engines.
>>
>>Why not "my chess engine, written in lisp?"
>>
>>???
>
>
>If you read a few more lines of my post, you would see the answer.
>Portability. I want to use the same code on Mac OS X, Linux and
>Windows, and I have long-term plans to port my engine to Palm OS.
That's the goal of every high-level language. I know of no language that has
actually pulled it off, however. Because every operating system offers some
facility that the compiler wants to present to the user. And this gets done in
different ways on different machines. This is true of C, Fortran, even Lisp.
The last big lisp code I fiddled with would only work using a particular
compiler from (I think) the "Golden common lisp package" IIRC. The lisp on our
vax would not deal with it.
Of course Crafty runs on all the boxes you mentioned, but by using the
pre-processor facility to include/exclude code as needed. Not very elegant.
But at least functional...
>
>>>
>>>>That is why there has been no successful chess engine based on LISP yet.
>>>
>>>There hasn't been any attempt to write a conventional chess engine in
>>>Lisp yet. But I know that my engine would have been no weaker if I had
>>>implemented it in CMUCL instead of using gcc. My reason to use C rather
>>>than Lisp is not efficiency, but portability.
>>>
>>>Tord
>>
>>
>>
>>There have been Lisp chess programs in the past. I'm not even sure that Steven
>>didn't write one a long while back, although I am thinking of "AI Chess" and he
>>might have used something else.
>
>Yes, Steven started on a project called CIL ("Chess In Lisp"). It is not
>a complete program. The code which is there is entirely unoptimized and
>looks like a complete joke, probably because the project was abandoned
>early.
>
>The only complete Lisp chess engine I have seen is called BCE. This is
>terribly weak, but the authors C chess program ("Bace") is not much
>better (rated 1319 on Leo's rating list).
>
>I repeat; there has been no serious effort to make any conventional chess
>engine in a modern version of Lisp, and I know that my own engine (currently
>rated 2733 in blitz on ICC, on a PIV 2.4 GHz) would perform at most
>marginally worse if I rewrote it in Lisp.
That would be a good hypothesis to test. I'd suspect that garbage-collection
alone would make a huge difference in performance.
>
>Tord
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.