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
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
