On Jul 5, 2014, at 21:45 , Gerriet M. Denkmann <email@hidden> wrote:
And here is my Swift code:
A couple of comments:
— There’s no really obvious (in the sense of “caused by the source code”) reason why it should be so much slower. I’d be inclined to look at the assembly output and see if something voluminous leaps out at you.
— You’re doing a micro-benchmark. As has been noted many times in the past, micro-benchmarks are pretty much useless at telling you anything except how the micro-benchmark behaves.
— Jens already pointed out the possible effect of array bounds checking. I wonder also if there’s any penalty for overflow checking, in the architecture you’re building for. You could try using ‘&+’ instead of ‘+’, etc.
— Your micro-benchmark isn’t very well controlled, at least in the form you’ve shown here. What if the much longer execution path contains a dynamic library load, or something expensive and unrelated like that? Is the elapsed time related to the number of iterations in any meaningful way?
— CFBitVector might help, but you’d be replacing either (a) an array lookup or (b) a simple shift by a function call into the frameworks. It seems to me that would defeat the purpose of the mask array completely, unless the cost of the real (b) operation were much greater.
That’s why micro-benchmarks are of so little value. There’s no *real* problem being investigated here.
However, the relative slowness is so gross that it would be interesting to know what’s causing it.
|