[Vm-dev] 3 Bugs in LargeInteger primitives

Levente Uzonyi leves at elte.hu
Sat Sep 1 21:25:22 UTC 2012


On Sat, 1 Sep 2012, Nicolas Cellier wrote:

>
> Hi Stefan,
>
> I just tried on a stack VM (MacOSX core 2...), and I get different
> measurements, at most 3% penalty, not 20%
> If I rewrite bytecodePrimMultiply like this :
>
> bytecodePrimMultiply
> 	| rcvr arg result |
> 	<var: #result type: 'sqLong'>
> 	rcvr := self internalStackValue: 1.
> 	arg := self internalStackValue: 0.
> 	(self areIntegers: rcvr and: arg)
> 		ifTrue: [rcvr := objectMemory integerValueOf: rcvr.
> 				arg := objectMemory integerValueOf: arg.
> 				result := rcvr.
> 				result := result * arg.
> 				(result >= 16r-40000000 and: [result <= 16r3FFFFFFF]) ifTrue:
> 					[self internalPop: 2 thenPush: (objectMemory integerObjectOf: result).
> 					 ^self fetchNextBytecode "success"]]
> 		ifFalse: [...
>
> Then I get mini bench timing:
>
> ORIGINAL:
> [33*35] bench
> '8,470,000 per second.'
> '8,670,000 per second.'
>
> MODIFIED:
> '8,410,000 per second.'
> '8,370,000 per second.'

IMHO #bench has too high overhead for accurately measuring such simple 
operations. With a CogVM I get this:

[ 33 * 35 ] bench '40,000,000 per second.'.
[] bench '47,300,000 per second.'


Levente

>
> Though, I didn't used SSE or any 64 bits friendly instructions:
>
> line 6501
> 					result = result * arg;
> .loc 1 6501 0
> 	movl	-1404(%ebp), %eax
> 	movl	%eax, %edx
> 	sarl	$31, %edx
> 	movl	-2068(%ebp), %ecx
> 	imull	%eax, %ecx
> 	movl	-2072(%ebp), %ebx
> 	imull	%edx, %ebx
> 	addl	%ebx, %ecx
> 	mull	-2072(%ebp)
> 	addl	%edx, %ecx
> 	movl	%ecx, %edx
> 	movl	%eax, -2072(%ebp)
> 	movl	%edx, -2068(%ebp)
> 	movl	%eax, -2072(%ebp)
> 	movl	%edx, -2068(%ebp)
>
> So it certainly is un-optimal, but I'm sure we wouldn't notice any
> difference on a macro benchmark.
>
> Also, we could let the primitive use create a #signed64BitIntegerFor:
> result instead of falling back to normal send if we really want to
> favour performance over clean separation (after all, the primitive
> already know about Float, why not about LargeInteger...)
>
> Nicolas
>
> 2012/8/30 Stefan Marr <smalltalk at stefan-marr.de>:
>>
>> Hi:
>>
>> On 30 Aug 2012, at 01:14, Nicolas Cellier wrote:
>>
>>>
>>> See also http://code.google.com/p/cog/issues/detail?id=92 where I
>>> attached a fix for large int
>>> It's untested yet and to review carefully !
>>>
>>> As Stefan told, there is UB-reliance in SmallInteger primitives too,
>>> but I did not fix them.
>>> We should simply compute result as signed 64 bits as proposed by
>>> Stefan (except bitShift)
>>
>> This might be the simplest solution, but at least on the RoarVM I measured a significant performance impact on tight integer loops.
>> It's 20% according to my measurements.
>>
>> Might be something necessary to be considered.
>>
>> Best regards
>> Stefan
>>
>>
>> --
>> Stefan Marr
>> Software Languages Lab
>> Vrije Universiteit Brussel
>> Pleinlaan 2 / B-1050 Brussels / Belgium
>> http://soft.vub.ac.be/~smarr
>> Phone: +32 2 629 2974
>> Fax:   +32 2 629 3525
>>
>


More information about the Vm-dev mailing list