[computer-go] C++ parameter passing (long)

[Mark Boon]

On 10-aug-2006, at 1:14, Chrilly wrote:
>
> If you are obsessed with speed, than make no classes at all. Good  
> old C style is the fastest. Classes have an overhead. But the main  
> point is, a class structure usually makes for this application  
> things more complicated without having a real benefit. Usually one  
> has only one array of zobrist_numbers. One can define this array  
> globally and there is no need to pass them as a parameter. I think  
> the basic rule is: If one is sure to have only one instantiation  
> and also no sort of class-hierarchy, one should avoid classes.
> One can structure C-style code in the same way than classes. E.g.  
> by putting all Hash-Related code in one file, by naming  
> conventions... In my experience, one can make a mess in any  
> programming language and programming style and one can write also  
> clear programms in any programming language including Assemblers.  
> The mess depends primarly on one ones head and the age of programm.  
> Over time every programm gets messy.
> The worst programming project I have worked ever was in Ada. Due to  
> an unclear and overambitious specifications it was a complete  
> horror. It was an error-tolerant Operating system. But only the  
> user had do be tolerant for the errors of the system. The project  
> was cancelled after spending about 1000 person years. I think clear  
> specifications - (at least in one ones head) - are much more  
> important than a specific programming style. Additionally one  
> should always implement the most simple solution which meets the  
> criterion. KISS. Handtalk is a nice example of this. Small, strong,  
> stable. It does not matter that it was written in Assembler.  
> Actually I think that its like this not although but because its  
> written in Assembler. Assembler is more cumbersome than C/Java..  
> and one thinks twice before one implements a complicated idea.
>
> Even if one parallizes the programm it is in my experience better  
> to parallize by using processes and not by threads. If one has a  
> cluster one has to use processes anyway. But the main point is,  
> that with processes there are clear defined communication points  
> and one can not overwrite some variables in another process. So  
> even for parallization there is only one instance of basic structures.
>
> Chrilly
>
Chrilly and other speed-obsessed programmers who consider using C or C 
++,

I meant to reply to this but didn't get around to it yet and I  
figured the answer was going to be long. I hope you don't mind  
combining it with another quote from another mail:

"But even with this restrictions the ladder routine generates 10-20  
nodes per evaluation. The ladder code runs at about 1.5 MegaPos/sec  
on a 3 GHz Pentum. So the ladder code alone reduces the speed of the  
eval to 75-150 KNodes."

I am obsessed with speed. And I'm well aware that the best speed is  
obtained by programming in Assembler. But it's not portable, so even  
though it gives the best speed in the short term, in the long term it  
just provides a lot of work to write it again for every new  
processor. The next step is C. Nowadays much more portable than 10-15  
years ago. And yes, it probably gives you the best speed of any  
reasonably portable language. There's no denying that.

But I think there's value in OO. Yes, in theory you don't need it.  
You can make equivalent constructs in C, just as you can do  
everything in assembler. But it makes life easier. In my personal  
opinion OO languages provide capabilities that make code cleaner,  
easier to understand and easier to extend, modify and maintain.  
(Although that wouldn't always be immediately apparent when looking  
at the average C++program.)

That's also the reason I like Java. It provides the closest thing to  
portability I know of. It's clean, easy to understand even when  
looking at someone else's code and a good OO language. But I pay a  
price in terms of performance. We can squible over how big the  
penalty actually is: is it a factor 1.2, 1.3 or 1.5 slower than C?  
Take 1.5 or even a factor 2 for all I care. Wait, didn't I just say  
I'm obsessed with speed? Let me reiterate that I am. But what I've  
learned from programming Go is that you need to write a lot of code  
to make a decent playing program. And there are many parts where  
speed is critical. You've been working on a Go program for a while  
now, you must have an idea by now how much work it is. And what I've  
learned is that there are always places where significant speed  
improvements can be made, you just need to spend the time on all  
those time-critical parts.

In short: (programming) time is (program) speed. The more time spent  
on some part of the program, the faster it gets. Of course you run  
into diminishing returns after a while. But there are always other  
parts that can be made faster you can switch to when (temporarily)  
you seem unable to make significant speed improvements on some part.  
So what I'm getting at is if I can have a portable language (saves me  
time porting) that provides libraries, constructs and features that  
save me a significant amount of programming time over another (faster  
but more laborious) language, then in the end I'm going to come out  
ahead in terms of speed.

Now I'm sure you're going to be skeptical about this claim of mine,  
if not outright incredulous. So let me get back to the second quote.  
I have an iMac (did I mention I like a portable language?) with a  
2Ghz Intel in it. I hadn't done any speed-tests with it yet, but I  
just needed to do that because I needed to find out what the overhead  
would be of using interfaces over classes in some parts of my new  
project. So I ran a few speed-tests that I have, including one that  
reads a ladder. In one example it reads a 14-move ladder in 8micro- 
secs. That's 1.75MegaPos/sec as you put it. Hey, but wait a minute!  
That is in Java and it's faster than a C program on a computer with  
1.5 times the clock-speed? How can that be?

OK, I'm teasing here. The reason it's faster of course is simply  
because I've spent more time on it than you have. Probably a lot  
more. I somehow gather you're a very good programmer. So I'm sure in  
time you'd be able to make a ladder-reading module in C that is  
faster than mine in Java. Hey, mine is public, you could even "steal"  
all the good ideas and put them in your C version.

So the moral of the story is it's OK to be obsessed with speed but  
you need to keep an eye on the big picture. I'm using Java because I  
am convinced that given the limited time I have I'll be able to make  
a faster program than if I'd be using C or C++. Is Java the best  
choice for programming Go? I honestly don't know, but I'm pretty sure  
it's not C.

I don't have the illusion that I'll convince you C/C++ die-hards out  
there but I couldn't help myself for a minute :-) I understand my  
advice already comes too late for some Assistent Professor from the  
Lewis & Clark College.

	Mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://computer-go.org/pipermail/computer-go/attachments/20060811/e6f46cd9/attachment.htm