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

Fri Aug 11 13:41:17 PDT 2006

Mark,

If I was to summarize what you are saying, in your experience you have found optimizing constraints around programmer coding time as a superior investment to optimizing code execution time.  If that is accurate, I would say my own experience strongly supports your view.  I say this especially in the light of how I have had to revisit and recode plenty of times both for "testing a new idea" flexibility as well as for optimizing performance around a bottleneck (which seem to directly conflict with each other way more than I find enjoyable).

Jim

----- Original Message ----
From: Mark Boon <tesujisoftware at gmail.com>
To: computer-go <computer-go at computer-go.org>
Sent: Friday, August 11, 2006 12:25:58 PM
Subject: Re: [computer-go] C++ parameter passing (long)

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

_______________________________________________
computer-go mailing list
computer-go at computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/

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