Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Sep 2007 19:11:27 -0400
From:      Paul Pathiakis <paul@pathiakis.com>
To:        freebsd-performance@freebsd.org
Cc:        Martin Cracauer <cracauer@cons.org>, Erich Dollansky <oceanare@pacific.net.sg>, Palle Girgensohn <girgen@pingpong.net>, Paul Pathiakis <ppathiakis@eagleaccess.com>
Subject:   Re: AMD or Intel?
Message-ID:  <200709101911.28469.paul@pathiakis.com>
In-Reply-To: <20070910184621.GA77744@cons.org>
References:  <E6C9DBADAE3839B380B736D7@rambutan.pingpong.net> <46E55204.20905@eagleaccess.com> <20070910184621.GA77744@cons.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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. 

This is the same stop gap method everyone uses when they've hit a wall.  

P.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709101911.28469.paul>