Related, the Lemaker Hikey dev board is a nice alternative for AMRv8/AARCH64. Its less than 1/4 of the price at $128 USD. http://www.amazon.com/dp/B01CNZ9GIQ.
2GB RAM and 8GB eMMC makes it very amicable to development. I use it for testing OpenSSL and Crypto++ on real hardware.
Having an ARMv8 with 2GB of RAM strikes me a bit like putting rocket engines on a bicycle. What's the use-case for using aarch64 with such tiny RAM where a 32-bit ARM will not do every bit as well? The key selling point of the Gigabyte board is that it'll take 128GB of standard ECC DIMMs. It is the first (and thus far only AFAICT) mass available standards-conforming ARM board that breaks out of the toy-server category.
In my use case, for OpenSSL and Crypto++, its about development and validation testing for the architecture. For us, 128 GB of RAM is overkill (though I would not turn it down).
The real hardware gets us out of Debian QEMU/Chroot's. We've had a few issues with the hand crafted assembly. We could not debug it because GDB was broken in the chroot. Moving to real hardware allowed us to debug the issues. We've also had troubles with -O3 and vectorization that seems to become more prevalent on real hardware.
I'm also told the multimedia stuff runs a little faster under ARMv8 because of the register width and vectorization, but I generally don't use those features.
ARM64 is currently a mild pain point for the beta-1 release of OpenSSL 1.1.0, and its directly because of the testing on that Hikey. See, for example, http://rt.openssl.org/Ticket/Display.html?id=4406&user=guest&pass=gu... and https://rt.openssl.org/Ticket/Display.html?id=4237&user=guest&pass=g....
In short, the processes and testing ensures folks like you don't have any troubles when you use the libraries on real servers :)
Jeff
On 2016-03-11 13:47, Jeffrey Walton wrote:
Related, the Lemaker Hikey dev board is a nice alternative for AMRv8/AARCH64. Its less than 1/4 of the price at $128 USD. http://www.amazon.com/dp/B01CNZ9GIQ.
2GB RAM and 8GB eMMC makes it very amicable to development. I use it for testing OpenSSL and Crypto++ on real hardware.
Having an ARMv8 with 2GB of RAM strikes me a bit like putting rocket engines on a bicycle. What's the use-case for using aarch64 with such tiny RAM where a 32-bit ARM will not do every bit as well? The key selling point of the Gigabyte board is that it'll take 128GB of standard ECC DIMMs. It is the first (and thus far only AFAICT) mass available standards-conforming ARM board that breaks out of the toy-server category.
In my use case, for OpenSSL and Crypto++, its about development and validation testing for the architecture. For us, 128 GB of RAM is overkill (though I would not turn it down).
The real hardware gets us out of Debian QEMU/Chroot's. We've had a few issues with the hand crafted assembly. We could not debug it because GDB was broken in the chroot. Moving to real hardware allowed us to debug the issues. We've also had troubles with -O3 and vectorization that seems to become more prevalent on real hardware.
I'm also told the multimedia stuff runs a little faster under ARMv8 because of the register width and vectorization, but I generally don't use those features.
ARM64 is currently a mild pain point for the beta-1 release of OpenSSL 1.1.0, and its directly because of the testing on that Hikey. See, for example, http://rt.openssl.org/Ticket/Display.html?id=4406&user=guest&pass=gu... and https://rt.openssl.org/Ticket/Display.html?id=4237&user=guest&pass=g....
In short, the processes and testing ensures folks like you don't have any troubles when you use the libraries on real servers :)
You make a most compelling argument. Thanks for this. :)
Gordan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/03/16 13:52, Gordan Bobic wrote:
On 2016-03-11 13:47, Jeffrey Walton wrote:
Related, the Lemaker Hikey dev board is a nice alternative for AMRv8/AARCH64. Its less than 1/4 of the price at $128 USD. http://www.amazon.com/dp/B01CNZ9GIQ.
2GB RAM and 8GB eMMC makes it very amicable to development. I use it for testing OpenSSL and Crypto++ on real hardware.
Having an ARMv8 with 2GB of RAM strikes me a bit like putting rocket engines on a bicycle. What's the use-case for using aarch64 with such tiny RAM where a 32-bit ARM will not do every bit as well? The key selling point of the Gigabyte board is that it'll take 128GB of standard ECC DIMMs. It is the first (and thus far only AFAICT) mass available standards-conforming ARM board that breaks out of the toy-server category.
In my use case, for OpenSSL and Crypto++, its about development and validation testing for the architecture. For us, 128 GB of RAM is overkill (though I would not turn it down).
The real hardware gets us out of Debian QEMU/Chroot's. We've had a few issues with the hand crafted assembly. We could not debug it because GDB was broken in the chroot. Moving to real hardware allowed us to debug the issues. We've also had troubles with -O3 and vectorization that seems to become more prevalent on real hardware.
I'm also told the multimedia stuff runs a little faster under ARMv8 because of the register width and vectorization, but I generally don't use those features.
ARM64 is currently a mild pain point for the beta-1 release of OpenSSL 1.1.0, and its directly because of the testing on that Hikey. See, for example, http://rt.openssl.org/Ticket/Display.html?id=4406&user=guest&pass=gu...
st
and
https://rt.openssl.org/Ticket/Display.html?id=4237&user=guest&pass=g...
est.
In short, the processes and testing ensures folks like you don't have
any troubles when you use the libraries on real servers :)
You make a most compelling argument. Thanks for this. :)
the other thing is - some level of standards... and enablement, docker and k8s on aarch64 is consistent across the entire armserver markets.
- -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
On 2016-03-11 15:00, Karanbir Singh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/03/16 13:52, Gordan Bobic wrote:
On 2016-03-11 13:47, Jeffrey Walton wrote:
Related, the Lemaker Hikey dev board is a nice alternative for AMRv8/AARCH64. Its less than 1/4 of the price at $128 USD. http://www.amazon.com/dp/B01CNZ9GIQ.
2GB RAM and 8GB eMMC makes it very amicable to development. I use it for testing OpenSSL and Crypto++ on real hardware.
Having an ARMv8 with 2GB of RAM strikes me a bit like putting rocket engines on a bicycle. What's the use-case for using aarch64 with such tiny RAM where a 32-bit ARM will not do every bit as well? The key selling point of the Gigabyte board is that it'll take 128GB of standard ECC DIMMs. It is the first (and thus far only AFAICT) mass available standards-conforming ARM board that breaks out of the toy-server category.
In my use case, for OpenSSL and Crypto++, its about development and validation testing for the architecture. For us, 128 GB of RAM is overkill (though I would not turn it down).
The real hardware gets us out of Debian QEMU/Chroot's. We've had a few issues with the hand crafted assembly. We could not debug it because GDB was broken in the chroot. Moving to real hardware allowed us to debug the issues. We've also had troubles with -O3 and vectorization that seems to become more prevalent on real hardware.
I'm also told the multimedia stuff runs a little faster under ARMv8 because of the register width and vectorization, but I generally don't use those features.
ARM64 is currently a mild pain point for the beta-1 release of OpenSSL 1.1.0, and its directly because of the testing on that Hikey. See, for example, http://rt.openssl.org/Ticket/Display.html?id=4406&user=guest&pass=gu...
st
and
https://rt.openssl.org/Ticket/Display.html?id=4237&user=guest&pass=g...
est.
In short, the processes and testing ensures folks like you don't have
any troubles when you use the libraries on real servers :)
You make a most compelling argument. Thanks for this. :)
the other thing is - some level of standards... and enablement, docker and k8s on aarch64 is consistent across the entire armserver markets.
Sort of. Maybe. See previous discussion on this thread about page sizes.
On Fri, Mar 11, 2016 at 03:00:13PM +0000, Karanbir Singh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/03/16 13:52, Gordan Bobic wrote:
On 2016-03-11 13:47, Jeffrey Walton wrote:
Related, the Lemaker Hikey dev board is a nice alternative for AMRv8/AARCH64. Its less than 1/4 of the price at $128 USD. http://www.amazon.com/dp/B01CNZ9GIQ.
2GB RAM and 8GB eMMC makes it very amicable to development. I use it for testing OpenSSL and Crypto++ on real hardware.
Having an ARMv8 with 2GB of RAM strikes me a bit like putting rocket engines on a bicycle. What's the use-case for using aarch64 with such tiny RAM where a 32-bit ARM will not do every bit as well? The key selling point of the Gigabyte board is that it'll take 128GB of standard ECC DIMMs. It is the first (and thus far only AFAICT) mass available standards-conforming ARM board that breaks out of the toy-server category.
In my use case, for OpenSSL and Crypto++, its about development and validation testing for the architecture. For us, 128 GB of RAM is overkill (though I would not turn it down).
The real hardware gets us out of Debian QEMU/Chroot's. We've had a few issues with the hand crafted assembly. We could not debug it because GDB was broken in the chroot. Moving to real hardware allowed us to debug the issues. We've also had troubles with -O3 and vectorization that seems to become more prevalent on real hardware.
I'm also told the multimedia stuff runs a little faster under ARMv8 because of the register width and vectorization, but I generally don't use those features.
ARM64 is currently a mild pain point for the beta-1 release of OpenSSL 1.1.0, and its directly because of the testing on that Hikey. See, for example, http://rt.openssl.org/Ticket/Display.html?id=4406&user=guest&pass=gu...
st
and
https://rt.openssl.org/Ticket/Display.html?id=4237&user=guest&pass=g...
est.
In short, the processes and testing ensures folks like you don't have
any troubles when you use the libraries on real servers :)
You make a most compelling argument. Thanks for this. :)
the other thing is - some level of standards... and enablement, docker and k8s on aarch64 is consistent across the entire armserver markets.
Prior to real hardware, we were porting under QEMU with userspace emulation only + Ubuntu. Talk about slow builds. This thing is lightning fast comparatively.
Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iQEbBAEBAgAGBQJW4t19AAoJEI3Oi2Mx7xbt/vAH90agSUxmAEW+zHE0xYkfYL6x 3Y3LOsQmXn+L+P5JSeMqjWkBW1iLcUhf6u9afb7aDEUqYq2C58crYOlIJuDzOJ8S cyXCojXLp5OvPM8BpPSFhlqyMEeyYYoPquxzZzqwj1S8Cq8lCCqtOmokpiznsk+m qP4mR8nhFKPQIt/j3AbvxxNHeQ8BpohRmWf9zupseUhh4/+K3ZViyl3ZIJLtczuA 6pMZEfdGVSs9Ef6ZSQlpINwpclvlfF6rR1NSqK/oPigriL15VFf3XnFbiY0qyURN Wm9STSsnoaEo7CcuZG+08v811sDcsVHtYXmbH/ezRq3MMxkZQAA8rbUhuOzKYQ== =xRK1 -----END PGP SIGNATURE----- _______________________________________________ Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
In short, the processes and testing ensures folks like you don't have
any troubles when you use the libraries on real servers :)
You make a most compelling argument. Thanks for this. :)
the other thing is - some level of standards... and enablement, docker and k8s on aarch64 is consistent across the entire armserver markets.
Prior to real hardware, we were porting under QEMU with userspace emulation only + Ubuntu. Talk about slow builds. This thing is lightning fast comparatively.
+1.
I have a "test script from hell" as I call it. It takes about 4 hours to run on a modern PC, and it builds the libraries and runs the self tests under various configurations. Using QEMU, it would take 3 to 5days to run. Under a Hikey (ARM64) or Cubie Truck Plus (ARM32), it takes about 12 hours to run.
Jeff
-
Gordan Bobic -
Jeffrey Walton -
Jeremiah Rothschild -
Karanbir Singh