[Pharo-project] SSL/HTTPS - SecureSocketStream/SSLSessionforPharo/Squeak and other Smalltalk implementations

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon May 16 09:51:47 CEST 2011


2011/5/16 David T. Lewis <lewis at mail.msen.com>:
> On Sat, May 14, 2011 at 01:13:29PM +0200, Nicolas Cellier wrote:
>> 2011/5/14 St?phane Ducasse <stephane.ducasse at inria.fr>:
>> >>>
>> >>
>> >> I accelerated raisedTo:modulo: a bit with a primitive
>> >> (http://bugs.squeak.org/view.php?id=7120) but that's not enough
>> > Nicolas
>> >
>> > do you know why it was not integrated?
>> > It is a good candidate to check the build system of the VM and their evolution.
>> > Igor (I gave the windows distribution) to the arnaud so I hope that soon we will get a new windows slave for jenkins.
>> >
>> > Stef
>> >
>>
>> Don't know.
>
> Nicolas,
>
> I added your LargeIntegersPlugin>>primMontgomeryTimes:modulo:mInvModB: in
> SqS/VMMaker/VMMaker-dtl.233 (interpreter VM only, not Cog), and added some
> notes to http://bugs.squeak.org/view.php?id=7120.
>
> It compiles and runs correctly on both 32 and 64 bit platforms, but I
> cannot confirm the performance gain, so examples or tests would be
> helpful.
>
> On my system I built 32 and 64-bit versions, and I can confirm that the
> primitive runs and that the results are as expected:
>
>  12345678907 raisedTo: 3 modulo: 12345678917 ==> 12345677917
>  12345678907 montgomeryRaisedTo: 3 modulo: 12345678917 ==> 12345677917
>
> But performance is not good in the example I came up with. On an
> interpreter VM (not Cog):
>
>  Time millisecondsToRun: [100000 timesRepeat: [12345678907 raisedTo: 3 modulo: 12345678917]] ==> 633
>  Time millisecondsToRun: [100000 timesRepeat: [12345678907 montgomeryRaisedTo: 3 modulo: 12345678917]] ==> 1415
>

Yes, there is a little overhead at method startup, so if the power is
small, there is no gain in using Montgomery.
You must increase the power.
Nonetheless, the results with classical VM were mitigated as I wrote
in the mantis issue with kind of random performance gains.

Note that the results are different with COG:

Time millisecondsToRun: [100000 timesRepeat: [12345678907 raisedTo: 3
modulo: 12345678917]] ==> 508
Time millisecondsToRun: [100000 timesRepeat: [12345678907
montgomeryRaisedTo: 3 modulo: 12345678917]]  ==> 646

And when we increase the power, Montgomery generally wins by about a factor 2:

Time millisecondsToRun: [10000 timesRepeat: [12345678907 raisedTo:
30000 modulo: 12345678917]]   ==> 534
Time millisecondsToRun: [10000 timesRepeat: [12345678907
montgomeryRaisedTo: 30000 modulo: 12345678917]]    ==> 255

Nicolas

>>
>> Don't know. I also have my modest bitShift: improvments pending
>> (http://bugs.squeak.org/view.php?id=7109).
>> Maybe I haven't performed enough tests to assert the performance gain.
>> The changes are reliable, I run a VM with both improvments without
>> crash for months.
>
> I have not looked at http://bugs.squeak.org/view.php?id=7109 yet but
> will do so.
>
> Dave
>
>
>



More information about the Pharo-project mailing list