AMD Logo AMD Developer Central
AMD Developer Blogs
AMD Developer Blogs
Decrease font size
Increase font size
March 26, 2008
  Myths and facts about 64-bit Linux(®)

Myths

  • "You don't need 64-bit software with less than 3 GB RAM"
  • "There are less drivers for 64-bit OS"
  • "You will need all new software, all 64-bit"
  • "64-bit software is twice as fast"


AMD's 64-bit architecture extension
AMD64 introduces one new mode to the processor, the Long mode, consisting of the 64-bit mode and the Compatibility mode. The former is the new 64-bit environment, the latter a compatibility implementation to run 32-bit code in that 64-bit environment. The current operating mode is connected to the code segment. By using instructions that change code segments (like syscall) one can switch between both submodes.
Currently the paging algorithm (derived from PAE) limits the physical address to 52 bits, while the virtual address space is 48-bits wide. Even with far less physical RAM this proves to be helpful for memory mapping.

Another important part of the new architecture is the extended number of registers, both the general purpose registers as well as the SSE registers have been doubled, you can now use 16 of each in the new 64-bit mode.


Software support
Support for 64-bit in software required a new ABI to be introduced as well as extending GCC with the new architecture. As an essential part in that, up to six function parameters are now passed in registers. Linux kernel support for 64-bit started by splitting off a new architecture tree, x86-64. Since 2.6.24 this was merged with the i386 tree to one common code base (x86).

In addition a compatibility layer (aka compat layer) provides support for execution of 32-bit binaries on 64-bit processors.


32-bit compatibility
Compatibility to 32-bit code has been a crucial goal in the design. First of all it allows to run unmodified 32-bit code inside a 64-bit environment. Syscalls are used to switch between both worlds.

The processor zero-extends all 32-bit addresses to 64-bit. Applications use the lower 4 GB of the address space. However, physically that can be mapped anywhere. The kernel manages the compat layer for all applications, meaning it resolves bitness differences, structure layouts and invokes the right library version (/lib{32,64}/ld.so).

Speaking of libraries - each library has to be present twice, once for 32-bit and once for 64-bit, which also includes all dependent ones down to the lowest.

With the Linux compat layer it is even possible to run an entire and unmodified 32-bit Linux installation with a 64-bit kernel.


Benchmarks
First we picked some real world benchmarks for our 32-bit vs. 64-bit comparisons. Oggenc, Mencoder and Povray as well as some compilation tests. Furthermore micro benchmarks were used to show specific performance differences for syscalls and 64-bit arithmetics.

We set up three system configurations - a 32-bit installation, a 64-bit installation and a combination of 32-bit installation with 64-bit kernel to challenge the compat layer. All tests were performed on a dual-core AMD-K8(tm) processor with 1 GB RAM.

The tests showed that the penalty of using the compat layer instead of running your 32-bit application on a native 32-bit kernel is about 1-2 percent. So it is almost negligible.

64-bit took the lead in the media encoding tests. Our Povray and Mencoder benchmarks took about 5% less time in the 64-bit case, Oggenc even 25%. Just C-compilation tests showed a performance advantage of 5% to 8% for 32-bit versus 64-bit.

Native arithmetic performance (64-bit data types used in 64-bit software vs. 32-bit data types used in 32-bit) showed a gain of 10% for the 64-bit case. Using 64-bit data types on 32-bit and 64-bit in the arithmetic performance test showed that 64-bit is more than twice as fast as 32-bit.


Downsides of 64-bit
A 64-bit execution environment and 64-bit software surely have their downsides, too. First there is the larger memory footprint. Binaries get larger because of an increased pointer size and 64-bit operands. This leads to higher memory transfer load and therefore increases cache utilization.


Myths revisited

  • "You don't need 64-bit software with less than 3 GB RAM"
    • Performance improvement even on systems with less than 3 GB RAM
  • "There are less drivers for 64-bit OS"
    • Irrelevant to Linux, hail open source 
  • "You will need all new software, all 64 bit"
    • 32-bit compat layer performs very well and is transparent
  • "64-bit software is twice as fast"
    • Rarely the fact, software is usually optimized for 32-bit


Conclusion
Use a 64-bit system and stick to the compat layer if you have the need of running certain 32-bit applications.


Andre Przywara, Andreas Herrmann, Peter Oruba



-------------------------
This response is provided for informational purposes only, is provided “AS IS” and does not obligate AMD to provide any of the services, technology, or programs described.

Edited: 03/26/2008 at 05:07 AM by peteroruba

 Post a Comment    

    Posted By: Peter Oruba @ 03/26/2008 04:54 AM     AMD Operating System Research Center (OSRC)     Comments (0)  

March 18, 2008
  Live from EclipseCon 2008
I have just a short break here, but wanted to give you all a quick update on how things are going here at EclipseCon 2008.

The booth has been quite busy, with attendees coming by to fill out our survey and get their 1GB USB drive. We've had a number of people wanting to learn what AMD's relationship is with Eclipse, and then are very interested once they find out what the CodeSleuth plugin can do for their Java development process.

Gary Frost from the AMD Java Labs team delivered his technical session this morning to a full room. After his session, I was flooded at the booth! I'll try to post some pictures when I get a moment.

Gotta go, the hall is opening up again and people are coming by! Be sure to check out CodeSleuth yourself if you're not able to join us at the show.



-------------------------

The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors. Links to third party sites are for convenience only, and no endorsement is implied.



Edited: 03/24/2008 at 05:04 PM by devcentral

 Post a Comment    

    Posted By: AMD DeveloperCentral @ 03/18/2008 05:41 PM     Inside Dev Central     Comments (0)  

March 13, 2008
  Join us at EclipseCon 2008
If you're coming to EclipseCon 2008 next week (March 17-20 in Santa Clara, CA), be sure to come visit the AMD Hardware Lounge or our booths (410/411) in the Exhibit Hall. We'll be showcasing one of the servers we've donated to the Eclipse Foundation to run their backend infrastructure, along with some AMD SPIDER systems.

Gary Frost, one of our AMD Java Labs engineers, will also be delivering a technical session and will be on hand to answer questions about the new plugin for Eclipse we're demonstrating.

Plus, fill out our survey for a chance to win a fun prize!

Get all the details at our AMD@EclipseCon page.

-------------------------

The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors. Links to third party sites are for convenience only, and no endorsement is implied.


 Post a Comment    

    Posted By: AMD DeveloperCentral @ 03/13/2008 03:55 PM     Inside Dev Central     Comments (0)  

FuseTalk Hosting Executive Plan - © 1999-2009 FuseTalk Inc. All rights reserved.

Contact AMD | Terms and Conditions | Forum Rules | ©2009 Advanced Micro Devices, Inc. | Privacy | Trademark information