Fedora Linux May Further Demote i686 Support

[duby229]

You don't need 64-bit to use more than 4GB of RAM. Thats been the cause since the Pentium Pro (1995) and the introduction of Physical Address Extension. Its only on Windows you need 64-bit because they were to scared of broken drivers causing problems to enable it. Just another example of Microsoft holding back advancement.

I highly suggest you benchmark PAE first before recommending it. It causes a major hit. It functions like a sliding window.

EDIT: https://en.wikipedia.org/wiki/Physic...ress_Extension

In protected mode, x86 processors use a two-level page translation scheme, where the control register CR3 points to a single 4 KB long page directory divided into 1024 ? 4 byte entries that point to 4 KB long page tables, similarly consisting of 1024 ? 4 byte entries pointing to 4 KB long pages.
Enabling PAE (by setting bit 5, PAE, of the system register CR4) causes major changes to this scheme. By default, the size of each page remains as 4 KB. Each entry in the page table and page directory becomes 64 bit long (8 bytes), instead of 32 bits, to allow for additional address bits. However, the size of tables does not change, so both table and directory now have only 512 entries. Because this allows only one half of the entries of the original scheme, an extra level of hierarchy has been added, so CR3 now points to Page Directory Pointer Table, a short table containing four pointers to page directories.
The entries in the page directory have an additional flag in bit 7, named PS (for page size). If the system has set this bit to 1, the page directory entry does not point to a page table but to a single, large 2 MB page (Page Size Extension).

Which is why PAE was never a good idea. It does appear to the user that it addesses more RAM, but it does not.

EDIT: really PAE is for 32bit processors what himem was for dos. It's sliding window type of workaround that does cause a performance hit.

[tarceri]

I highly suggest you benchmark PAE first before recommending it. It causes a major hit. It functions like a sliding window.

A minor hit. I'm not recommending anything its already the default on most distros and has been for a long time. The performance hit is minimal vs access to more RAM, I'm all for 64-bit but was just pointing out that 32-bit was not a limit to accessing more than 4GB.

EDIT: https://en.wikipedia.org/wiki/Physic...ress_Extension


Which is why PAE was never a good idea. It does appear to the user that it addesses more RAM, but it does not.

EDIT: really PAE is for 32bit processors what himem was for dos. It's sliding window type of workaround that does cause a performance hit.

[duby229]

A minor hit. I'm not recommending anything its already the default on most distros and has been for a long time. The performance hit is minimal vs access to more RAM, I'm all for 64-bit but was just pointing out that 32-bit was not a limit to accessing more than 4GB.

It's not that minor. Put your computer into a memory bandwidth limited scenario and the differnece between a PAE kernel and one without can be a big difference. Considering the disparity between cache performance and memory performance PAE becomes more and more harmful each new product generation as that disparity continues growing. The only good solution is to go 64bits.

[adler187]

I highly suggest you benchmark PAE first before recommending it. It causes a major hit. It functions like a sliding window.

EDIT: https://en.wikipedia.org/wiki/Physic...ress_Extension



Which is why PAE was never a good idea. It does appear to the user that it addesses more RAM, but it does not.

EDIT: really PAE is for 32bit processors what himem was for dos. It's sliding window type of workaround that does cause a performance hit.

Also, Linus on PAE.

Using x86_64, you get:
- Access to more registers, allowing compilers better optimization strategies
- x86_64 calling convention, which passes the first 6 arguments via registers instead of via the stack, which is much faster (similar to Microsoft's fastcall calling convention)
- Access to 64-bit address space per process, which enables your programs to access more than 4GiB of data at once. This also helps things like ASLR, since it makes attacks like heap spraying less effective.
- Assumption of SSE1 (or is it SSE2?), which enables better optimizations (though no one is preventing you from compiling everything with SSE1 support on x86)

Downfalls of x86_64:
- Can't run 16-bit code (not a huge deal nowadays) once processor has been put in to "long mode"
- 64-bit pointers take up twice the space as 32-bit pointers. This increases memory use a bit (can't find the benchmarks I saw, but IIRC it was under 5%) and decreases cache efficiency

Even using slightly more memory and filling up cache faster, x86_64 is generally 10-15% faster, due to the increased register size, better calling convention, and access to SSE registers for floating point (instead of using x87 fp).

Of course, this is doesn't matter in the slightest if your processor doesn't support x86_64. Pretty much all AMD and Intel processors in the last decade have supported x86_64: all Athlon64, Phenom, FX, APU processors; a select few Prescott P4 processors, all Pentium D processors, all Core-series processors starting with Core 2 Duo, etc... The big outliers are: early Sempron processors, most Prescott P4 and older processors, Pentium M, Core Solo/Duo, and some Atom processors manufactured up to at least 2008.

[dungeon]

The only good solution is to go 64bits.

As you say 12 years ago industry started it... but still Microsoft stated that they have 71 millions of users who regulary recieve updates from/to 32bit OSes And god knows, how many are there who does not update anything or not so regulary

[duby229]

Also, Linus on PAE.

Using x86_64, you get:
- Access to more registers, allowing compilers better optimization strategies
- x86_64 calling convention, which passes the first 6 arguments via registers instead of via the stack, which is much faster (similar to Microsoft's fastcall calling convention)
- Access to 64-bit address space per process, which enables your programs to access more than 4GiB of data at once. This also helps things like ASLR, since it makes attacks like heap spraying less effective.
- Assumption of SSE1 (or is it SSE2?), which enables better optimizations (though no one is preventing you from compiling everything with SSE1 support on x86)

Downfalls of x86_64:
- Can't run 16-bit code (not a huge deal nowadays) once processor has been put in to "long mode"
- 64-bit pointers take up twice the space as 32-bit pointers. This increases memory use a bit (can't find the benchmarks I saw, but IIRC it was under 5%) and decreases cache efficiency

Even using slightly more memory and filling up cache faster, x86_64 is generally 10-15% faster, due to the increased register size, better calling convention, and access to SSE registers for floating point (instead of using x87 fp).

Of course, this is doesn't matter in the slightest if your processor doesn't support x86_64. Pretty much all AMD and Intel processors in the last decade have supported x86_64: all Athlon64, Phenom, FX, APU processors; a select few Prescott P4 processors, all Pentium D processors, all Core-series processors starting with Core 2 Duo, etc... The big outliers are: early Sempron processors, most Prescott P4 and older processors, Pentium M, Core Solo/Duo, and some Atom processors manufactured up to at least 2008.

The only thing I want to add is that Prescott and Pentium D used EM64T which misses a few instructions. It's not fully AMD64 compliant. Those chips are really only useful on distros like Gentoo where you can be certain that the binaries they execute are all compiled properly for them.

[Guest]

What I think should happen is if you have a 64bit CPU then it should have to be a 64bit OS.

Any distro that does this is an instant no-go on the computer I use for StepMania. The computer I use for it currently has an AMD64 CPU, but StepMania only ships (and afaik compiles) x86 binaries. On a typical Linux install, going from a x86 to x64 base just for StepMania equals going from minor inconvenience (3 packages) to probably hours of jumbling around package find and install commands just to install all the x86 libraries that game needs (I've tried this before on F22 and gave up after 10 minutes of doing it).

So simply put, that computer in that specific use-case scenario has no benefit on x64, and even gains hassle with trying to use it.

Although on the other hand, this particular computer doesn't have to have the "latest and greatest" installed either, so I could get away with just keeping it on a what-will-eventually-be-outdated disto version, so this particular use-case might not matter that much.

[duby229]

Any distro that does this is an instant no-go on the computer I use for StepMania. The computer I use for it currently has an AMD64 CPU, but StepMania only ships (and afaik compiles) x86 binaries. On a typical Linux install, going from a x86 to x64 base just for StepMania equals going from minor inconvenience (3 packages) to probably hours of jumbling around package find and install commands just to install all the x86 libraries that game needs (I've tried this before on F22 and gave up after 10 minutes of doing it).

So simply put, that computer in that specific use-case scenario has no benefit on x64, and even gains hassle with trying to use it.

Although on the other hand, this particular computer doesn't have to have the "latest and greatest" installed either, so I could get away with just keeping it on a what-will-eventually-be-outdated disto version, so this particular use-case might not matter that much.

I can picture that. Maybe what I said was a bit harsh. But I do think 64bit adoption should have been heavily encouraged about 9 years ago. These problems like what you describe would have happened way back then instead of right now.

I've made it a habit of only booting read only squashfs images. It's pretty easy for me to build a gentoo system, so I have different images I build for different jobs. So basically ld everything and then find sources and ebuilds and throw it into an overlay. Portage has history going back to about 2004 so finding tweaking a similar ebuild is usually simple. The hard part is often times finding the sources or packages.

I wonder if it would be worthwhile trying to build an image for that game?

[Delgarde]

and no, there is no reason to drop i686

Actually, there's a very good reason. If nobody cares about it enough to keep maintaining it, enough to make release, and to address blocker issues, then it has to get dropped.

It's the golden rule in OSS software circles... if you want something done, do it yourself, or find someone else who cares enough to do it.

[s_j_newbury]

What gets me is where projects ostensibly support x86-32, but then mandate sse2, which is a complete violation of the x86 ISA. A good example is Chrome/Chromium where x86 builds no longer works on perfectly x86 ISA compatible CPUs, pretty much requiring running x86 on amd64 hardware. What sense does that make? I ran into this when I built a Gentoo image for a friend who can't afford to upgrade his old pre-sse2 hardware, but can get by okay with a highly optimized Gentoo Xfce install.