32-bits vs 64-bits -- thoughts, issues, etc.

[DrJ]

(this thread has been split off from http://forums.freebsd.org/showthread.php?t=4873)

How severe is the performance penalty of running i386 binaries on amd64? I am soon going to be putting together a new box, and I assumed that I would run amd64 for the added addressing space. I had thought that the speed penalty would be overwhelmingly compensated by the increase in speed (from a seven-year-old dual Athlon to some flavor of quad core).

Is that not true? Are there other "gotchas" with amd64? I don't need Wine, but I will need VBox, Flash, Acroread, Java and the usual other stuff.

 

[wonslung]

How severe is the performance penalty of running i386 binaries on amd64? I am soon going to be putting together a new box, and I assumed that I would run amd64 for the added addressing space. I had thought that the speed penalty would be overwhelmingly compensated by the increase in speed (from a seven-year-old dual Athlon to some flavor of quad core).

Is that not true? Are there other "gotchas" with amd64? I don't need Wine, but I will need VBox, Flash, Acroread, Java and the usual other stuff.

there is java, flash works via linux compat, i haven't tried vbox yet...theres no nvidia graphics drivers for amd64, not the 3-D ones at least (theres the normal desktop nv driver)
I run it on 2 desktops and it runs well enough for me. But in all honesty 32 bit runs really well too.

The main reason i used AMD64 was because i was learning ZFS and i really liked the idea of snapshots, it works in 32 bit as well but i read it was better in amd64 so i tried that.

 

[DrJ]

Right -- that much I know. But it would seem that you need to keep separate 32 and 64 bit binaries; how are the various library calls handled? With separate libraries? Any issue with managing those? Or is it pretty transparent? And do you need a 32-bit Firefox (for example) to use the plugins? Not that these is anything particularly wrong with that.

 

[Oko]

Right -- that much I know. But it would seem that you need to keep separate 32 and 64 bit binaries; how are the various library calls handled? With separate libraries? Any issue with managing those? Or is it pretty transparent? And do you need a 32-bit Firefox (for example) to use the plugins? Not that these is anything particularly wrong with that.

Doc, let me be straight with you. I have not used amd64 version of FreeBSD so I can say only talk about OpenBSD version. OpenBSD is fully 64-bit OS on amd64. That in practical terms means that you will not be able to use any 32 bit binaries. OpenBSD doesn't have linux emul on amd64 so you wouldn't be able to use flash, win32-codes, or wine or more serious things like Maple, Mathematica, MatLab, Adobe reader. Java compiles on amd64 so you would be able to have JDK and JRE. The same goes for FreeMat, Maxima, Octave and similar.

Penalization on amd64 is not significant but it does exit for applications which are written with 32 bit in mind. It is offset by the fact that you can utilize 4Gb of RAM unlike i386 which can not see more than 3Gb in practical terms.

OpenBSD amd64 is fully functional and ready for prime time. My decision to stick with i386 was also based on the fact that from the maintenance point of view unless all your PCs (in my case probably close to dozen) are capable of running amd64 you are better off sticking with the single version of OS.

I do however have to worn everybody. Unless you are 100% sure that you will be mostly running 64 bit applications your life will be probably simpler if you stick with i386 at least for now.

 

[DrJ]

That in practical terms means that you will not be able to use any 32 bit binaries.

I assume you mean Linux binaries, right? You should be able to run a 32-bit version compiled on FreeBSD on 64-bit, right?

OpenBSD doesn't have linux emul on amd64 so you wouldn't be able to use flash, win32-codes, or wine or more serious things like Maple, Mathematica, MatLab, Adobe reader.

FreeBSD has amd64 versions of the linuxator, at least according to the ports page. So many of these concerns seem not to apply to Free. That leaves out Wine, but that's no issue for me.

Penalization on amd64 is not significant but it does exit for applications which are written with 32 bit in mind. It is offset by the fact that you can utilize 4Gb of RAM unlike i386 which can not see more than 3Gb in practical terms.

That's exactly it. I'm wavering between 4 cores and 8; it seems silly to have an 8-core (16 with HTT) computer that has 3GB of memory. For practical purposes, anything over 4 cores seems silly.

from the maintenance point of view unless all your PCs (in my case probably close to dozen) are capable of running amd64 you are better off sticking with the single version of OS.

This would be the first amd64 computer I have, but slowly I will move over as funds permit. The 32-bit ones can stay on Windows -- they are fine for everyday things, and my employees understand the system and software. The ones with Win7 and FreeBSD I want to migrate over. (I will retire an AMD 1500 system as part of the upgrade, though.)

 

[Oko]

I assume you mean Linux binaries, right? You should be able to run a 32-bit version compiled on FreeBSD on 64-bit, right?

Absolutely NOT. All applications have to be compiled on amd64 in order to be usable on amd64. Cross compilation is possible but as you know it is only for developers to introduce new architectures. That is not something that should be regularly practiced.

Still unless the developer have properly used 64 bits registers in the program you will be penalized by machine for executing such code on 64-bits even though it is compiled on amd64.

 

[DrJ]

Absolutely NOT. All applications have to be compiled on amd64 in order to be usable on amd64.

Ah -- that helps. And it is one difference from Vista (for example) where you practically have to run 32-bit browsers to use their plugins. So those reside in a separate directory, with their statically-linked libraries.

I'll have to look further into the FreeBSD linuxator. If it works with 32-bit code, then the situation might not be as severe as it is on Open. Even the Adobe Reader really is necessary. While the Poppler-based readers have improved a great deal, there are some files (primarily from TeX) tht just don't render properly. At least that is what I've found.

 

[DrJ]

Hmm. nspluginwrapper works on both i386 and amd64. So the plugins would seems to work on FreeBSD. That would seem to take care of most of it. That leaves nVidia, which I'd bet comes out in alpha form in a couple of months.

Admittedly this is a surface view, and things might not work as well in practice. Comments?

 

[Oko]

Ah -- that helps. And it is one difference from Vista (for example) where you practically have to run 32-bit browsers to use their plugins. So those reside in a separate directory, with their statically-linked libraries.

That is the 32 bit chroot (sendbox) on 64 bits that I was talking about. That is the "proper" way to run 32 bits binaries on 64 bit machine.

I'll have to look further into the FreeBSD linuxator. If it works with 32-bit code, then the situation might not be as severe as it is on Open. Even the Adobe Reader really is necessary. While the Poppler-based readers have improved a great deal, there are some files (primarily from TeX) tht just don't render properly. At least that is what I've found.

I would be really pleasantly surprised that linux emulator works
as good on amd64 as it does on i386. Check the user@netbsd for
horror stories.

 

[DrJ]

That is the 32 bit chroot (sendbox) on 64 bits that I was talking about. That is the "proper" way to run 32 bits binaries on 64 bit machine.

So can that be set up easily? I'm not that concerned about security -- this is a desktop, and not a server, and my internet habits are very well managed.

I would be really pleasantly surprised that linux emulator works as good on amd64 as it does on i386.

You may well be right. On Free, in particular because of all the work done on the linuxator recently (f9 and f10, for example). That of course overlooks the fundamental problem of mixing all these programs together in a manageable way.

 

[Oko]

Hmm. nspluginwrapper works on both i386 and amd64. So the plugins would seems to work on FreeBSD. That would seem to take care of most of it. That leaves nVidia, which I'd bet comes out in alpha form in a couple of months.

Admittedly this is a surface view, and things might not work as well in practice. Comments?

nspluginwrapper is open source code which can be compiled on amd64. Do not forget that flash is not open source. If there is no native 64-bits version of flash for Vista do you really think that there is a good 64-bits version for Linux?

I think, people are kidding themselves about amd64 and how wide spread are applications written for 64 bits.
On the another hand if the application is written for 64 bits it is going to out preform 32-bit application by a mile. Yes, that is the "future".
For the record SGI had fantastic 128 bit implementation of last versions of Irix if I remember correctly and they were even had implementation of 256 bit operating system and applications.

 

[Oko]

So can that be set up easily? I'm not that concerned about security -- this is a desktop, and not a server, and my internet habits are very well managed.

32 bit chroot on amd64 requires serious kernel hacking. I am not aware of any BSDs currently having any activity in that direction but I might be wrong. For OpenBSD, I am 100% sure that there is absolutely no interest for implementing something like that.

Linux emulator is on life support on OpenBSD. I think it will be gone soon. On the another hand there is significant work done on porting latest Wine to OpenBSD.

 

[DrJ]

nspluginwrapper is open source code which can be compiled on amd64. Do not forget that flash is not open source. If there is no native 64-bits version of flash for Vista do you really think that there is a good 64-bits version for Linux.

That right, of course. Oops! On the main Adobe site, there is no 64-bit version of either Reader or Flash. Wasn't there a buggy version of Flash that was released for Linux?

I think, people are kidding themselves about amd64 and how wide spread are applications written for 64 bits.
On the another hand if the application is written for 64 bits it is going to out preform 32-bit application by a mile. Yes, that is the "future".

This sure has been a slow transition. It seems like such a waste of good hardware.

 

[DutchDaemon]

*bump* to get thread-split noticed

 

[wonslung]

i think it depends on what you're doing. I've noticed better performance on amd64 on my quadcore with 8gb ram. I'm sure it's mostly due to the ram and 32 bit address space but for a lot of stuff it's noticeable, just not so much in the desktop area.

 

[DrJ]

*bump* to get thread-split noticed

Thanks -- I was just sending you a note requesting the thread split. Once again, you are fast!

 

[DrJ]

i think it depends on what you're doing.

That right, of course. And what exactly a "desktop" is is not clearly defined, either. To be specific, my intended application is to do the usual email/browsing/text processing/spreadsheets like the rest of the world. That includes Flash and Reader and codecs and stuff like that.

There are also applications that require Windows or OS X, like access to certain remote databases or flawless Word or WordPerfect compatibility. Those I have traditionally done in a VM (or on a Win Box). The old VMware worked just fine for these purposes, but it just is too old for today's hardware. That's one reason I've been testing VBox so extensively.

The next layer is that I work on a lot of big 2D images, and will be moving more into high-resolution videos (from photomicroscopy, FWIW). I also am getting ready to do some calculations that would be big on most people's scales, though they are small for OKO's. They will certainly exceed 3GB.

I had hoped that I could do all of that on one computer, and replace my very old desktop box. A 64-bit box would seem to be the way to go, if it could do these things. Perhaps I am being too optimistic, but that was the goal.

 

[Oko]

That right, of course. And what exactly a "desktop" is is not clearly defined, either. To be specific, my intended application is to do the usual email/browsing/text processing/spreadsheets like the rest of the world. That includes Flash and Reader and codecs and stuff like that.

There are also applications that require Windows or OS X, like access to certain remote databases or flawless Word or WordPerfect compatibility. Those I have traditionally done in a VM (or on a Win Box). The old VMware worked just fine for these purposes, but it just is too old for today's hardware. That's one reason I've been testing VBox so extensively.

The next layer is that I work on a lot of big 2D images, and will be moving more into high-resolution videos (from photomicroscopy, FWIW).

To be frank, I would use i386 for that. If for no other reason just be on the safe side. You want to spend time working not fixing things.

I also am getting ready to do some calculations that would be big on most people's scales, though they are small for OKO's. They will certainly exceed 3GB.

I had hoped that I could do all of that on one computer, and replace my very old desktop box. A 64-bit box would seem to be the way to go, if it could do these things. Perhaps I am being too optimistic, but that was the goal.

I agree on that one as long as the applications are native for FreeBSD and native for 64 bit architecture.

 

[wonslung]

i use freebsd 7.2 amd64 for my home media server desktop and laptop.

I have been thinking about trying it on my htpc's as well if i can get it to run xbmc well enough in 32 bit mode but i might stick with linux here for awhile simply because of the new nvidia drivers have hardware accel for xbmc which is great.

I have flash running no problem in amd64 via the linux compat mode
I haven't tried vmware or virtualbox yet but if they ran i'd be very happy.

for flash i used this guide http://crnl.org/blog/2008/11/01/flash-9-for-freebsd-71 though i didn't follow it 100%, i used f10 instead of f8 and i MIGHT have used flash10, i can't remember to be honest.

I know this, kde4 looks great on my laptop.

 

[DrJ]

I have flash running no problem in amd64 via the linux compat mode
I haven't tried vmware or virtualbox yet but if they ran i'd be very happy.

I've poked around a bit, and it seems that it is easier to get 32-bit Linux applications to run on amd64 than native FreeBSD ones. It is part of the linuxator.

So do the codecs and the Adobe reader all work? And do you use native 64-bit java, and can that execute with the plugins?

 

[DrJ]

To be frank, I would use i386 for that. If for no other reason just be on the safe side. You want to spend time working not fixing things.

I agree on that one as long as the applications are native for FreeBSD and native for 64 bit architecture.

Sounds like you would suggest two different boxes. Maybe it is time to set up a small cluster, and leave the desktop to the i386 world.

 

[vivek]

For desktop usage I will always go with 32bit operating systems, especially all multimedia stuff.

For server or dedicated router / nat / firewall there is no question - amd64 rules.

Also, freebsd 7.2 can run 32bit jails. So you can dump your desktop inside a jail (however, you have to relax /dev/ rules to get working linux stuff).

 

[Oko]

Also, freebsd 7.2 can run 32bit jails.

This is very interesting and important information. Am I hearing well Vivek that you are saying that 32 bit jail can be run on 64-bit amd64 on FreeBSD 7.2? Are you 100% sure? If that can be done that is very, very cool!

 

[DrJ]

Also, freebsd 7.2 can run 32bit jails.

I didn't know this, but it makes perfect sense. i386 in amd64 is a userland issue, and not a kernel issue. Setting it up in a jail would allow for a clean solution to this.

What exactly do you have to do with the dev rules? Can it be set up so that it is transparent in day-to-day use (maintaining it, primarily)?

 

[Oko]

I didn't know this, but it makes perfect sense. i386 in amd64 is a userland issue, and not a kernel issue. Setting it up in a jail would allow for a clean solution to this.

Doc it is more complicated. It is kernel issue as well. That being said, it is "correct" way to do it. I am still not 100% convinced. Can a developer or somebody who is using 32 bit Jail on amd63 confirm Vivek's statements?