Fguy64 wrote:It's not clear to me why memory footprint should be an issue in this case, since the memory is allocated only once when the program is initialized. An array like this shouldn't take more than a few KB, no? Are you saying it would be slower with the static array than calculating knight moves on the fly?
64 (squares) x 8 (directions) = 512 bytes
That is not much compared with for example magic move generation method where all the moves are pregenerated and take around 838kb.
Anyway, it is always good practice to try to reduce the memory footprint as it pollutes the processor cache. If a certain value is not stored, it has to be collected from the RAM which takes much more time. On the other hand you might overwrite other valuable variables for example from the board structure or similar.
Concerning the number of processor cycles these two should be roughly the same.
Fguy64 wrote:It's not clear to me why memory footprint should be an issue in this case, since the memory is allocated only once when the program is initialized. An array like this shouldn't take more than a few KB, no? Are you saying it would be slower with the static array than calculating knight moves on the fly?
64 (squares) x 8 (directions) = 512 bytes
That is not much compared with for example magic move generation method where all the moves are pregenerated and take around 838kb.
Anyway, it is always good practice to try to reduce the memory footprint as it pollutes the processor cache. If a certain value is not stored, it has to be collected from the RAM which takes much more time. On the other hand you might overwrite other valuable variables for example from the board structure or similar.
Concerning the number of processor cycles these two should be roughly the same.
ok well mine is an array of 32-bit integers, since java requires array indexes to be integers, if you try to use bytes as indexes it will upcast to integer format before using as an index, so I figure may as well store them that way.
Anyways, you say RAM storage not really the point. I hadn't considered aspects such as pollution of processor cache, that's not something I have taken into account, but now that you mention it, I'll be sure to consider it.
regards.
p.s. if you are saying that the cost of processor cache pollution possibly outweighs the cost of doing upcasting from 1-byte to 4-byte format for array indexing, then that is something worth knowing.
Fguy64 wrote:p.s. if you are saying that the cost of processor cache pollution possibly outweighs the cost of doing upcasting from 1-byte to 4-byte format for array indexing, then that is something worth knowing.
Sorry, I don't have the experience to say that. Best in this case is often just to try it, as it is very engine specific. Maybe just run some testpositons and compare the average time to reach a certain depth or the average nps.
Fguy64 wrote:It's not clear to me why memory footprint should be an issue in this case, since the memory is allocated only once when the program is initialized. An array like this shouldn't take more than a few KB, no? Are you saying it would be slower with the static array than calculating knight moves on the fly?
64 (squares) x 8 (directions) = 512 bytes
That is not much compared with for example magic move generation method where all the moves are pregenerated and take around 838kb.
Anyway, it is always good practice to try to reduce the memory footprint as it pollutes the processor cache. If a certain value is not stored, it has to be collected from the RAM which takes much more time. On the other hand you might overwrite other valuable variables for example from the board structure or similar.
Concerning the number of processor cycles these two should be roughly the same.
ok well mine is an array of 32-bit integers, since java requires array indexes to be integers, if you try to use bytes as indexes it will upcast to integer format before using as an index, so I figure may as well store them that way.
Anyways, you say RAM storage not really the point. I hadn't considered aspects such as pollution of processor cache, that's not something I have taken into account, but now that you mention it, I'll be sure to consider it.
regards.
p.s. if you are saying that the cost of processor cache pollution possibly outweighs the cost of doing upcasting from 1-byte to 4-byte format for array indexing, then that is something worth knowing.
If you're actually worried about performance, using java is bad. Even if you wrote beautiful java code, your code will be slower.
With that in mind, I think it's much more important to write easy to maintain code since you've already lost the performance race before it started.
Fguy64 wrote:It's not clear to me why memory footprint should be an issue in this case, since the memory is allocated only once when the program is initialized. An array like this shouldn't take more than a few KB, no? Are you saying it would be slower with the static array than calculating knight moves on the fly?
64 (squares) x 8 (directions) = 512 bytes
That is not much compared with for example magic move generation method where all the moves are pregenerated and take around 838kb.
Anyway, it is always good practice to try to reduce the memory footprint as it pollutes the processor cache. If a certain value is not stored, it has to be collected from the RAM which takes much more time. On the other hand you might overwrite other valuable variables for example from the board structure or similar.
Concerning the number of processor cycles these two should be roughly the same.
ok well mine is an array of 32-bit integers, since java requires array indexes to be integers, if you try to use bytes as indexes it will upcast to integer format before using as an index, so I figure may as well store them that way.
Anyways, you say RAM storage not really the point. I hadn't considered aspects such as pollution of processor cache, that's not something I have taken into account, but now that you mention it, I'll be sure to consider it.
regards.
p.s. if you are saying that the cost of processor cache pollution possibly outweighs the cost of doing upcasting from 1-byte to 4-byte format for array indexing, then that is something worth knowing.
If you're actually worried about performance, using java is bad. Even if you wrote beautiful java code, your code will be slower.
With that in mind, I think it's much more important to write easy to maintain code since you've already lost the performance race before it started.
duly noted. I was just thinking about that. I think I've pretty much hit the wall with tweaking code to improve nodes per second, although there is plenty of useful work to be done when it comes to reducing the over all node count.
Anyways, the goal was really to learn java, and write the best java engine I can, rather than to write the best engine in any language. So efforts at improving performance have been useful in that context.
I think it's mostly pointless to focus on nodes per second until your engine is already very strong. It's good to have efficient data structures, of course, but raw nodes per second is much less important than good search and evaluation.
I've heard a rule of thumb here that says by doubling the nps of your engine its strength increases about 70 elo. If that's true, then according to CCRL Rybka would a 2900 elo engine even if it was 16 times slower. Even if that number is off, micro-optimizations will never be as important as sound algorithms.
There is zero cost in 'upcasting' from 1 to 4 byte. To do anything with variables the CPU has to load them from memory into a register first, and it simply has several flavors of load instructions for this, that are all equally fast (1->4 byte zero extend, 1->4 sign extend or load all 4 bytes from memory).
Aaron Becker wrote:I think it's mostly pointless to focus on nodes per second until your engine is already very strong. It's good to have efficient data structures, of course, but raw nodes per second is much less important than good search and evaluation.
I've heard a rule of thumb here that says by doubling the nps of your engine its strength increases about 70 elo. If that's true, then according to CCRL Rybka would a 2900 elo engine even if it was 16 times slower. Even if that number is off, micro-optimizations will never be as important as sound algorithms.
Thanks, If you mean that there are other things I can focus on at this stage that will have a much bigger effect on engine strength, then yeah, I suppose that is true.
thanks again to HG for that little tidbit of informaton o upcasting
Aaron Becker wrote:I think it's mostly pointless to focus on nodes per second until your engine is already very strong. It's good to have efficient data structures, of course, but raw nodes per second is much less important than good search and evaluation.
I've heard a rule of thumb here that says by doubling the nps of your engine its strength increases about 70 elo. If that's true, then according to CCRL Rybka would a 2900 elo engine even if it was 16 times slower. Even if that number is off, micro-optimizations will never be as important as sound algorithms.
My engine gets 100 knps on average on my computer. Before some modifications in the past, I had 300 knps on average. However, changes that made my evaluation more accurate and especially using checks in qsearch let the number rapidly drop. If I could get back to 300 knps without ruining my eval and throwing checks in qsearch out again, I'd on average get more than one iteration (with an EBF of <3) and about 70-80 Elo increase in playing strength, which would clearly be very helpful.
Lets say you have an A/B search with a branch factor of about 6. Lets say you search somewhere around a million nodes per second. That means the 10th ply of a search would take about 60 seconds to complete.
Would you rather double the speed of the engine or drop the branching factor from 6 to 5.5?
Well, doubling the speed gives you that 10th ply in 30 seconds. Reducing the branching factor to 5.5 gives you that 10th ply in 24 seconds. With each successive ply, the branching factor becomes more and more important relative to raw speed.
Of course, we want both, but generally with new engines, it's easier to shrink the branching factor a little bit than to speed the engine up a lot.
