Popcnrt is already there, no need for asm. https://www.freepascal.org/docs-html/rtl/system/popcnt.html Docs are there to help you..... There is no slowdown.Yes, exactly. If I use PopCnt RTL function - my algo runs in 15s.
Show us your code please :)One line, one place change PopCnt to GetBitCount.
No. You need the compiler options. Why can't you change them?Because I am talking about online judge.
In Lazarus you can add it to the compile options.
(Although such tests should be done with the raw compiler!!!)
Same code on same platform - Intel Xeon E3-1220 v5 (FPC 3.0.0 - I can't change compiler!)I think you should open a bug that the compiler does not inline the popcnt command for processors that have this capability.
Using RTL PopCnt - 15s.
Using ASM GetBitCount - 2.3s.
Please advice!
Thanks.
I think you should open a bug that the compiler does not inline the popcnt command for processors that have this capability.There is no bug. The default CPU type for x86_64 is Athon64 and those don't have POPCNT thus the generic code will be used. If the CPU type is set to something newer then the compiler will happily insert the instruction.
May be. But this does not explain strange behavior with if t <> 0 then t := PopCnt(t);I think you should open a bug that the compiler does not inline the popcnt command for processors that have this capability.There is no bug. The default CPU type for x86_64 is Athon64 and those don't have POPCNT thus the generic code will be used. If the CPU type is set to something newer then the compiler will happily insert the instruction.
May be. But this does not explain strange behavior with if t <> 0 then t := PopCnt(t);The comparison test is a single cycle on most cpu's , popcnt takes at least three, so testing for zero optimizes a little here.
Yes - a little, but not from 15s to 6.5s. It's impossible.May be. But this does not explain strange behavior with if t <> 0 then t := PopCnt(t);The comparison test is a single cycle on most cpu's , popcnt takes at least three, so testing for zero optimizes a little here.
Yes - a little, but not from 15s to 6.5s. It's impossible.May be. But this does not explain strange behavior with if t <> 0 then t := PopCnt(t);The comparison test is a single cycle on most cpu's , popcnt takes at least three, so testing for zero optimizes a little here.
@MathMan thank you for reply.Yes - a little, but not from 15s to 6.5s. It's impossible.May be. But this does not explain strange behavior with if t <> 0 then t := PopCnt(t);The comparison test is a single cycle on most cpu's , popcnt takes at least three, so testing for zero optimizes a little here.
Hi julkas - from my perspective it is very well possible, as the difference simply relates to the number of 0s detected. You seem to calculate the hamming distance over two arrays. If the arrays are held on heap and are not preset with random values prior to calculation then the run-time will be erratic, depending on the values found in the uninitialized heap. If your code uses variant arrays which get sized but again not preset prior to calculation then the array content is explicitely 0. There are other, more theoretical, explanations on the runtime difference.
Hi julkasHi, @MathMan!
No you do not only have one line of code (you popcnt function) which is relevant for your measurement. You must have some surrounding code where you initialize the the arrays a & b, do the popcnt loop over the arrays etc.
Without having seen this I can not comment on whether this is "normal" behaviour or not. Pls. show the complete, compilable program of your popcnt test.
BTW - this was indeed the first question to you at the beginning of this thread.
MathMan
Hi, @MathMan!
Link to the problem - https://www.spoj.com/problems/ADAFUROW/.
Regards.
Hi, @MathMan!
Link to the problem - https://www.spoj.com/problems/ADAFUROW/.
Regards.
Well, thanks. Unfortunately this doesn't help me to help you with your problem. Again - I can only judge if there is a real issue or everythings behaves as expected if you show me your compilable sources.
Regards,
MathMan