we do builds of amd64, but they are not tested in any way. Primarly, this is because:

(1) given the nature of the software, LinuxMCE doesn't need the extended address space offered by 64-bit address spaces.(2) the performance increase offered by 64-bit accelleration has been nominally less than 7% over the 32 bit build.

Given this, the incompatibilities, and additional bugs resulting from improperly written third party software, doesn't justify us with our small build team to maintain a 64-bit build for public consumption at this time.

To address this specifically - all Intel/AMD/etc x86_64 (actually known as AMD64 now) chips are also 32 bit chips. That is unlikely to change any time soon.

The nomenclature now is:

i386 = 32 bit mode (not a 32 bit chip, as such, and the brand is irrelevant, it is still called i386)AMD64 = 64 bit mode (not a 64 bit chip, as such, and the brand is irrelevant, it is still called AMD64)

I have been running the 64 bit version for over a year now. ... next install I do I am going back to 32 bit since it is better supported. Getting ready to build a new core this week. I want to be able to use MAME in the near future. 64 bit seems somewhat flakey from time to time. I am sure my wife will like me better when I am not having to fidget with my core all the time.

I've been running the 64bit version for about a year now too. I've had some stability and performance issues with Samba amongst other things. Next release I plan on moving to 32bit. However, 64bit is the direction that most software platforms are moving due to memory limitations at the 32bit level. PAE will allow 32bit to survive for a while but at some point it would seem this project will have to move to 64bit.

The vast majority of computing problems DO NOT NEED THE EXTENDED ADDRESS SPACE OF 64-bits!

This is the BIG reason why the industry has been slow to move to it.

Given that:

(1) LinuxMCE is an I/O bound application, NOT a memory or CPU bound application(2) The I/O busses on x86 machines are downright PITIFUL, especially with their insanely asymmetrical front side bus design. I can only hope that someday the entire x86 and x86_64 architecture gets DUMPED for something more balanced in this department.(3) The memory consumption (and therefore by extrapolation the needed address space) of a media director has never gone beyond 1.5 GB when in full use.

In short, it's a plateau. A big one.

I am sick and tired of people thinking that bigger is always better, when they just puppet what the "pundits" shove down their throat, instead of actually studying the problem domain and determining if a solution is actually appropriate!

If you want a high performance core, 64-bit isn't going to help. You're better off literally trying to strengthen your I/O subsystem by either balancing it:

(1) vertically, more disks on a RAID, on a controller that can adequately transfer on the bus, to get your iowaits down.(2) horizontally, by pushing storage out to NASes on the network, and using a well balanced interconnect (good twisted pair cabling, good switch, good cards which try to offload data transfers as much as humanly possible)

while avoiding:

(1) disks which use host based transfer methods such as USB, which suck up ungodly amounts of CPU time in the form of iowait.(2) unbalanced memory configurations

So, unless our address space requirements shoot up considerably in the next 3 years, we're not going to actively support the 64-bit configuration any time soon.

I see where you coming from and I understand your reasoning, it is sound. However, I can't help feeling a little hammered by your last post, and I feel a little taken back by the harshness. It was not my intent to slam linuxMCE with the 64bit bat, and so I'm hoping that you anger wasn't directed straight at me.

However, to play devils advocate, though most current functions are I/O intensive there are things that could take conceivably more CPU and memory resources in the future. For example, UPNP services also allows for video encoding to resize video for clients. With HD recordings coming up in the future re-encoding the stream will be more intensive.

Glad to hear it. I know you have a lot invested in LinuxMCE and I'm sure it gets aggravating hearing the same question, requests, and even demands going around over and over.

PAE should allow for 64GB of memory allocation and there doesn't seem to be a cut off for 64/32 hybrid processors. So, it will be sometime before a turning point would be needed. In addition there are advantages to 32 bit. 64bit processing is to accommodate larger resource pools, but the bigger chunks take a little more time to process then the smaller 32bit chucks. So processing 32bit natively should be slightly faster.

In either case, I look forward to changing over to 32bit in the next release. I hope it clears up the stability issues I'm having.

Just to be clear (as I wasn't sure from your post whether you understood this point) - A processor running in 32 bit mode (on Linux) has a per process virtual address space limit of 3GB. Note: per process. In other words, the 4GB addressable space (3GB user + 1GB Kernel space) is for each single process, not the whole machine.

So if you had a machine with 32GB of physical RAM installed, and that machine happened to be running 10 heavy duty processes, each of which required 3GB of memory... that machine would happily run, and be utilising all of its RAM even though it is only running in 32bit mode!! In fact in this configuration it wouldn't even need to use swap! I just thought I should point that out because lots of people think that 32bit mode means a maximum of 4GB RAM useage over the whole machine, and that simply isn't true. It is the memory management module that needs to be able to address more than a 32bit physical address space (and they easily can), not the CPU's address bus itself. The CPU works within its 32bit virtual address space for the process that happens to be paged in at the time. The MMU then translates these virtual addresses into the physical addresses in the much larger (than 32bit) physical address space. Each time the CPU performs a context-switch from one process to the next, the MMU selects a new set of address translations appropriate for all the physical pages that the new process is using. This gives the appearance to the CPU that the 3GB space the previous process was using has just been removed from its universe, and a new 3GB data/code set suddenly appeared in its place, using the same addresses. (BTW, this is true of Windows machines, too, they work in the same way)

The point of all this is, the limitation is 3GB per process, and if you run top, you will see that the only process that tops even 1GB is DCERouter (because it also contains all the plugins). All the other processes are tiny. In fact a 3GB process would be extremely unusual.... certainly not anything we are likely ever to see in LinuxMCE. Perhaps if the process was a database engine and was caching a huge amount of the DB, or was a very heavy data processing/crunching application. But seriously unusual. And those types have a genuine need for 64bit processing.

BTW, all the CPUs we are talking about (Intel, AMD, etc) are 32/64 bit CPUs... anything you buy that is designed for Windows is going to be "i386"-style architecture as that is all Microsoft support and all of these are 32/64 bit.... Just because you see a CPU that describes itself as 64bit doesn't mean it isn't also 32bit... it is! The only 64bit-only chips are way outside what we are talking about (for Linux and Windows) such as the Itaniums and PowerPC, etc. This isn't going to change anytime soon, after all, we still have legacy 8 and 16 bit stuff! I agree with Thom, the sooner the world makes the break that should have been done decades ago, and dumps this seriously hamstringed architecture the better! Who remembers segmented address spaces?? urgh, and we still have legacy stuff for that!!!

Well, if you don't use PAE the system will not see RAM over 3GB, system wide. I did not know about a per-process limit, but I never really though about or investigated that aspect. I am and was aware of the current 32/64 bit processor offerings and the previous 64bit Itanium offerings. I appreciate your clarifications. The per-process limitations are interesting to know.