Linked by Thom Holwerda on Fri 15th Jun 2007 12:08 UTC, submitted by cragnotil
Permalink for comment 248124
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 06/18/13 22:33 UTC
Linked by Anonymous on 06/18/13 22:26 UTC
Linked by Thom Holwerda on 06/18/13 22:25 UTC
Linked by Thom Holwerda on 06/18/13 17:45 UTC
Linked by Thom Holwerda on 06/18/13 17:32 UTC, submitted by poundsmack
Linked by Thom Holwerda on 06/17/13 17:58 UTC
Linked by Thom Holwerda on 06/17/13 17:52 UTC
Linked by Thom Holwerda on 06/14/13 21:03 UTC
Linked by Thom Holwerda on 06/14/13 20:46 UTC
Linked by Thom Holwerda on 06/14/13 17:32 UTC
More News »
Sponsored Links



Member since:
2005-07-08
I'm still not convinced that this massive number of cores is going to be the right way to go from here on out. Transferring scheduling complexity into software is a concept that hasn't worked well for Intel before and it makes me wonder why they're doing this again.
If we look back at the Itanium we see one of it's major drawbacks was that to get the full power out of the chip, you needed to have 3 instructions running at any given time. Anyone who's written for the Itanium will tell you that keep the thing running at 100% capacity was nearly impossible unless you were talking about crunching raw numbers in an easily parallelized way.
I'm also curious to see how Intel is dealing with the massive amounts of traffic that are going to be traveling across the CPU bus. Cache synchronization between that many cores must be a nightmare.
I saw the justification for 2 cores and even 4 cores. Ok I'll even stretch it to 8 for very specialized applications and high def video encoding.