Re: [opensource-dev] 64 bit pointers

[Boroondas Gupte]

 [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
) or also to my suggested
fix ?

> 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
> ban

Re: [opensource-dev] 64 bit pointers

[Argent Stonecutter]

On 2010-10-24, at 15:44, Boroondas Gupte wrote:
>> 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.

This has nothing to do with the OS. In every environment I know, 32-bit is 
faster then 64 bit. Every environment but one.

That exception is intel's x86 and amd64 architecture.

That's because in the AMD extensions to the 64 bit architecture, AMD not only 
extended the instruction set to support 64 bit, but they quadrupled the size of 
the register file. The biggest problem that the intel architecture had was the 
tiny register file, so on x86 the 64-bit mode is MUCH MUCH easier to optimize 
for than the 32 bit mode.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges