[opensource-dev] 64 bit pointers

Boroondas Gupte sllists at boroon.dasgupta.ch
Sun Oct 24 13:44:19 PDT 2010


 [CCing opensource-dev as this could be of general interest.]

Hi Ponzu,

On 10/24/2010 07:07 PM, Ponzu wrote:
> Hi, 
>
> I noticed your jira about casting a pointer to a U32, and of course
> you are correct.
Thanks! Are you referring to only the bug report (CTS-323
<https://jira.secondlife.com/browse/CTS-323>) or also to my suggested
fix <http://bitbucket.org/boroondas/cts-323/changeset/d49a26895db9>?

> My question is why you would build a 64-bit viewer, anyway?  I am not
> a Linux guy, so let me ask, can a 64-bit kernel support a 32-bit
> application?
Yes, a 64-bit kernel can support 32-bit applications. In particular, all
of the following combinations usually work:

    * 32-bit CPU, 32-bit kernel, 32-bit   userland, 32-bit application (duh)
    * 64-bit CPU, 32-bit kernel, 32-bit   userland, 32-bit application
    * 64-bit CPU, 64-bit kernel, 32-bit   userland, 32-bit application
    * 64-bit CPU, 64-bit kernel, mulitlib userland, 32-bit application
      <--- this is the interesting case
    * 64-bit CPU, 64-bit kernel, mulitlib userland, 64-bit application
    * 64-bit CPU, 64-bit kernel, 64-bit   userland, 64-bit application
      (well, of course)

"Multilib" means that some important libraries are present on the system
in both, 32-bit and 64-bit versions. 32-bit application that only need
these libraries run fine on such systems. GStreamer's library however,
that are used by SL for streaming media on Linux, is on most multilib
distributions not one of these libraries, so 32-bit Second Life binaries
will run on these systems, but lack support for video and audio stream
playback.

If you want streaming media support, you're thus left with the following
options:

   1. Only run a 32-bit operating system (either 32-bit kernel, or
      64-bit kernel with 32-bit userland)
          * Though ... why did I buy 64-bit hardware, then?
   2. Run an additional 32-bit operating system for using SL
          * With dual-boot and a common /home on a separate partition,
            this is not too difficult.
          * ... but I'd rather just maintain one system ;-)
   3. Run SL in a 32-bit chroot or a 32-bit VM
          * SL is having performance problems as-is, adding a VM layer
            is probably not the best idea. (Yes, I know current VM
            technology can have very little overhead, but there's still
            some.)
          * Installing a fresh system is much less work than setting up
            a suitable chroot environment, so I'd rather go with option
            2 above
   4. Manually install a 32-bit GStreamer (probably in parallel to the
      64-bit GStreamer that might be needed by other applications)
          * Never tried this, but could imagine this to be a PITA until
            it works
   5. Build a 64-bit SLPlugin binary
          * Because 32-bit SL can talk to a 64-bit SLPlugin (and the
            64-bit SLPlugin can use 64-bit GStreamer alright) this would
            suffice to provide streaming media support
          * If I do this ... why not go with option 6 below and build
            the whole viewer? It's not much harder.
   6. Build SL myself (fixing any 64-bit specific problems, or get
      others to fix them if I can't do it myself)
   7. Use a TPV that provides 64-bit binaries

Because I like to change the viewer and am thus building myself anyway,
option 6 is the most attractive to me. (Building a 32-bit binary would
probably require to go with one of the options 1-3, i.e. do it in a
32-bit environment.)

Ideally, fixing the issues that creep up when building 64bit makes the
source more portable in a generic sense, so that we'd have less issues
left once we want to build on yet another platform. (Solaris? 
iPod/Phone/Pad/Whateva? maemo or meeGo? *BSD? Your favorite game console
platform? You're university's/company's HPC cluster (no dual boot
there!)? The Windows version of 2072 that'll only be available in
128-bit and 256-bit variants? Ok ... most not very realistic, but you
get the idea.)

> If so the 32-bit app will usually run faster.  They do in the HP-UX
> and Solaris environments, anyway.
I've never worked with these two UNIX systems, but I don't think this is
generally true. On Linux and Windows, a properly optimized 64-bit binary
should usually perform the same or better than a (also optimized) 32-bit
binary build from the same source. In a lot of cases the difference will
not be significant, but there are exceptions: Especially for
number-crunching (e.g. in scientific simulations) at high precision
64-bit binaries often outperform their 32-bit counterparts.

> The only good reason to build a 64-bit app is if the 4GB memory model
> makes things difficult, for example, processing LARGE HD images.
I only have 4GB of RAM (and another 4 swap), so that isn't my reason.
While SL is known to be memory hungry, if it hits 4GB we've probably
introduced another major memory leak.

> If longs and pointers are 64-bit, they take up twice the memory bus
> bandwidth, and they use twice as much register space in the CPU.
This is true and the increased size of binaries as well as RAM usage due
to bigger pointers are indeed sometimes noticeable (though almost never
significant compared to the total filesize / memory requirement). For
longs ... well, if the application doesn't benefit enough from the
increased value range to make up for the increased memory usage, you
should have used ints in the first place.  :-P

Cheers,
Boroondas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20101024/8d176dad/attachment.htm 


More information about the opensource-dev mailing list