<div class="gmail_quote">On Thu, Dec 31, 2009 at 12:04, Lori Paniak <span dir="ltr"><<a href="mailto:ldpaniak@fourpisolutions.com">ldpaniak@fourpisolutions.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, 2009-12-31 at 10:22 -0500, Chris Irwin wrote:<br>
> 1. He was using Ubuntu, so it was i386 vs modern AMD64. So how much of<br>
> this was affected by having things like SSE, etc. There was a request<br>
> to try using an i686-targetted system (such as Arch). There was also a<br>
> request to use gentoo and actually build the system with the same<br>
> capabilities for 32- and 64-bits, but I doubt anybody wants to spend<br>
> two weeks doing that ;)<br>
<br>
<br>
</div>As is typical with standardized benchmarks, there is a pound of salt to<br>
be digested as well. The only benchmarks that make sense are ones of<br>
your typical usage pattern.<br>
<br>
One probably does not have to go as far afield as Arch or Gentoo to get<br>
i686 results along with AMD64 and i386.  Debian ships kernels in each of<br>
these flavours (i486 too).  With Debian, much of the test environment<br>
should just be a copy-and-paste from ubuntu.<br></blockquote><div><br>The issue was two part: Is it the kernel alone that provides improvement (try 64-bit kernel with 32-bit i386 userspace) or was it the fact that compiling targeting amd64 enables all sorts of cpu features that are not present on i386 (mmx, sse, etc). Using these capabilities may cause GCC to compile certain applications differently.<br>
<br>Lets take SSL as the standout example. A fair amount of the improvement will be coming from extra registers as part of the amd64 platform. But some of the improvement may be simply that the compiler knew it had SSE and other modern hardware capabilities available and was able to create a better binary. Having a 32-bit userspace that targeted a modern CPU's capabilities would provide a more interesting comparison from a technical point of view (what gives more benefit: 64-bit or knowing the capabilities of your CPU and hardware). Granted, from a user point of view it doesn't matter as the average user (myself included) is just going to run whatever bits Ubuntu gives them.<br>
<br>But it would give all those gentoo folk with massive lists of CFLAGS something to gloat about.. Actually, that is probably bad. ;)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div class="im"><br>
> Also, not to nitpick (though I do so love playing the part), but your<br>
> short summary read like "64-bit isn't worth it except in these<br>
> specific instances". I read the article as coming more across as<br>
> "There are no regressions, but you may get improved performance in<br>
> specific instances". Subtle difference, but it would affect whether<br>
> somebody decided to install a 32- or 64-bit system.<br>
<br>
</div>I agree with your more precise summary. My own view is that if you have<br>
a 64-bit CPU, you should run a 64-bit OS.  Since AMD has been making<br>
64-bit CPUs for 6+ years and Intel for 4 years, there are fewer and<br>
fewer situations that require 32-bit systems.  Performance gains<br>
suggested in this article just reinforce this view (even with the<br>
i386/i686 caveats).  Now that virtualization environments support 64-bit<br>
guests and many netbook-class CPUs are 64-bit, I am not sure how one<br>
makes the argument for 32-bit OS on new hardware (ex-basic netbooks).<br>
</blockquote><div><br>I agree. I wish (as pointed out in another email) that Ubuntu and Debian had a better 32-bit compatibility capability, though.<br><br>Since you opened the Virtualization can-of-worms, Linux has awesome support for this built-in with KVM now. The only issue is it needs special support on-chip. This means VT for Intel, and AMD-V for AMD. At least when you buy an AMD processor, all of them are 64-bit and AMD-V capable, with the exception of the Sempron, which is not the latter.<br>
<br>Intel on the otherhand, you have to look up every chip to see if it is VT capable. An example: The T5500 and T5600 processors have VT, while the T5550 and T5670 do not (one would assume they were simply improved versions of their predecessors). It made it very difficult to purchase a new laptop since most manufacturers do not indicate what specific processor is within. Interestingly, all of their "su" low-power processors are VT capable, even though I would imagine that is not their target market...<br>
<br><a href="http://ark.intel.com/Compare.aspx?ids=32427,27253,35163,27254">http://ark.intel.com/Compare.aspx?ids=32427,27253,35163,27254</a>,<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For the desktop user, I think this is the most relevant test where the<br>
32/64-bit question comes up.  I use ecryptfs for my home as well - with<br>
64-bit karmic on a 2.2Ghz Intel T7500 mobile Conroe.  If you have<br>
similar hardware and 32-bit OS, we could compare disk I/O numbers on<br>
home.</blockquote><div> </div><div>Sadly no, 64-bit only.<br></div></div><br>-- <br>Chris Irwin<br><<a href="mailto:chris@chrisirwin.ca">chris@chrisirwin.ca</a>><br>