Some past comments about 32-bit vs. 64-bit and some recent test results. Bob Friesenhahn <bfrie...@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.al...@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 <jimkli...@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 fa...@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. _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
