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.
Re: processors of the future: super-computer-on-a-chip? ... " How many cores do you think a chip could have, lets say 10 or 20+ years from now? ...relegating single-threaded performance to the back seat of its POWER architecture: instead, after pioneering dual-core products 5 years ago it has been steadily improving their single-threaded performance. ... Sure, there will be a few applications that could make really good use of huge numbers of slower cores, but will they fund the associated development sufficiently to overcome the resources available to develop commodity products? ... [end quote] ... (comp.arch)
Re: How to develop a random number generation device ...chip, and something new will be required to manage them. ... I think that the number of virtual cores will grow faster than the ... One CPU would be the manager, ... I'm happy to accept that doing things in hardware is often more reliable than doing things in software (I work with small embedded systems - I know when reliability is important, and I know about achieving it in practical systems). ... (sci.electronics.design)
Re: How to develop a random number generation device ...chip, and something new will be required to manage them. ... I think that the number of virtual cores will grow faster than the ... One CPU would be the manager, ... embedded systems - I know when reliability is important, ... (sci.electronics.design)
Re: Target market for Intellasys. ... I was wrong about that Ambarella chip, it's average power requirements are more than I thought. ... With the 1 transistor dram, the substrate acts as a capacitor, so theoretically you get many times more memory density, good speed etc. ... I for one would be dropping in 10+DACS, extra processors, extra memory, and if available 36bit processor cores and full external SRAM memory buss mapped to one core. ... But such a scheme would allow customers to easily order a module populated with a desired amount of memory cores, and it would cost intellasys a lot less than putting memory on the processor. ... (comp.lang.forth)
Re: processors of the future: super-computer-on-a-chip? ... " How many cores do you think a chip could have, lets say 10 or 20+ years from now? ... Just because it's become harder to improve single-thread performance doesn't mean that it's no longer useful to and that taking the path of least hardware resistance is The Right Thing To Do. ... In fact, one could argue that because single-threaded operation characterizes such a large percentage of today's applications, and because software has historically changed so slowly compared with hardware, then there's relatively little reason to push multiple cores per chip beyond *at most* a few dozen for the immediate future while continuing to devote significant concentration to improving single-thread performance too. ... (comp.arch)
