Re: AMD or Intel?

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@xxxxxxxx> http://www.cons.org/cracauer/
FreeBSD - where you want to go, today. http://www.freebsd.org/
_______________________________________________
freebsd-performance@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Scaling noise
    ... > cores, and so are trying to dispatch three instructions per clock. ... Neither of these CPUs are multi-core. ... > do branch prediction and speculative execution. ...
    (Linux-Kernel)
  • Re: PowerPC Simulation
    ... For early phases of design I make sure caches stay turned off and just ... follow memory fetches. ... It will be a mix of instructions and data of ...
    (comp.arch.fpga)
  • Re: OT: race for 8086s continues: 4 cores for AMD
    ... AMD is to have 4 cores in its 8086. ... One of the biggest changes will come in the caches, ... data from main memory--a time-consuming process. ...
    (comp.os.vms)
  • OT: race for 8086s continues: 4 cores for AMD
    ... One of the biggest changes will come in the caches, ... dedicated to their respective cores. ... With the third cache, the processor will less often have to fetch ... data from main memory--a time-consuming process. ...
    (comp.os.vms)
  • Re: Difference Between ARM and THUMB
    ... > all Thumb-2 opcodes mapped into empty/spare opcode space, ... undefined or unpredictable instructions. ... Thumb2 only cores will fault state change instructions instead ...
    (comp.sys.arm)