<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">The --cpuprofile option doesn't seem to generate a human-readable file and my go-fu is weak, but I've attached it anyway.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 3, 2017 at 9:18 PM, Jeremy Linton <span dir="ltr"><<a href="mailto:jlinton@redhat.com" target="_blank">jlinton@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On 01/01/2017 11:57 AM, Gordan Bobic wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not much of a Go user at the best of times, but I am noticing that<br>
there seems to be a huge ( > 10x clock-for-clock) performance<br>
discrepancy between x86-64 and aarch64 binaries.<br>
<br>
Specific example I am looking at is rclone, uploading encryoted backups<br>
to Amazon Cloud Drive.<br>
<br>
When I run it on a Westmere class Xeon (3.6GHz), it is comsuming about<br>
2% CPU to saturate a 20Mbit uplink. When I run it on an X-Gene (2.0GHz),<br>
it is consuming about 50% CPU. Even adjusting for differences in clock<br>
speeds, this seems to be a huge difference.<br>
<br>
Is the Go complier known to produce very poor results on aarch64, or is<br>
something else in play? I know that x86-64 has a much more powerful SIMD<br>
unit, but I am not convinced that this is the explanation, and rclone<br>
doesn't use AES AFAIK, so hardware implementation of that doesn't seem<br>
to explain it either.<br>
</blockquote>
<br>
AFAIK, amazon drive uses SSL/TLS so its likely you are using AES. Further, go implements their own TLS/etc libraries rather than depending on openSSL/gnuTLS. So, while ARMv8 cores have hardware AES instructions, go's AES implementation is currently only hardware accelerated on x86 and s390. MD5 (also used AFAIK) is also missing an ARM64 native implementation even though there is an ARM one. So, just those two issues could cause a large performance delta, but at those data rates it seems possible there is something else going on.<br>
<br>
So, a couple questions, did you build rclone yourself or use one of the binaries from <a href="http://rclone.org" rel="noreferrer" target="_blank">rclone.org</a>?<br>
<br>
There is a --cpuprofile option to rclone. It might be helpful if you can post the output from that.<br>
<br>
Thanks,<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
At general purpose pointer chasing such as compiling, the X-Gene seems<br>
to produce similar performance clock-for-clock as the Westmere Xeon, so<br>
the large discrepancy with rclone seems odd.<br>
<br>
Has anyone got any insights? Both machines are running CentOS 7.<br>
<br>
Gordan<br>
<br>
<br>
______________________________<wbr>_________________<br>
Arm-dev mailing list<br>
<a href="mailto:Arm-dev@centos.org" target="_blank">Arm-dev@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/arm-dev" rel="noreferrer" target="_blank">https://lists.centos.org/mailm<wbr>an/listinfo/arm-dev</a><br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Arm-dev mailing list<br>
<a href="mailto:Arm-dev@centos.org" target="_blank">Arm-dev@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/arm-dev" rel="noreferrer" target="_blank">https://lists.centos.org/mailm<wbr>an/listinfo/arm-dev</a><br>
</blockquote></div><br></div>
</div><br></div>