Date: Tue, 11 Sep 2007 10:34:48 -0400 From: Martin Cracauer <cracauer@cons.org> To: Paul Pathiakis <paul@pathiakis.com> Cc: Erich Dollansky <oceanare@pacific.net.sg>, freebsd-performance@freebsd.org, Martin Cracauer <cracauer@cons.org>, Palle Girgensohn <girgen@pingpong.net>, Paul Pathiakis <ppathiakis@eagleaccess.com> Subject: Re: AMD or Intel? Message-ID: <20070911143448.GA79526@cons.org> In-Reply-To: <200709101911.28469.paul@pathiakis.com> References: <E6C9DBADAE3839B380B736D7@rambutan.pingpong.net> <46E55204.20905@eagleaccess.com> <20070910184621.GA77744@cons.org> <200709101911.28469.paul@pathiakis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Pathiakis wrote on Mon, Sep 10, 2007 at 07:11:27PM -0400: > On Monday 10 September 2007 14:46:21 Martin Cracauer wrote: > > For integer workloads Intel's Core2-base Xeons outperforms K8 (the > > old-school AMD64) by about 25-30% per clock per core. K10 seems to be > > 5-15% faster than K8 for integer workloads (I hope to run my benchmark > > suite on one thi week or weekend). > > > > However, tasks that use multiple cores and have threads on cores > > communicate a lot see both AMD architectures close the gap. > > > > Paul Pathiakis wrote on Mon, Sep 10, 2007 at 10:17:40AM -0400: > > > Be very, very careful in purchasing Core 2 Duo. There are major > > > problems with the chip that have been documented across the board. > > > > These have been blown out of proportion by Theo. Can you point to a > > demonstratable case with current Linux or BSD kernels? > > > Agreed. However, Matt Dillon also made statements as did a few EE types. > > The chip is complicated due to poor design and the need for backward > compatibility. I believe several people over the years have said that if > they dumped everything pre-Pentium (486 instructions and earlier), the > instruction set and complexity could easily be halved. Doubtful. All the legacy instructions that are not part of the "useful" set are just high-level microcode programs. You can tell by how slow they are :-) The true complexity of Core2 is in the new caches, including speculative prefetch (aka they keep a dependency graph around and can invalidate wrongly fetched cache lines). Most of the bugs that Theo was concerned about are in emmory management and MMU, which might or might not be made worse by the caches. There probably is some additional memory management complexity from i386 compatibility, but I don't see how, for example, the need to run non-MMU code would cause MMU bugs. Also, I really like to continue to use my bootloaders :-) > Honestly, could you imagine how energy efficient and fast these chips (from > both) would be at that point? > > One of the things that I'm seeing that really is starting to show is the use > of more layers of cache and their increases in size. Not sure what you mean here. The L2 and L3 caches we see today have been around for long. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070911143448.GA79526>