Slashdot Mirror


Next Gen Intel CPUs Move To Yet Another Socket

mr_sifter writes "According to a leaked roadmap, next year we'll be saying hello to LGA1155. The socket is 1-pin different from the current LGA1156 socket Core i3, i5, and some i7s use. Sandy Bridge CPUs will be based on the current 32nm, second-generation High-k metal gate manufacturing process. All LGA1155 CPUs will have integrated graphics built into the core instead of a separate chip. This is an upgrade from the current IGP, PCI Express controller and memory controller in Clarkdale CPUs. which is manufactured on the older 45nm process in a separate die (but still slapped together the same package). This should improve performance, as all the controllers will be in one die, like existing LGA1366 CPUs."

3 of 254 comments (clear)

  1. Re:Figures... by zach_the_lizard · · Score: 5, Informative

    You've had to do this for a while. Don't you remember having to get a new motherboard to use newer CPUs, even though they had the same socket? Yeah, I do. That was very confusing at times, and at least with a new socket, you will have a better chance of knowing what will / will not work.

    --
    SSC
  2. And yet,... by Pojut · · Score: 5, Informative

    ...the AM2+/AM3 socket on my AMD board continues to be useful for new AMD CPUs literally years after I originally purchased it.

  3. Re:Integrated graphics in the CPU? by marcansoft · · Score: 5, Informative

    The key is modern RISC, not RISC. x86 is horribly inefficient. I'm not talking about the instruction decoder, I'm talking about the instruction semantics. x86 was never designed for today's high-performance CPUs, and the result is that the instruction set basically allows the programmer to do anything they want, even if it goes against modern CPU design optimizations. This forces the CPU to devote a large amount of die area to workaround logic that detects the thousands of possible dirty tricks that a programmer might use which are allowed by the ISA. For example, every modern RISC requires that the programmer issue cache flush instructions when modifying executable code. This is common sense. x86 doesn't, which means there needs to be a large blob of logic checking for whether the data you just touched happens to be inside your code cache too. The fact that on x86 you can e.g. use one instruction to modify the next instruction in the pipeline is just so ridiculously horribly wrong it's not even funny. There are similar screw-ups related to e.g. the page tables. I can't even begin to imagine the pains that x86 CPU engineers have to go through.

    You can make an x86 chip reasonably small and very slow, or very large and very fast. x86 doesn't let you have it both ways to any reasonable degree.