Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Languages revisited. Functional language beats C for number cruncing

Author: Vincent Diepeveen

Date: 09:53:17 01/10/03

Go up one level in this thread


On January 10, 2003 at 12:28:56, Uri Blass wrote:

It was written in emacs. It is doing things like
{
}

that's 3 lines extra for free.

#include <stdio.h>
#include <string.h>

bla bla.

all default crap.

Ask people how fast i can type :)

400 keys a minute.

all default crap. then some cut'n pasting of parsing stuff and
changing 2 letters in it and 1 resulting action and you get
lines for *free* :)

the resulting thing was somewhere against 200 lines.
It's an estimation from now :)

the total work was 30 minutes in total and that included 1 bathroom
break.

I do not understand why they estimate effective work done in businesses
at 0.5 lines an hour.

That means i work 200 times more efficient when i program computerchess features
(not to confuse with algorithms or optimizing the code a lot).
features is straight programming.

Of course you never manage that 8 hours a day.

I remember my record was some months ago when i made an entire new EGTB scheme
from scratch with new features and such. My old EGTB scheme was very
inefficient. The straight feature programming was done in a matter of a day.

No cut'n pasting at all. All made from scratch with perhaps a few lines
exception (initializing of KK reduction which i did in old EGTB).

Rest all written from scratch in a day.

10/23/2002  05:14p              56,776 DIEPBITT.C

The bugfixing took however quite some longer :)

Even faster than this straight ansi-coding goes coding interfaces. it's cut'n
pasting so many lines for each new feature and then modifying a few things that
those standards of 0.5 line an hour a programmer is IMHO completely outdated.

>On January 10, 2003 at 10:52:37, Vincent Diepeveen wrote:
>
>>On January 10, 2003 at 08:01:45, Dan Andersson wrote:
>>
>>>A couple of postings on comp.lang.scheme implemented the CoyoteGulch benchmarks
>>>in Scheme. And lo and behold BigLoo produced faster code for the numerical
>>>benchmark. One might object that since BigLoo emits C or Java bytecode it isn't
>>>really faster. But the amount of automated program transformations that are
>>>applied is huge. For a coder to do the same thing would be like trying to
>>>outperform a spreadsheet. And the C code is inhuman in nature. And the question
>>>arises: Why on earth would one use C++ or Java? Both are verbose and terribly
>>>low level compared to lambda calculus.
>>>
>>>MvH Dan Andersson
>>
>>I disagree.
>>
>>When i converted my functional international checkers program to C it was not
>>bigger in code and it was 10000 times faster in C than in Gofer (which also has
>>lambda).
>>
>>Later efforts from expert gofer programmers speeded it up another 2 times.
>>
>>Big deal. factor 5000 difference.
>>
>>Compiling it was not very well possible that gofer language, because there were
>>no good compilers for it (the only thing that was there was some stupid turbo-C
>>thing and by then turbo-C was completely outdated and only worked in DOS not
>>windows).
>>
>>However on a fast PC i tried and the difference after some tuning was still a
>>factor 100 favourable for C.
>>
>>It is not true that functional programming is easier. Instead it is more
>>difficult to learn because you need more functions and shorter functions. The
>>lambda you will never manage to explain whereas the imperative languages are
>>clear for everyone.
>>
>>The big 'advantage' of gofer was said to be easy parsing anything. Then they had
>>a script to 'parse' in such a way that it could be used to use gofer for CGI
>>parsing.
>>
>>Then i had a contest between someone who promoted on Gofer (so not exactly a
>>gofer beginner) who would be using gofer mixed with haskell to parse some type
>>of output from a homepage into a textfile and then converting it back to a
>>resulting html page which showed results.
>>
>>I would write it in C. He in gofer+haskell (whatever).
>>
>>After 10 minutes i was nearly done and after going to the toilet and then fixing
>>another bug after in total 30 minutes i finished my C parser and had it bugfree
>>working and doing anything and everything.
>>
>>After 2 hours he still didn't manage to write the equivalent in Gofer+Haskell,
>>even though he could use a 'cool' number of already existing scripts whereas i
>>parsed the direct (method POST) output.
>>
>>My CGI script in C was like 200 lines at most but it easy to write and easy to
>>debug. It took another few afternoons before the equivalent in Gofer was ready.
>>
>>30 minutes including bathroom stop in C is equivalent to some hours of
>>functional coding.
>>
>>Best regards,
>>Vincent
>
>I am surprised that you can write 200 C lines in 10 minutes with only one bug.
>ut means that you write one line in one second.
>
>To be more correct you say at most 200 lines but even if I assume that it was
>only 100 lines still writing one line in 6 seconds seems impossible for me.
>Only writing your program from memory (if I remember all the program) seems to
>me more time.
>
>I also almost never write 200 lines without some testings in the middle for
>bugs.
>
>Uri



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.