[OpenIndiana-discuss] 32-bit and/or 64-bit programs (Was: Bash bug issue)

Tue Nov 11 09:39:17 UTC 2014

Some past comments about 32-bit vs. 64-bit and some recent test results.

Bob Friesenhahn <bfriesen at simple.dallas.tx.us>

> While it would be nice if Solaris software was all 64-bit, in actual
practice I notice no difference in day to day use between systems with
32-bit applications and 64-bit.  Only certain memory-hungry applications
will significantly benefit.

and

> The AMD64 ABI provides quite a lot more CPU registers than 32-bits. The
function calling convention has changed to make better use of registers for
passing values.  This places less stress on the CPU L1 cache and allows the
CPU to juggle more variables at once without doing loads/stores.
>
> In performance benchmarks, I do usually see a performance gain due to
compiling as 64-bits on x86 hardware.  Results are highly compiler
dependent.
>
> Regardless, most OS 'utilities' are not CPU bound and so the difference
may not be measurable for normal use.

david allan finch <david.allan at finch.org>

> We spent some time investigating this 10 years back and found that for
most apps that don't require the 64bit address space that they ran slower
compiled for 64bit. 64bit file access was of some us to us but the we stuck
with [32]bit compiles and I expect that until CPU cache sizes increase a
lot more there will be no gain outside the OS (and DBs etc) for 99% of
current apps.

Jim Klimov <jimklimov at cos.ru>

> Also note that 64-bit programs have a larger footprint in memory (bigger
pointers). While people might dismiss it today (saying all our boxes are
big anyway) - not all environments are big or get many benefits from such
over-use of resources. You have laptops, vm's, local zones...

I ran a test by building both 32-bit and 64-bit versions of Ted Faber's
grap from source ( http://www.lunabase.org/~faber/Vault/software/grap/ ).
I chose that because:
1. I use grap frequently, so needed to build it anyway.
2. I'm familiar with the program.
3. I had not expected any 32- vs. 64-bit issues based on looking at version
1.43 source, so this was originally intended as strictly a performance
test; however version 1.45 does nave support for using strptime and
strftime, so there is now an issue via time_t.  Grap is not particularly
"memory-hungry", and isn't a database application; in short, nothing to
bias performance in favor of 64-bits.
4. As the source distribution is based on autoconfigure et al, it
illustrates porting issues related to the unusual case of default 32-bit
builds on 64-bit Solaris.

Aside from "--prefix=/usr", the 32-bit build was a straight 'configure ;
make'.
The default configuration compiler options were "-g -O2", so for the 64-bit
build, I exported "CXXFLAGS=-g -O2 -m64" to the environment before
re-configuring for a fair comparison regarding optimization.  Build was on
an old desktop machine using an Intel Celeron 64-bit processor; single
core, small (256 kB!) cache, RAM maxed out at 4GB -- again nothing to
particularly favor 64-bits, and certainly not a "big box".
Strictly manual rebuild; automake etc. has no provision for building both
32-bit and 64-bit versions or for dealing with isaexec.

Executable sizes are interesting:
# file grap ; ls -l grap ; size grap
grap:           ELF 64-bit LSB executable AMD64 Version 1, dynamically
linked, not stripped
-rwxr-xr-x 1 root root 1690960 2014-11-07 23:44 grap
   text    data     bss     dec     hex filename
 353615    2104    5368  361087   5827f grap

and for the 32-bit version:
grap:           ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped
-rwxr-xr-x 1 root root 1576324 2014-11-11 03:50 grap
   text    data     bss     dec     hex filename
 294562   33973    2604  331139   50d83 grap

About 7% difference in overall size; 32-bit version has smaller text and
bss, larger data.

Simple test input to demonstrate 32-bit time_t issue:

# cat test.grap
.G1
frame invis
label bot strftime("%Y-%m-%dT%H:%M:%S", strptime("%Y-%m-%dT%H:%M:%S",
"2038-01-20T23:59:59"))
.G2

64-bit results unremarkable:
# grap test.grap | grep aligned
line invis "2038-01-20T23:59:59" aligned from Frame.Bottom.end + (0, -0.4)
to Frame.Bottom.start + (0, -0.4)

32-bit results show the critical time_t overflow issue:
# grap test.grap | grep aligned
line invis "1969-12-31T18:59:59" aligned from Frame.Bottom.end + (0, -0.4)
to Frame.Bottom.start + (0, -0.4)

That's broken, and is sufficient reason to build as 64-bits on 64-bit
hardware.

I ran 3 passes with 32- and 64-bit versions using the distributed example /
regression input ( examples/example.ms in the source distribution) and
timed the runs; there was a fairly consistent speed benefit (real and user)
to the 64-bit build.
Some details of the version of grap built, the build platform, test
command, and results follow.

==> version <==
grap 1.45 compiled under SunOS 5.11
Fine comparsion limit: 2.22045e-16
Fine minimum value: 2.22507e-308
Coarse comparsion limit: 1e-06
Coarse minimum value: 1e-06
Report bugs to faber at lunabase.org
Documentation in /usr/share/doc/grap
Examples in /usr/share/examples/grap
Defines are in /usr/share/grap/grap.defines

==> isainfo <==
64-bit amd64 applications
        cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
32-bit i386 applications
        ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu

==> psrinfo <==
Status of virtual processor 0 as of: 11/07/2014 23:11:08
  on-line since 10/20/2014 18:46:23.
  The i386 processor operates at 2667 MHz,
        and has an i387 compatible floating point processor.

==> command <==
/usr/bin/time -p ksh -c '../grap -d ../grap.defines example.ms > /dev/null'

==> time.32.0 <==
grap:           ELF 32-bit LSB executable 80386 Version 1 [FPU],
dynamically linked, not stripped

==> time.32.1 <==

real 0.43
user 0.38
sys 0.03

==> time.32.2 <==

real 0.43
user 0.38
sys 0.03

==> time.32.3 <==

real 0.42
user 0.38
sys 0.03

==> time.64.0 <==
grap:           ELF 64-bit LSB executable AMD64 Version 1, dynamically
linked, not stripped

==> time.64.1 <==

real 0.34
user 0.30
sys 0.03

==> time.64.2 <==

real 0.37
user 0.31
sys 0.03

==> time.64.3 <==

real 0.35
user 0.30
sys 0.03

YMMV.