Talk me about 64 bit systems...

Suppose you just buy a new piece of computer, with 64 bit technology and everything you consider cool. And suppose you'd like to install a GNU/Linux system on it.

As you've got a 64 bit architecture, I think you should use a 64 bit distribution, right? Once you installed it, since the 32 bit instruction set should be still available, you should be able to run 32 bit applications as well.

The only thing that may prevent you to run it would be the use of shared libraries, since a 32 bit application could never dinamically load a 64 bit shared library...

Is there a leak in my reasoning?

You can use a 32 bit distribution, but why would you?

Well... I've just read this article: http://www.linuxforums.org/forum/linux-tutorials-howtos-reference-material/69585-should-you-choose-32-bit-64-bit-linux.html

And actually there seems no real reason to use a 64 bit distribution... so that why should I buy a 64 bit computer then? And most importantly, am I able to find a 32 bit computer here around?

>>2
Oh, I forgot... Never mind what I'm going to buy, I'm very curious to know if my reasoning is right.

>>3
No reason? How about the extra memory and some 64bit only applications.

Why would you buy a 32bit computer? 64bit Core2's work quite well in 32bit mode if you want to use them like that.

>>5
Ok... but don't you think that using it in 32 bit would be a kind of waste? That's why I'm asking if is it possible to run a 32 bit application on a 64 bit distro.

>>6
Yes, it would be slightly wasteful, but you will be able to benefit from the extra cores, and the extra speed that newer Core2 CPUs have.

A quick google search will tell you that you need ia32-libs to run 32bit code from a 64bit Linux OS.

As for the other OSes:
On 64bit Windows, it can emulate 32bit apps using the Wow64 layer, it works pretty well.
On 32bit Windows, you can natively(at full speed) virtualize 64bit OSes using your favorite virtualization suite such as vmWare (will only work if your CPU has native virtualization support).

This question belongs in /g/, why did you ask /prog/ about it?

>>7
Thanks for your answers and...

This question belongs in /g/, why did you ask /prog/ about it?
Basically because I trust /prog/ more than /g/, and because this question is expecially related to shared libraries.

Why don't just use Solaris?

Consider that most programs don't need an extra 32 bits for their computations (i.e. they work with values usually less than 4 billion), and that 64-bit code takes twice as much space for each immediate value (the upper 4 bytes always being 0), and you'll see that 64-bit is more of a waste. The only way I see it would be useful is if you need more than 64GB of RAM and/or 64-bit integers are needed in your programs -- enterprise or scientific computing applications are some examples of this.

>>10
Except that with x86, it's not just about the pointer size. The x86-64 architecture doubles the inventory of GPRs, which means that you don't have to push as many values to the stack when making function calls, which means that everything is suddenly a lot less cache-sensitive. In other words, the x86 -> x86-64 move is a specific case where, by sheer coincidence, everything does indeed get faster.

>>11
Except there's no software for it yet compared to x86 software.

>>12
There's some 64-bit only software, and for free software you can just build your own. For commercial ones, you may be lucky to get a 64-bit version from time to time.

>>13
lol free software is such shit

>>14
I blame you.

>>11
That's true, but it works only if the compiler that produces the code is smart enough to use this feature.

As ARM ASSEMBLY PROGRAMMER I know that there's a huge difference in performances between user-written assembly and compiler assembly... this is particulary true on ARM platform because of it's flexible instruction set.

Don't change these.

Name:		Email:
Entire Thread Thread List