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

[Andrew Gabriel]

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