[Vm-dev] bitXor: is slower than - on Spur32 (MacOSX) r3684

[Eliot Miranda]

Hi Nicolas,

> On Apr 23, 2016, at 2:22 PM, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> Hi,
> for large integers (> 64 bits), a bitClear: implementation using bitXor: is faster than by using - indeed we don't have to care of carry.
> 
> {
> [(12398767868759866578644 bitOr: 567812564128976768553) - 567812564128976768553] bench.
> [(12398767868759866578644 bitOr: 567812564128976768553) bitXor: 567812564128976768553] bench.
> }
> #('3,480,000 per second. 288 nanoseconds per run.'
>  '4,950,000 per second. 202 nanoseconds per run.')
> 
> For large integers < 64 bits or small integers, I would expect sort of similar speed, but bitXor: is slower:
> 
> {
> [(1234 bitOr: 5678) - 5678] bench.
> [(1234 bitOr: 5678) bitXor: 5678] bench.
> }
> 
> #('170,000,000 per second. 5.88 nanoseconds per run.'
>   '133,000,000 per second. 7.53 nanoseconds per run.')
> 
> {
> [(12398767868754 bitOr: 5678125641253) - 5678125641253] bench.
> [(12398767868754 bitOr: 5678125641253) bitXor: 5678125641253] bench.
> }
> #('7,100,000 per second. 141 nanoseconds per run.'
> '5,110,000 per second. 196 nanoseconds per run.')
> 
> OK, (Smalltalk specialSelectors includes: #bitXor:) is false, but is it the sole explanation?


I expect so.  You can test the primitive performance by invoking both via perform:with:, using e.g. #== or #= as a control.

I would suggest using the VM profiler, which will show you immediately but
a) you need the latest VM to run it in Mac OS X
b) it is currently dog slow because it gets confused by CoreAUC which it thinks has a 2.5Mb text symbol in and spends all its time tallying it
c) somewhere along the line Morohic changes result in its UI hiding behind an alignment morph the size of the inner window which has to be manually removed
So I have done maintenance to do before it's usable.  I fixed the VM.  The rest will follow soon.