Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Can a Programming Language Cause Engines to be Slow?

Author: Eugene Nalimov

Date: 18:09:49 11/15/02

Go up one level in this thread


Off topic.

You may be surprised, but the most realistic scenario of the manned Mars mission
uses exactly Apollo-era (i.e. mid-sixties) technology -- mainly Saturn V-like
heavy booster on chemical fuel, not some futuristic propulsion system. And total
program cost will be less than inflation-adjusted cost of Apollo.

Search the web on "Mars Direct" and "Zubrin".

Thanks,
Eugene

On November 15, 2002 at 18:07:52, Vincent Diepeveen wrote:

>On November 14, 2002 at 23:35:14, Dan Andersson wrote:
>
>>What are you trying to prove? Lazy evaluation, in the CS sense, can be
>>optimized. As can most anything. Using well known transformations. A language
>>implementation can have some implementation detail that makes it slow. Like
>>making assignments immutable for example. That makes it neccessary to destroy
>>and recreate all data at certain points. That is slow. But then you use a tree
>>representation of large data and you go from N to log N. Or list access may be
>>by traversion. Then you use a good data representation. Slowness usually stems
>>from poor comprehension on the programmers part. Using lists as arrays an such.
>>
>>MvH Dan Anderssond
>
>Theoretically you can use years 50 technology with very old
>computers to fly to Mars too.
>
>However a possible mars mission will use the latest technology.
>
>So if you manage to optimize your years 70 functional languages
>very well for a compiler for a certain cpu, then we have a new
>generation of CPUs already.
>
>The compilers for the imperative languages will be ready by then. The
>functional language compilers will only look like years 70s. Everyone
>abandons them therefore.
>
>There are other practical problems with languages like Gofer. I wrote
>a checkers program in it. That's not a simple 10 line program.
>
>That's a few thousands of lines of code.
>
>That's hundreds of functions.
>
>It's complete chaos.
>
>Imperative programming is completely superb to that.
>
>Any serious program is not possible to get written in a functional
>language.
>
>It's chaos. It's idiocy to optimize such code to working code.
>
>Now you try to explain to me that you can write an even bigger compiler than
>all other imperative compilers combined yourself, which also is doing
>the same job, and you can do it while they move on to newer and newer
>cpu's?
>
>Please be realistic. Those languages will *never* be optimized as well as
>the current imperative languages are.
>
>It's too much code to let it optimize well.
>
>I challenge you to write an efficient move generator in a functional language
>and then tell me what speed it produces semi-legal moves. then we can
>compare it with the speeds the C programs get. 0 bytes of inline assembly.
>
>Let's compare with DIEP, Yace and some others.
>
>No theoretic nonsense please.
>
>I wrote thousands of lines of functional language and after that i realized
>better than the professor who had to look after all that code, how
>impossible functional languages are from practical and realistic viewpoint!
>
>It's *impossible* to optimize that very well.
>
>Best regards,
>Vincent



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.