LinuxMCE Forums

General => Feature requests & roadmap => Topic started by: Cyber on August 06, 2009, 10:24:38 pm

Title: x86_64?
Post by: Cyber on August 06, 2009, 10:24:38 pm
As a complete newbie, is there any plan to support 64 bit OS?  I haven't used 32bit linux in about 6 years.  (Do Intel/AMD still routinely sell 32bit CPU's?)
Title: Re: x86_64?
Post by: tschak909 on August 06, 2009, 10:53:38 pm
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.

Unless you want to maintain it?

Title: Re: x86_64?
Post by: Cyber on August 06, 2009, 10:59:44 pm
Thankyou Thom,
Appreciate the prompt reply and can see the logic.  Beyond my abilities to maintain a 64bit version.  Will see if my CPU remembers how to run 32bit.
Title: Re: x86_64?
Post by: colinjones on August 07, 2009, 01:39:39 am
(Do Intel/AMD still routinely sell 32bit CPU's?)

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)
Title: Re: x86_64?
Post by: Cyber on August 07, 2009, 05:37:23 pm
Thom mentioned that you do AMD64 builds.  Where can I download these?  Do you have a link?
Title: Re: x86_64?
Post by: tschak909 on August 07, 2009, 05:59:18 pm
they are not publically available. you can build them yourself if you set up a builder. look in the wiki for Building LinuxMCE 8.10

Title: Re: x86_64?
Post by: fearingsept on August 07, 2009, 08:02:59 pm
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.
Title: Re: x86_64?
Post by: Enigmus on August 29, 2009, 08:56:35 pm
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.
Title: Re: x86_64?
Post by: tschak909 on August 29, 2009, 09:48:11 pm
Dude.... *shake-head*

64-bit is about address space.

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.

Title: Re: x86_64?
Post by: Enigmus on August 30, 2009, 12:04:55 am
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.
Title: Re: x86_64?
Post by: tschak909 on August 30, 2009, 01:18:53 am
nah, it wasn't aimed at you.

I've had to answer that question, a LOT, over the last two years.

And your rebuttal is an interesting possibility, but really, it comes down to code not only becoming 64-bit clean, but also takes advantage of 64-bit wide registers efficiently.

Title: Re: x86_64?
Post by: Enigmus on August 30, 2009, 01:53:03 pm
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.
Title: Re: x86_64?
Post by: colinjones on August 30, 2009, 11:45:51 pm

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!!!
Title: Re: x86_64?
Post by: Enigmus on September 03, 2009, 08:06:36 pm
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.