[computer-go] language choices

[Mark Boon]

Don,

I disagree rather strongly with some of your statements.

On 4-dec-06, at 18:35, Don Dailey wrote:

>
> This isn't a Java issue,  it's most if not all computer languages - if
> you really go all out to optimize your code for performance,  you will
> sacrifice readability, clarity, etc.
>

In principle I agree with this, however...

> Without looking at your code I would say that if it's extremely  
> easy to
> read and clear and beautiful, it's not as optimized as you  
> think.    If
> it's highly optimized and efficient, it's probably not as beautiful  
> and
> readable as you think.

I find that this tends to be decreasingly the case as compilers get  
better. Nowadays it's very rare to have to program something for  
speed that makes me cringe.

>
> I've never understood that reasoning.   If you are willing to wait  
> for a
> better compiler to come along, fine.    But to say optimizations are a
> waste of time because a better compiler will come along someday isn't
> the point we are talking about.    You could also claim that ANY
> optimization is a waste of time because if you wait long enough
> computers will get faster and get you up to the desired level of
> performance.

Sorry, but this is outright wrong thinking. When I wait for a faster  
computer the program becomes faster but I still lose out relatively  
to the optimized program. If I wait for the better compiler, both  
programs perform the same. That's a big difference.

> The only problem with that reasoning is that you will always be slower
> than you have to be.  If it's important to you to be competitive with
> other programs, you will always be behind - at least with the computer
> hardware speed issue.

I don't see that as a problem as much as a fact of life. For  
sufficiently complex programs (I think Go programs qualify) one is  
always slower than one has to be, even in C or assembler.

> However I do agree with you to a point.  If I knew  a particular
> compiler optimization is likely to happen in the near future, I  
> probably
> wouldn't bother  unless it was a major problem right now.
>
> For me, here is the point:
>
> If you use anything other than C (or assembler) you are starting  
> with a
> speed penalty, a handicap.  Presumably, the only reason you would do
> this,  is for the convenience of a higher level language - a  
> logical and
> sensible trade-off that I have no problem with.
>
> But then you spend a lot of time optimizing it because it's not as  
> fast
> as C.   You started with Java to save yourself a lot of time and
> increase your productivity, then you give it all back trying to  
> overcome
> the speed handicap you accepted!

Again, I don't agree. I think for a well optimized program the effort  
spent optimizing in Java compared to C is probably about the same or  
less, so I don't return any gain in productivity by choosing Java.

>
> Once you make the decision of a higher level language, you have  
> accepted
> the tradeoff of lower performance for higher programmer productivity.
> You have implicitly admitted, by choosing Java or some high level
> language,  that you don't need to be on the cutting edge of  
> performance.
>
> So my question is why not just wait for a faster computer or better
> optimizer and maintain the advantages of using a higher level  
> languages?
>

That's what I generally do, exactly my point.

> I don't have a problem with basic and sensible optimizations that may
> even increase the readability of the code,  but people here are  
> talking
> about going out of their way to avoid creating objects and such.    
> This
> just doesn't make sense to me.    This is something you would do in C
> because you are performance guru freak.

The object pooling is the only thing I'd rather do without. But for  
speed that's not possible, unfortunately. However it hardly affects  
cleanliness or readability as there's not such a big difference  
between a constructor call and a factory call. It does add some extra  
code, that's true. However, that's the same for any language, also  
low-level ones like C or assembler. I don't see the logic why you  
can't do in Java something that performance gurus do in C. Just  
because it's Java? Because it makes sense?

Mark