Slashdot Mirror


Dual Caches for Dual-core Chips

DominoTree writes "The dual-core chips that AMD and Intel plan to bring to market next year won't be sharing their memories. A version of Opteron coming in 2005 and Montecito, a future member of Intel's Itanium family also slated for next year, will both have two processor cores, the actual unit inside a processor that performs the calculations, and each core will have separate caches."

6 of 342 comments (clear)

  1. mmmm cores by zaqattack911 · · Score: 3, Insightful

    Can I have a 64bit OS too please? (no not linux)

  2. Commodity hardware grows mature. by Skulker303 · · Score: 5, Insightful

    Daul core microprocessors are not a new development. IBM with their POWER4 and POWER5, HP and the PA-RISC 8800, and TI with their OMAP processors are definitive proof that multi-core solutions are not just a stop gap in increasing the performance delta of modern silicon.

    Daul core processors are a natural evolution in the development of general purpose and even specialized computing devices. SMT was to be a boon for the EV8, but later found its way into the Pentium4. Multiple logical processors were just a first step.

    It should be interesting to see just what AMD can do with both SMT and a daul core design.

    It just had better run BSD. = )

  3. Sure, OS/400 by Shivetya · · Score: 4, Insightful

    Been that way for many years. Is rock stable and secure.

    Granted it is on a mini, but we have enjoyed 64bit computing for nearly nearly 10 years. Even have some power5s in production.

    There are great OSes other than the ones used on PC hardware... too many "geeks" forget that.

    --
    * Winners compare their achievements to their goals, losers compare theirs to that of others.
  4. It's nice but.. by leathered · · Score: 4, Insightful

    I like Itanium. It's a pretty neat architecture which crushes most before it in FP intensive tasks. It is clear why it has done well in HPC. But HPC is nothing more than a niche.

    Now here are the problems:

    32 bit (x86) perfomance sucks. All those apps you've spent years developing will need re-writing (A simple recompile is often out of the question).

    HP (in collusion with Intel) killed perfectly good archs. in Alpha and PA-RISC in an effort to get people to migrate to IA-64. A few may have made the move but this has mostly served to push people towards the vasty cheaper x86. HP, and to a lesser extent Intel, should provide what their customers want, not what they think is best for them.

    It still uses a shared bus architecture. There are diminishing returns as you add more processors.

    Itanium requires massive caches to get the best from it. Cache = Silicon = Cost. It is clear that a large scale seeding exercise is still underway with Itanium systems being provided at or below cost. Looks like it will be a long time before there will be any return on the billions invested in Itanium.

    --
    For all intensive porpoises your a bunch of rediculous loosers
  5. Re: unified (single) is not always better by mepperpint · · Score: 3, Insightful

    It's not entirely true that single is better. It depends on what the system is used for. If both cores are accessing the same memory (likely the case in a multi-threaded webserver for instance), then they can benefit from sharing a cache and effectively doubling the cache size. However, if both cores are accessing different memory (almost any situation where different applications are running on the different cores), then sharing a cache could have devastating effects on performance. As each process running on each of the cores would be likely to be evicting the other processes cached memory, there would be a plethora of cache misses. In the worst case, this could effective make the system as slow as if there were no cache at all. In the average case there would likely be a significant performance hit. A better strategy than unified or seperate caches would be to have a read/write cache for each core and allow each core to read the other core's cache. This would allow the benefits of the shared cache in the case where both cores were accessing the same memory without having the major performance hit when each process is accessing different memory. Unfortunately the hardware for this would be even more complicated than for the unified or seperate cache techniques.

  6. Day late, dollar short... by gillbates · · Score: 3, Insightful

    While dual cores on a chip might be nice, it won't produce any serious performance increases.

    The underlying problem with Intel and AMD's processors is that they are at the mercy of the architecture:

    1. These chips must share a relatively slow memory bus with other devices.
    2. Currently, the fastest FSB to date is 1033MHz - almost 1/3 of the max clock speed of the processor. Given that Intel's integer units operate at twice the clock speed, the fastest parts of the chip operate at 6 times faster than memory.
    3. The monolithic, synchrous, central-processing-unit design of the architecture prohibits optimizations such as using memory controllers for block moves and having dedicated IO processors. Contrast this with Mainframes in which the CPU passes off IO instructions to ancillary processors and continues to work. In PC-land, when the IDE controller seizes the bus for a transfer from disk into memory, the CPU has to execute out of its cache for ~256 instruction cycles, or risk stalling.

    The ironic thing is that even though AMD and Intel are out-clocking mainframe processors by factors of 2 and 3, mainframes still get more work done simply because they aren't choked by a slow and overcrowded system bus .

    --
    The society for a thought-free internet welcomes you.