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