Author: Vincent Diepeveen
Date: 16:33:52 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.
Though i love Hyatt crawling over the floor, i have to admit that in this case
he must be crawling laughing for your idiocy here.
Let's start the functional programming subject.
I wrote a checkersprogram in a functional language. It was called gofer
(developed at university amsterdam). Deliberately i didn't use Haskell features
because haskell is in fact imperative and that would defeat the goal.
The checkers program using lazy evaluation and such high level language stuff,
was searching at 2 nodes a second.
It took me a week or 2 to make and optimize the gofer program.
Then i converted that by hand into a C program. That took 1 day and it was
10000-20000 times faster. Of course interpreted.
When compiled the C program was factor 50-100 faster.
Functional programming languages would be great to parse anything and easy to
use.
Well after writing a checkersprogram i realized at least 2 of its disadvantages.
Not only it's dead slow but also you can only make small functions. Have you
ever written a serious application in LISP?
I doubt it.
Really i do.
((((((((((a b c)(a))))))(((())))))(((())))
Sentences like above are not so easy to understand. C is way easier.
However if you write a chessprogram in LISP you will end up with tens of
thousands of lines of the above.
In fact i am 100% sure that a C chessprogram is SMALLER than a LISP chess
program is, when just looking to the code size.
Now we didn't talk about readability. C is easily readable.
A huge program when written in LISP will have ten thousand different functions.
That really is very bad. Trivially no compiler will be ever capable of
optimizing that well.
AFAIK only some grey old emacs fans write their stuff in LISP. When i define
something in LISP there i continuesly make (((()))((())) mistakes.
Defending such a functional dynosaur language as being a good language to
program in is against any common sense.
Let's summarize the problems of it
- too slow
- too many functions
- difficult to read code thanks to the ((()))(())(()))((
- really slow
- even slower
- dead slow
- slow to program complex applications in too by the way
>>>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.
>
>>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.
>
>>>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 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.
>
>Tord
This page took 0.01 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.