After my talk on Friday a few people were discussing how 32 bit code can actually run slower on 64 bit uProcessors. (compared to a 32 bit uProcessor)
We discussed this is true but thankfully the linux community is working on this problem with the x32 ABI (Application Binary Interface): https://sites.google.com/site/x32abi/ http://linux.slashdot.org/story/13/12/24/2025228/linux-x32-abi-not-catching-wind The speed gains appear only slight and it does create a few overheads, well... and a new ABI to look after. << remember this coming from me, a guy that is experimental with "CFLAGS" (compile flags) for just a few % Speaking of "CFLAGS" , another person asked me what I was running for them on my Intel(R) Core(TM) i3-3120M Laptop? : CFLAGS="-march=corei7 -ftree-vectorize -funroll-all-loops -fprefetch-loop-arrays --param prefetch-latency=300 -O3 -fno-tree-pre -minline-all-stringops -pipe -mtune=corei7" (don't try these at home kids! Use them on the biggest mainframe you can find!) Oddly I am finding faster performance switching the AVX functions off with -march=corei7, they are supposedly enabled in my kernel: [ 0.724241] sha1_ssse3: Using AVX optimized SHA-1 implementation [ 0.724303] sha256_ssse3: Using AVX optimized SHA-256 implementation [ 0.724364] sha512_ssse3: Using AVX optimized SHA-512 implementation ..and test programs such as "nbench" are being compiled with 493 AVX instructions used when -march=corei7-avx or -march=core-avx-i is being used . Perhaps we need some sort of avx64 ABI to improve 128,256 and 512 bit AVX performance in later uProc's?....doh.... let's just nest the ABI's Brett -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
