> 3) Algorithmic improvements are always more important that
fine-tuning.
It depends on what you mean by algorithmic improvements. Do you mean
performance improvements or do you mean conceptually cleaner code?
Sometimes you get both, but other times you have to write difficult to
understand code to get performance.
The problem with writing fast code in java, you have to "over-ride" the
language to get speed. Of course this is not only a java issue, even
C to a large extent has this problem (and I assume virtually all
languages have it to an extent.) To write the very fastest C code you
have to get ugly sometimes.
But it seems like more of a travesty in Java. You don't normally use C
to write clean simple easy to maintain code, but presumably you might
use Java for that. So it just seems WRONG to nullify all of this by
"avoiding object creation" in a object oriented language or even to seek
high performance algorithms that are ugly to implement.
Also, having to go out of your want to avoid creating objects is a
violation of the principle not to optimize your program till the end
(unless you are now at the end of course.) You have to wonder why you
chose Java if you start moving in this direction away from code
simplicity and clarity.
Algorithmic improvements are ALMOST always more important that
fine-tuning but not always.
Example: linear search is more efficient for small lists.
1. easier to understand.
2. simpler to write.
3. runs faster.
Of course you might simply consider a linear search to be an algorithmic
improvement in this special case. In a loop this kind of algorithmic
improvement could actually make a huge difference in speed, going from
binary search to linear search!
I know sometimes there are cases when a less efficient algorithm in
theory cannot be implemented to run faster in practice, usually due to
hardware issues or setup times that are not considered in the
theoretical big O notation.
It's all about which compromises you are willing to take and why you
choose a certain language. Java has many advantages they may cause you
to want to choose it, even if you are willing to give up code clarity
for performance. It could be as simple as having the libraries you
need or being a language where it's easy to find developers, etc.
I guess Mick Jagger said it best, "you can't always get what you want."
Do you want fast or clear? BOTH you say? It ain't gonna happen!
- Don
On Mon, 2006-12-04 at 08:22 -0800, Peter Drake wrote:
> 1) Run java in -server mode. This appears to double speed for no
> effort.
>
> 2) As you say, avoid creating objects. For example, instead of
> creating a new array each time a method is invoked, make the array a
> field and just clear it out when you need a "new" one. Similarly,
> instead of
>
> Foo x = y.clone();
>
> do something like
>
> x.copyDataFrom(y);
>
> where of course you have to write copyDataFrom().
>
> 3) Algorithmic improvements are always more important that
> fine-tuning.
>
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
