Hallo,
According to statprof, I am spending nearly 40% of my running time in lines which call 'board-ref', which is simply defined as:
(define board-ref u8vector-ref)
'u8vector-ref' seems a pretty low-level call, so I can't see how this can be improved further. It is just a macro around '##u8vector-ref'. Maybe using it directly instead of 'board-ref'? Or is this probably a memory alignment issue?
Cheers,
Afficher les réponses par date
On 2009-10-27, at 9:54 AM, Alex Queiroz wrote:
Hallo,
According to statprof, I am spending nearly 40% of my runningtime in lines which call 'board-ref', which is simply defined as:
(define board-ref u8vector-ref)
'u8vector-ref' seems a pretty low-level call, so I can't see how this can be improved further. It is just a macro around '##u8vector-ref'.
That's hard to believe... If u8vector-ref is really a *macro* you can't use "define" to set board-ref to that macro.
You'd need:
(define-macro (board-ref v i) `(u8vector-ref ,v ,i))
Alternatively, don't use a macro for u8vector-ref and give the declarations (declare (extended-bindings) (block)) so that the compiler can inline u8vector-ref (my guess is that your code is actually doing a procedure call to u8vector-ref, which will be slow).
When in doubt, use the -expansion option to gsc to see what is inlined. If you are in serious doubt, use the -gvm option to view the GVM code produced (.gvm file). If you can't believe what is happening, use the -keep-c option to get the .c file and see if it is calling the ___U8VECTORREF C macro. If the execution of the program contradicts the laws of physics, send email to Brad Lucier.
Marc
Hallo,
On 10/27/09, Marc Feeley feeley@iro.umontreal.ca wrote:
When in doubt, use the -expansion option to gsc to see what is inlined. If you are in serious doubt, use the -gvm option to view the GVM code produced (.gvm file). If you can't believe what is happening, use the -keep-c option to get the .c file and see if it is calling the ___U8VECTORREF C macro. If the execution of the program contradicts the laws of physics, send email to Brad Lucier.
Actually I am kind of speechless right now. I changed all uses of u8vector to u32vector, because of memory alignment issues on RISC machines, and my code tells me it is searching to ply 35 in this 2001's SPARC machine, which is hard to believe. I need to investigate this further, and will look at the generated C code.
Cheers,
Hallo,
On 10/27/09, Alex Queiroz asandroq@gmail.com wrote:
Actually I am kind of speechless right now. I changed all uses ofu8vector to u32vector, because of memory alignment issues on RISC machines, and my code tells me it is searching to ply 35 in this 2001's SPARC machine, which is hard to believe. I need to investigate this further, and will look at the generated C code.
I am replying to myself so as to set things straight. This "search" till ply 35 was obviously wrong, caused by a bug in the way I handled transposition tables. After fixing the bug, rewriting the transposition table code in C and porting a very hot function to C ("legal?", predicate for a legal move) my code searches 12 moves ahead in this same machine (UltraSPARC II). I still think that's pretty awesome, though.
Cheers,
Hallo,
On 10/27/09, Marc Feeley feeley@iro.umontreal.ca wrote:
When in doubt, use the -expansion option to gsc to see what is inlined. If you are in serious doubt, use the -gvm option to view the GVM code produced (.gvm file). If you can't believe what is happening, use the -keep-c option to get the .c file and see if it is calling the ___U8VECTORREF C macro. If the execution of the program contradicts the laws of physics, send email to Brad Lucier.
I am using these declarations:
(declare (safe) (block) (fixnum) (inline-primitives) (standard-bindings) (extended-bindings) (not run-time-bindings))
But I cannot find U32VECTORREF in the code. I see calls to S16VECTORREF, though, so probably the former macro has a different name?
Cheers,
On 2009-10-27, at 12:20 PM, Alex Queiroz wrote:
I am using these declarations:(declare (safe) (block) (fixnum) (inline-primitives) (standard-bindings) (extended-bindings) (not run-time-bindings))
But I cannot find U32VECTORREF in the code. I see calls to S16VECTORREF, though, so probably the former macro has a different name?
You need (not safe), otherwise (u32vector-ref v i) will not be transformed into (##u32vector-ref v i) which is inlinable and fast. If you had used a u8 or u16 primitive, then some inlining would have occurred (including the range check for the index).
Marc
-
Alex Queiroz -
Marc Feeley