Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Vijay Chander]

Mike,
   I was native compiling on A72 (64 bit) using libgmp version 10.2.

   Thanks,
-vijay

On Feb 7, 2017 7:21 PM, "Mike Mohr"  wrote:

> Licensing issues are indeed thorny. Why can't openssl perform a dynamic
> link? The soversion should handle any ABI issues introduced in later
> versions of GMP.
>
> Are you cross compiling GMP for your use on a target device? If so, you'll
> need to ensure that the MPN_PATH is set appropriately. If you don't do so,
> you'll get the generic c code instead of optimized assembly routines. The
> performance difference can be dramatic, potentially several orders of
> magnitude. I had to deal with this myself when cross compiling GMP for
> Android.
>
> On Feb 7, 2017 4:51 PM, "Vijay Chander"  wrote:
>
> Yes. Already took Andy's word from his previous replies for precisely this
> reason.
>
> GMP exercise was easy enough to get it out of the way.
>
> Thanks,
> Vijay
>
> On Feb 7, 2017 4:46 PM, "Jakob Bohm"  wrote:
>
>> OpenSSL also has a lot of handwritten assembly language for ARM,
>> x86 etc.  Most of it written by Andy Polyakov.
>>
>> His response about what can and cannot be done on various ARM CPU
>> models is most probably a result of this work.
>>
>> Also, OpenSSL has a more permissive license than the GMP, so using
>> GMP in OpenSSL would cause problems for many OpenSSL using
>> applications.
>>
>> On 08/02/2017 00:31, Mike Mohr wrote:
>>
>>> Have you considered using GMP as a big integer backed for openssl?  It
>>> has support for several arm variants using handwritten assembly code
>>> and the developers go to great lengths to find optimize runtime on all
>>> supported platforms.
>>>
>>> On Feb 7, 2017 2:26 PM, "Vijay Chander" >> > wrote:
>>>
>>> Andy,
>>>1:2.5 is pretty in my opinion for ARM !
>>>
>>>We  will check out Mongoose.
>>>
>>>Hmm - will try to get to the bottom of those cache misses (at a
>>> lower priority).
>>>
>>> Thanks,
>>> -vijay
>>>
>>>
>>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov >> > wrote:
>>>
>>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should
>>> hopefully
>>> > get down to -1:5.
>>>
>>> And Mongoose will take you to ~1:2.5 (scaled to same frequency
>>> that is).
>>> Which I'd say is a fair result. Well, still could have been a bit
>>> better, but it's not unreasonable given ISA differences. Keep
>>> in mind
>>> that presented x86_64 result is for code utilizing
>>> Intel-specific code
>>> extensions.
>>>
>>> > There is no L3 cache on the A72 eval board and performance
>>> counters do
>>> > show 9x more DRAM accesses for ARM compared to x86.
>>>
>>> This is unexpected, because it takes *less* references to
>>> memory to
>>> perform it on ARMv8. Because it has larger register bank. And
>>> cache
>>> requirement is not that high for L3 to kick in... But at any
>>> case memory
>>> is not bottleneck here...
>>>
>>>
>>
>> --
>> Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
>> Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 > +4531131610>
>> This message is only for its intended recipient, delete if misaddressed.
>> WiseMo - Remote Service Management for PCs, Phones and Embedded
>>
>>
>> Enjoy
>>
>> Jakob
>> --
>> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
>> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
>> This public discussion message is non-binding and may contain errors.
>> WiseMo - Remote Service Management for PCs, Phones and Embedded
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Matt Caswell]

On 08/02/17 14:12, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
>> Behalf Of Mike Mohr Sent: Tuesday, February 07, 2017 22:21
> 
>> Licensing issues are indeed thorny. Why can't openssl perform a
>> dynamic link? The soversion should handle any ABI issues introduced
>> in later versions of GMP.
> 
> Replace "thorny" with "completely unacceptable" for at least some
> commercial users of  OpenSSL. And dynamic linking does not solve the
> problem, because customers would still have to get GMP. Some
> companies refuse to ship GPL code in any form, regardless of whether
> they've made modifications, and forcing customers to find and install
> GMP is hardly reasonable.
> 
> Providing TLS support in commercial software is already difficult
> enough. Let's not make it harder in the hypothetical hope of eking
> out a bit more performance.
> 
> Anyone who really wants GMP could implement it as an OpenSSL engine.
> That is, take the OpenSSL code for the algorithms you're using, copy
> them into an  engine, and then replace the BN math operations with
> calls to GMP.

FYI, there already *is* a GMP engine in 1.0.2. It got removed from 1.1.0
due to lack of use. It is not compiled by default. You have to use
"enable-gmp". Not tried it though.

Matt



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Mike Mohr
> Sent: Tuesday, February 07, 2017 22:21

> Licensing issues are indeed thorny. Why can't openssl perform a dynamic link? 
> The soversion should handle any ABI issues 
> introduced in later versions of GMP.

Replace "thorny" with "completely unacceptable" for at least some commercial 
users of  OpenSSL. And dynamic linking does not solve the problem, because 
customers would still have to get GMP. Some companies refuse to ship GPL code 
in any form, regardless of whether they've made modifications, and forcing 
customers to find and install GMP is hardly reasonable.

Providing TLS support in commercial software is already difficult enough. Let's 
not make it harder in the hypothetical hope of eking out a bit more performance.

Anyone who really wants GMP could implement it as an OpenSSL engine. That is, 
take the OpenSSL code for the algorithms you're using, copy them into an  
engine, and then replace the BN math operations with calls to GMP.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Salz, Rich via openssl-users]

> Licensing issues are indeed thorny. Why can't openssl perform a dynamic link? 
> The soversion should handle any ABI issues introduced in later versions of 
> GMP.

Anything is possible; it is just  code.

I don't think this is a priority for the team.  A pull request ...
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Mike Mohr]

Of course OpenSSL contains hand-optimized assembly routines.  However, GMP
has been around since at least 1993 and the library specifically targets
heavily optimized multiple precision arithmetic.  OpenSSL is a TLS/SSL
toolkit, and necessarily focuses on implementing SSL/TLS correctly - I'd
argue that the bigint subsystem is almost tangential to the other parts of
any SSL library.  A less optimized bigint subsystem should be reasonably
expected.  I would be surprised if the native bigint code could compete
against GMP performance-wise, even when OpenSSL's optimized assembly code
is used.  I haven't benchmarked OpenSSL's bigint subsystem and would be
interested in seeing a comparison against a correctly configured GMP.

On Tue, Feb 7, 2017 at 4:46 PM, Jakob Bohm  wrote:

> OpenSSL also has a lot of handwritten assembly language for ARM,
> x86 etc.  Most of it written by Andy Polyakov.
>
> His response about what can and cannot be done on various ARM CPU
> models is most probably a result of this work.
>
> Also, OpenSSL has a more permissive license than the GMP, so using
> GMP in OpenSSL would cause problems for many OpenSSL using
> applications.
>
> On 08/02/2017 00:31, Mike Mohr wrote:
>
>> Have you considered using GMP as a big integer backed for openssl?  It
>> has support for several arm variants using handwritten assembly code
>> and the developers go to great lengths to find optimize runtime on all
>> supported platforms.
>>
>> On Feb 7, 2017 2:26 PM, "Vijay Chander" > > wrote:
>>
>> Andy,
>>1:2.5 is pretty in my opinion for ARM !
>>
>>We  will check out Mongoose.
>>
>>Hmm - will try to get to the bottom of those cache misses (at a
>> lower priority).
>>
>> Thanks,
>> -vijay
>>
>>
>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > > wrote:
>>
>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should
>> hopefully
>> > get down to -1:5.
>>
>> And Mongoose will take you to ~1:2.5 (scaled to same frequency
>> that is).
>> Which I'd say is a fair result. Well, still could have been a bit
>> better, but it's not unreasonable given ISA differences. Keep
>> in mind
>> that presented x86_64 result is for code utilizing
>> Intel-specific code
>> extensions.
>>
>> > There is no L3 cache on the A72 eval board and performance
>> counters do
>> > show 9x more DRAM accesses for ARM compared to x86.
>>
>> This is unexpected, because it takes *less* references to
>> memory to
>> perform it on ARMv8. Because it has larger register bank. And
>> cache
>> requirement is not that high for L3 to kick in... But at any
>> case memory
>> is not bottleneck here...
>>
>>
>
> --
> Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10  +4531131610>
> This message is only for its intended recipient, delete if misaddressed.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Mike Mohr]

Licensing issues are indeed thorny. Why can't openssl perform a dynamic
link? The soversion should handle any ABI issues introduced in later
versions of GMP.

Are you cross compiling GMP for your use on a target device? If so, you'll
need to ensure that the MPN_PATH is set appropriately. If you don't do so,
you'll get the generic c code instead of optimized assembly routines. The
performance difference can be dramatic, potentially several orders of
magnitude. I had to deal with this myself when cross compiling GMP for
Android.

On Feb 7, 2017 4:51 PM, "Vijay Chander"  wrote:

Yes. Already took Andy's word from his previous replies for precisely this
reason.

GMP exercise was easy enough to get it out of the way.

Thanks,
Vijay

On Feb 7, 2017 4:46 PM, "Jakob Bohm"  wrote:

> OpenSSL also has a lot of handwritten assembly language for ARM,
> x86 etc.  Most of it written by Andy Polyakov.
>
> His response about what can and cannot be done on various ARM CPU
> models is most probably a result of this work.
>
> Also, OpenSSL has a more permissive license than the GMP, so using
> GMP in OpenSSL would cause problems for many OpenSSL using
> applications.
>
> On 08/02/2017 00:31, Mike Mohr wrote:
>
>> Have you considered using GMP as a big integer backed for openssl?  It
>> has support for several arm variants using handwritten assembly code
>> and the developers go to great lengths to find optimize runtime on all
>> supported platforms.
>>
>> On Feb 7, 2017 2:26 PM, "Vijay Chander" > > wrote:
>>
>> Andy,
>>1:2.5 is pretty in my opinion for ARM !
>>
>>We  will check out Mongoose.
>>
>>Hmm - will try to get to the bottom of those cache misses (at a
>> lower priority).
>>
>> Thanks,
>> -vijay
>>
>>
>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > > wrote:
>>
>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should
>> hopefully
>> > get down to -1:5.
>>
>> And Mongoose will take you to ~1:2.5 (scaled to same frequency
>> that is).
>> Which I'd say is a fair result. Well, still could have been a bit
>> better, but it's not unreasonable given ISA differences. Keep
>> in mind
>> that presented x86_64 result is for code utilizing
>> Intel-specific code
>> extensions.
>>
>> > There is no L3 cache on the A72 eval board and performance
>> counters do
>> > show 9x more DRAM accesses for ARM compared to x86.
>>
>> This is unexpected, because it takes *less* references to
>> memory to
>> perform it on ARMv8. Because it has larger register bank. And
>> cache
>> requirement is not that high for L3 to kick in... But at any
>> case memory
>> is not bottleneck here...
>>
>>
>
> --
> Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10  +4531131610>
> This message is only for its intended recipient, delete if misaddressed.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Vijay Chander]

Yes. Already took Andy's word from his previous replies for precisely this
reason.

GMP exercise was easy enough to get it out of the way.

Thanks,
Vijay

On Feb 7, 2017 4:46 PM, "Jakob Bohm"  wrote:

> OpenSSL also has a lot of handwritten assembly language for ARM,
> x86 etc.  Most of it written by Andy Polyakov.
>
> His response about what can and cannot be done on various ARM CPU
> models is most probably a result of this work.
>
> Also, OpenSSL has a more permissive license than the GMP, so using
> GMP in OpenSSL would cause problems for many OpenSSL using
> applications.
>
> On 08/02/2017 00:31, Mike Mohr wrote:
>
>> Have you considered using GMP as a big integer backed for openssl?  It
>> has support for several arm variants using handwritten assembly code
>> and the developers go to great lengths to find optimize runtime on all
>> supported platforms.
>>
>> On Feb 7, 2017 2:26 PM, "Vijay Chander" > > wrote:
>>
>> Andy,
>>1:2.5 is pretty in my opinion for ARM !
>>
>>We  will check out Mongoose.
>>
>>Hmm - will try to get to the bottom of those cache misses (at a
>> lower priority).
>>
>> Thanks,
>> -vijay
>>
>>
>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > > wrote:
>>
>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should
>> hopefully
>> > get down to -1:5.
>>
>> And Mongoose will take you to ~1:2.5 (scaled to same frequency
>> that is).
>> Which I'd say is a fair result. Well, still could have been a bit
>> better, but it's not unreasonable given ISA differences. Keep
>> in mind
>> that presented x86_64 result is for code utilizing
>> Intel-specific code
>> extensions.
>>
>> > There is no L3 cache on the A72 eval board and performance
>> counters do
>> > show 9x more DRAM accesses for ARM compared to x86.
>>
>> This is unexpected, because it takes *less* references to
>> memory to
>> perform it on ARMv8. Because it has larger register bank. And
>> cache
>> requirement is not that high for L3 to kick in... But at any
>> case memory
>> is not bottleneck here...
>>
>>
>
> --
> Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10  +4531131610>
> This message is only for its intended recipient, delete if misaddressed.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Jakob Bohm]

OpenSSL also has a lot of handwritten assembly language for ARM,
x86 etc.  Most of it written by Andy Polyakov.

His response about what can and cannot be done on various ARM CPU
models is most probably a result of this work.

Also, OpenSSL has a more permissive license than the GMP, so using
GMP in OpenSSL would cause problems for many OpenSSL using
applications.

On 08/02/2017 00:31, Mike Mohr wrote:

Have you considered using GMP as a big integer backed for openssl?  It
has support for several arm variants using handwritten assembly code
and the developers go to great lengths to find optimize runtime on all
supported platforms.

On Feb 7, 2017 2:26 PM, "Vijay Chander" > wrote:

Andy,
   1:2.5 is pretty in my opinion for ARM !

   We  will check out Mongoose.

   Hmm - will try to get to the bottom of those cache misses (at a
lower priority).

Thanks,
-vijay


On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > wrote:

> A72 is running 1GHz compared to x86 at 2.1Ghz. So that should 
hopefully
> get down to -1:5.

And Mongoose will take you to ~1:2.5 (scaled to same frequency
that is).
Which I'd say is a fair result. Well, still could have been a bit
better, but it's not unreasonable given ISA differences. Keep
in mind
that presented x86_64 result is for code utilizing
Intel-specific code
extensions.

> There is no L3 cache on the A72 eval board and performance
counters do
> show 9x more DRAM accesses for ARM compared to x86.

This is unexpected, because it takes *less* references to
memory to
perform it on ARMv8. Because it has larger register bank. And
cache
requirement is not that high for L3 to kick in... But at any
case memory
is not bottleneck here...




--
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 


This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Salz, Rich via openssl-users]

> Have you considered using GMP as a big integer backed for openssl?  It has 
> support for several arm variants using handwritten assembly code and the 
> developers go to great lengths to find optimize runtime on all supported 
> platforms.

It might be interesting if we could figure out how to handle it as a dynamic 
library.  License issues prevent anything else.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Vijay Chander]

Mike,
   Tried with GMP. Same result for A72.

   Thanks,
Vijay

On Tue, Feb 7, 2017 at 3:31 PM, Mike Mohr  wrote:

> Have you considered using GMP as a big integer backed for openssl?  It has
> support for several arm variants using handwritten assembly code and the
> developers go to great lengths to find optimize runtime on all supported
> platforms.
>
> On Feb 7, 2017 2:26 PM, "Vijay Chander"  wrote:
>
>> Have you considered using GMP as a big integer backed for openssl?  It
>> has support for several arm variants using handwritten assembly code and
>> the developers go to great lengths to find optimize runtime on all
>> supported platforms.
>>
>> On Feb 7, 2017 2:26 PM, "Vijay Chander"  wrote:
>>
>> Andy,
>>1:2.5 is pretty in my opinion for ARM !
>>
>>We  will check out Mongoose.
>>
>>Hmm - will try to get to the bottom of those cache misses (at a lower
>> priority).
>>
>> Thanks,
>> -vijay
>>
>>
>>
>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov  wrote:
>>
>>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully
>>> > get down to -1:5.
>>>
>>> And Mongoose will take you to ~1:2.5 (scaled to same frequency that is).
>>> Which I'd say is a fair result. Well, still could have been a bit
>>> better, but it's not unreasonable given ISA differences. Keep in mind
>>> that presented x86_64 result is for code utilizing Intel-specific code
>>> extensions.
>>>
>>> > There is no L3 cache on the A72 eval board and performance counters do
>>> > show 9x more DRAM accesses for ARM compared to x86.
>>>
>>> This is unexpected, because it takes *less* references to memory to
>>> perform it on ARMv8. Because it has larger register bank. And cache
>>> requirement is not that high for L3 to kick in... But at any case memory
>>> is not bottleneck here...
>>>
>>> --
>>> openssl-users mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>>
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Mike Mohr]

Have you considered using GMP as a big integer backed for openssl?  It has
support for several arm variants using handwritten assembly code and the
developers go to great lengths to find optimize runtime on all supported
platforms.

On Feb 7, 2017 2:26 PM, "Vijay Chander"  wrote:

Andy,
   1:2.5 is pretty in my opinion for ARM !

   We  will check out Mongoose.

   Hmm - will try to get to the bottom of those cache misses (at a lower
priority).

Thanks,
-vijay



On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov  wrote:

> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully
> > get down to -1:5.
>
> And Mongoose will take you to ~1:2.5 (scaled to same frequency that is).
> Which I'd say is a fair result. Well, still could have been a bit
> better, but it's not unreasonable given ISA differences. Keep in mind
> that presented x86_64 result is for code utilizing Intel-specific code
> extensions.
>
> > There is no L3 cache on the A72 eval board and performance counters do
> > show 9x more DRAM accesses for ARM compared to x86.
>
> This is unexpected, because it takes *less* references to memory to
> perform it on ARMv8. Because it has larger register bank. And cache
> requirement is not that high for L3 to kick in... But at any case memory
> is not bottleneck here...
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Vijay Chander]

Andy,
   1:2.5 is pretty in my opinion for ARM !

   We  will check out Mongoose.

   Hmm - will try to get to the bottom of those cache misses (at a lower
priority).

Thanks,
-vijay



On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov  wrote:

> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully
> > get down to -1:5.
>
> And Mongoose will take you to ~1:2.5 (scaled to same frequency that is).
> Which I'd say is a fair result. Well, still could have been a bit
> better, but it's not unreasonable given ISA differences. Keep in mind
> that presented x86_64 result is for code utilizing Intel-specific code
> extensions.
>
> > There is no L3 cache on the A72 eval board and performance counters do
> > show 9x more DRAM accesses for ARM compared to x86.
>
> This is unexpected, because it takes *less* references to memory to
> perform it on ARMv8. Because it has larger register bank. And cache
> requirement is not that high for L3 to kick in... But at any case memory
> is not bottleneck here...
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Andy Polyakov]

> A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully
> get down to -1:5.

And Mongoose will take you to ~1:2.5 (scaled to same frequency that is).
Which I'd say is a fair result. Well, still could have been a bit
better, but it's not unreasonable given ISA differences. Keep in mind
that presented x86_64 result is for code utilizing Intel-specific code
extensions.

> There is no L3 cache on the A72 eval board and performance counters do
> show 9x more DRAM accesses for ARM compared to x86.

This is unexpected, because it takes *less* references to memory to
perform it on ARMv8. Because it has larger register bank. And cache
requirement is not that high for L3 to kick in... But at any case memory
is not bottleneck here...

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Vijay Chander]

Thanks Andy.

A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully get
down to -1:5.
There is no L3 cache on the A72 eval board and performance counters do show
9x more DRAM accesses for ARM compared to x86.

Will check out Mongoose and Kyro.

Do you know of any good hardware crypto intellectual property like synopsis
for example which can help in asymmetric crypto part of TLS handshake ?

Thanks,

Vijay


On Feb 7, 2017 7:06 AM, "Andy Polyakov"  wrote:

>   Is big number montogomery multiplication as optimized as it can be for
> ARM64 as compared to X86-64 from the latest openssl github ?
>   We are not seeing vmull ( or pmull/pmull2) instructions in
> armv8-mont.pl .
>
>On an ARM cortex-A72 (1GHz)  and E5-2620 (2.1 Ghz)  we are seeing an
> order of 10 difference in RSA signing perf for 2048 bit keys.

When it comes to performance correct question actually is not what is
the result in absolute terms, but how far is it from possible maximum
for specific processor [taking into consideration all the factors from
ISA capabilities and specific hardware implementation]. So that implying
that 10x difference between processors in question is result of
insufficient optimization for one is somewhat unjustified. Well, to be
completely honest there are some minor tricks one can pull on ARMv8, but
it will only make the gap a *little* bit smaller. Or in other words suck
it up, that's the way Cortex [currently?] is. If it's so critical *and*
you're in position to choose processor, then Samsung Mongoose core would
be much better choice (but I don't know anything about Qualcomm Kryo).
Yet, even though it would be better choice, it still wouldn't actually
close the gap, so don't get your hopes too high :-)

As for not seeing vector instructions. Pmull[2] is about something
completely different. As for vmull you have to recognize that it's
limited by 32-bit inputs and there is no carry handling in vector
instructions. This means that it would take more instructions to do same
job, even though you perform pair of multiplications in one vector
instruction. Well, it's more complicated than just amount of
instructions, but nevertheless, scalar 64x64 multiplication with carry
processing offered by ARMv8 ISA does deliver better result than 128-bit
vector instructions would.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Andy Polyakov]

>   Is big number montogomery multiplication as optimized as it can be for
> ARM64 as compared to X86-64 from the latest openssl github ?
>   We are not seeing vmull ( or pmull/pmull2) instructions in
> armv8-mont.pl .  
>   
>On an ARM cortex-A72 (1GHz)  and E5-2620 (2.1 Ghz)  we are seeing an
> order of 10 difference in RSA signing perf for 2048 bit keys.

When it comes to performance correct question actually is not what is
the result in absolute terms, but how far is it from possible maximum
for specific processor [taking into consideration all the factors from
ISA capabilities and specific hardware implementation]. So that implying
that 10x difference between processors in question is result of
insufficient optimization for one is somewhat unjustified. Well, to be
completely honest there are some minor tricks one can pull on ARMv8, but
it will only make the gap a *little* bit smaller. Or in other words suck
it up, that's the way Cortex [currently?] is. If it's so critical *and*
you're in position to choose processor, then Samsung Mongoose core would
be much better choice (but I don't know anything about Qualcomm Kryo).
Yet, even though it would be better choice, it still wouldn't actually
close the gap, so don't get your hopes too high :-)

As for not seeing vector instructions. Pmull[2] is about something
completely different. As for vmull you have to recognize that it's
limited by 32-bit inputs and there is no carry handling in vector
instructions. This means that it would take more instructions to do same
job, even though you perform pair of multiplications in one vector
instruction. Well, it's more complicated than just amount of
instructions, but nevertheless, scalar 64x64 multiplication with carry
processing offered by ARMv8 ISA does deliver better result than 128-bit
vector instructions would.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users