On 21/02/18 12:11 PM, Norm Green wrote:
> On 2/21/2018 8:42 AM, Dennis Clarke wrote:
>> Pretty sure I have done builds and tests. In fact I am certain of it.
>
> If you added -xmemalign=8s to the SPARC compiler flags (as shown in one
> of your emails from yesterday) then you would not see the problem.
> -xmemalign=8s forces the compiler to use 8-byte alignment.
Which is correct way to do this on sparc systems. I am digging into the
whole build process to see what needs to be "hacked" at to get solid and
reasonable results. The real issue is compilers. Sorry but gcc just
won't do the right things on sparc and that isn't anyones fault.
This is where we could go down a deep dark hole. For the sake of
getting it out there we may as well just admit that the compilers that
are generally installed on Solaris systems were of the Forte flavour way
back when little dinosaurs were still roaming the datacenters and the
cost of the license was about $3000 or so. The acquisitions and rename
of everything happened for a while there and I am surprised no one at
Sun lost their little minds and called it the Java Enterprise C Compiler
because everything else had "Java" slapped on it. Regardless, the Forte
name went away and we then had "Sun Studio" which revved up until we
were able to compile the whole source code base with it and Solaris
"UNIX" was self hosted and self boot-strappable and time marched on. So
here we are today with Oracle Studio compilers and they are very very
good. At least on sparc they are. The concept of doing a compile for a
very specific machine class was dropped on the market way back in 1999
or so and I think by 2002 we could target flavours of sparc v9 with the
vis instructions as well as a lot of hullabaloo about fused multiply
etc. However that was a sun4c and sun4m issue back when we needed the
optional weitek coprocessor.
So anyways the "target" option was born out of necessity to get the
right opcodes for given sparc units. People had fights over the entire
x86 platform and Sun dropped it. Then picked it up again. Then built a
version for Itanium. Put that on a shelf and hid it. Buried it. Then
went back and released a general x86 version again. Madness. I had a sit
down coffee with the global manager for the "solaris" product and it is
history now but the compiler tools for x86 were never the same quality
as the sparc tools. Never have been. One needs to use "fpversion" to
get the correct target and cache line options but someone at Oracle has
spilled a coffee and shuffled papers and forgot to release fpversion in
the latest flavour of the Studio compilers. I will take a look on a big
new shiney M-class machine and see what is there but I can tell you that
the openssl binaries I build from sources are at least the same speed or
better than the ones shipped out by Oracle. For a given specific type of
machine and sparc target.
jupiter # /opt/developerstudio12.5/bin/fpversion
A SPARC-based CPU is available.
Kernel says main memory's clock rate is 1272.0 MHz.
Sun-4 floating-point controller version 0 found.
An UltraSPARC chip is available.
Use "-xtarget=sparc64viiplus -xcache=64/64/2:11264/256/11"
code-generation option.
Hostid = 0xBADCAFFE.
A much older system may say :
mimas $ /opt/solarisstudio12.4/bin/fpversion
A SPARC-based CPU is available.
Kernel says CPU's clock rate is 500.0 MHz.
Kernel says main memory's clock rate is 100.0 MHz.
Sun-4 floating-point controller version 0 found.
An UltraSPARC chip is available.
Use "-xtarget=ultra2e -xcache=16/32/1:256/64/1" code-generation option.
Hostid = 0xBADCAFFE.
Even more bizarre and older :
ns1_$ /opt/solarisstudio12.4/bin/fpversion
A SPARC-based CPU is available.
Kernel says CPU's clock rate is 360.0 MHz.
Kernel says main memory's clock rate is 90.0 MHz.
Sun-4 floating-point controller version 0 found.
An UltraSPARC chip is available.
Use "-xtarget=ultra2i -xcache=16/32/1:1024/64/1" code-generation option.
Hostid = 0xDEADBEEF.
I say "bizarre" because that is a system that uses the memory options
which were shipped on the E10k servers and those cache lines are wrong.
That machine will always report "infinite" performance from openssl
speed results and be damned if I can figure out why. Yet.
ns1_$ /usr/local/ssl/bin/openssl speed rsa4096
Doing 4096 bit private rsa's for 10s: 13 4096 bit private RSA's in 0.00s
Doing 4096 bit public rsa's for 10s: 1436 4096 bit public RSA's in 0.00s
OpenSSL 1.0.2n 7 Dec 2017
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(ptr,risc1,16,int) aes(partial)
idea(int) blowfish(ptr)
compiler: /opt/solarisstudio12.4/bin/c99 -I. -I.. -I../include -KPIC
-DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -Xc -g -errfmt=error -erroff=%none -xmemalign=8s
-errshort=full -xstrconst -xildoff -m64 -xnolibmil -xcode=pic32
-xregs=no%appl -xlibmieee -ftrap=%none -xarch=sparc -mc -xs
-xbuiltin=%none -xdebugformat=dwarf -xunroll=1 -D_TS_ERRNO
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -DB_ENDIAN
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM
sign verify sign/s verify/s
rsa 4096 bits 0.000000s 0.000000s inf inf
However the latest from Oracle claims :
$ ls /opt/developerstudio12.6/bin/fpversion
/opt/developerstudio12.6/bin/fpversion: No such file or directory
However it is in the manual still.
Messy. Very.
So as I said earlier ... this should be fun.
Dennis
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
