From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 49DEB13800E for ; Tue, 31 Jul 2012 05:03:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2D4EFE06D6; Tue, 31 Jul 2012 05:03:33 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 4A8F6E0676 for ; Tue, 31 Jul 2012 05:02:13 +0000 (UTC) Received: by bkwj4 with SMTP id j4so3318163bkw.40 for ; Mon, 30 Jul 2012 22:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=2IOoR6QSe/LiLVuh9qjfRkOstPw9GtPsFgKX6FnEuKw=; b=nxF3B3xrTUwa/CNVs2ei3qU2HCCDumCvTsBWOseQh5MgwCksqNUUvAzymyJRmDfY9J 4e4/y8S4eO4URUBdpVwAFCn0/xFgy1pQG/1CA46o1RXt3/GKyLhyCdHYegda8EMjQOJm HQZ7wW6NmJN0RcLj7BunUcgS3AR3qeTSDlTUZGk52E9VmlZDBUeYM1ZCM/jcjNtUCFvP qRs1NSd++ntdY+plsuPdAmI1aXxgfyCNOMAy/3WjJxgv3+1IhQElnFvPlj2XPXgjoAnj Nx/lJbuz8nT3CqfyK+XpKkF107kdbANWpil1lXizYrrDp1zGO9HC/W5Ns5fXYNHsLoZg XAYg== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.128.202 with SMTP id l10mr4695486bks.127.1343710933323; Mon, 30 Jul 2012 22:02:13 -0700 (PDT) Received: by 10.205.33.10 with HTTP; Mon, 30 Jul 2012 22:02:13 -0700 (PDT) In-Reply-To: <20120731042134.GA10763@waltdnes.org> References: <20120730204201.GB10223@waltdnes.org> <20120731042134.GA10763@waltdnes.org> Date: Tue, 31 Jul 2012 01:02:13 -0400 Message-ID: Subject: Re: [gentoo-user] Re: x32 ABI From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 9230214a-821f-4cb6-8ec7-725ecd313eb2 X-Archives-Hash: 03ede30a123443d9d0dc0668ccc05979 On Tue, Jul 31, 2012 at 12:21 AM, Walter Dnes wrote: > On Tue, Jul 31, 2012 at 05:47:22AM +0300, Nikos Chantziaras wrote > >> That's a problem with x86, not x32. x32 is a 64-bit mode. It's a >> new ABI :-) > > The original poster asked... > >> What are the benefits and drawbacks of using the x32 ABI, other >> than the obvious "experimental" cautions? I currently do not have >> a computer with more than 4GB of ram, and one only has 2GB (used as >> a media center). > > x32 is a backwards compatability shim for use under 64-bit mode. The > point I was trying to make was that the minimum memory where 64-bit has > clear advantages is 4 gigs. If you have 3 gigs or less, you can stick > with 32-bit mode, and x32 libs become moot. The only reason they're the "clear" advantages is because it's much, much harder to adequately describe the advantages given in things such as: * Doubling the number of general-purpose registers. The compiler has a _lot_ more wiggle room for efficiently arranging data during execution. * Doubling the number of SSE registers. You can process a lot more data a lot more quickly without the round trip latency of getting to your GPU. * Decreasing the pressure on memory allocators to allocate memory in a way that avoids fragmentation. This is a function of the larger virtual address space, and has nothing to do with the amount of physical memory you have. * Changing the calling convention to reduce function prologues, and to enable some fancy optimizations. It's also commonly forgotten that a process's address space is divided between userspace and kernelspace; the kernel takes its piece of your process, too, meaning that even if you have 4GB of RAM, you can't create a 3GB heap allocation or mmap 3GB of data. And that has nothing to do with the architecture's mapping of your video card's memory into your system's physical address space. People pound on the "3-4GB of RAM, and you should use x86_64" because it was the easiest way to justify x86_64 to people when it came out; AMD didn't retain full compatibility with x86 when the processor is in long mode, nor does the compatibility mode (which is what x86 ELF binaries running under an x86_64 kernel) have all of the features of the legacy x86 ISA. AMD discarded them for a variety of reasons, even though it meant breaking compatibility with a lot of code that was out there. These days, that doesn't seem like a big deal, but there was doubt at the time as to whether or not AMD64 would take off. Even Microsoft bet the wrong way on that one, initially announcing its only 64-bit platform would be Itanium. To get around the bad press, people pointed to RAM. AMD64 long mode carried real benefits over PAE for enterprise applications, and AMD's parts kept things like instruction reordering, whereas Intel's Itanium ditched it, hoping that compilers would cover the difference. So, for enterprise, where you often had servers with a whopping 16GB of RAM and terabytes of mmap()-able data, the improved address space was a major boon. Meanwhile, home users just kinda trotted along. It took Unreal's developers complaining they needed to be able to fit gigabytes of texture, object and model data into RAM before you really started seeing AMD64 pick up steam on home systems. Even then, Windows desktop users didn't get real 64-bit support until Vista. (Yes, there was a 64-bit version of XP, but driver support there was and is abysmal). But by the time users started installing Vista, they'd already had 4GB of RAM in their systems and were wondering why their BIOS POST sequence would say they only had, say, 3.6GB. So, again, people started pounding on the RAM barrier as a reason to switch to AMD64. People in userland still didn't notice things like additional registers, because they didn't (and don't) understand them. It's not something they see as as part of their POST process or as a visible part of a spec sheet, so it's not something they jockey over. But it's far more important than whether a part has a 90nm feature size or a 45nm feature size. It's true enough; if you have enough RAM, you certainly should be using x86_64. The opposite isn't true, though; even if you don't have enough RAM to demand 64-bit pointers, that doesn't mean you shouldn't be using x86-64. -- :wq