Bruce Lilly wrote:
I ran a test by building both 32-bit and 64-bit versions of Ted Faber's
[...]
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.
We currently support 32 bit and 64 bit kernel. A bug fix needs to work on both 32 and 64 bit versions, so that would not be acceptable as a bug fix for this issue (if it was something you were trying to fix in the distro).
Applications which need to handle dates outside of the operating system time (such as dates of births, deaths, marriages, retirements, etc) shouldn't be using time_t -- that's very well established.
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.
Generally, 32 bit apps which are simply rebuilt as 64 bit (without being modified to explicitly make use of larger address space) run faster on x86 because of the extra registers available for compiler optimisation, and run slower on sparc because of the larger working set size.
However, there is very little in /usr/bin which is performance critical on any system, because these are not normally a significant part of any application, so optimizing for the performance of /usr/bin/* gets you almost no gains, and a lot of pain. The general philosophy has been to provide separate 64 bit versions only when essential for operation on 64 bit kernel or there's a performance or data capacity gain which is important for some specific application. In all other cases, 32 bit versions are used on both 32 bit and 64 bit kernels so we don't need to do two builds, two lots of testing, install two binaries, etc.
-- Andrew Gabriel _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
