Author: Ralf Elvsén
Date: 16:47:31 07/20/00
Go up one level in this thread
On July 20, 2000 at 17:02:36, Peter Kappler wrote: >On July 20, 2000 at 14:56:39, Ralf Elvsén wrote: > >>On July 20, 2000 at 12:15:49, Peter Kappler wrote: >> >>>On July 20, 2000 at 05:47:34, Ralf Elvsén wrote: >>> >> >>>> >>>>Lately I have begun to suspect that the try/catch statements >>>>in my Javacode was partly responsible for the preformance. >>>>Do you know if this is true? Can you guesstimate other pitfalls >>>>for an unexperienced Java-chess programmer? >>>> >>> >>>I'm not sure about the try/catch overhead. >> >>Ok, I'll have to look into it myself sometime. My program is full >>of that. It's a blessing for the debugging. >> >>>The only thing I absolutely avoid is creating any new objects while the search >is executing. >> >>Yes, no objects were created after the search started. I did create >>one or two simple objects for a while, to hold integers, at each node but I >>immediately noticed the overhead and removed it. >> >>>Also, what VM/JIT are you using? IBMs is the fastest. >>> >>It was all free stuff from Sun. Java 2.something and their >>Hotspot compilator. I figured IBMs wouldn't be THAT much better and >>was looking for the more serious bottlenecks first. > > >Hotspot is pretty good, but I think the IBM JIT is ~10-15% faster. > >Have you tried the profiler that comes with Sun's JDK? It's not too bad. > >--Peter Yes. Sorry, I don't want to make this discussion longer than necessary because I guess there is no simple thing I overlooked that can be fixed easily. Anyway, yes the profiler is good if it can be trusted, which I hope. I looked at the "balance" of the code, i.e. the time used in eval, movegen, q-search, SEE,... and from my understanding of what other people have posted here, it looked quite allright. I had killer moves, and together with SEE the move ordering was so and so, but could be improved alot I guess. My branching factor was good on average but varied wildly and I had strong odd-even effects I never understood. Is it possible that a program with these features in a "crude" state can be tweaked to a lot better performance? I had nullmove and a primitive hashtable. These two additions together gave my around three plies. I still missed two to be "fast" although I had a small eval. Oh well, I know it's impossible to help without looking at the code. But I would be interested to know if you know about what can cause odd-even effects. Or you can just pass :) Ralf
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.