Slashdot Mirror
The Future of Intel Processors
madison writes to mention coverage at ZDNet on the future of Intel technology. Multicore chips are their focus for the future, and researchers at the company are working on methods to adapt them for specific uses. The article cites an example were the majority of the cores are x86, with some accelerators and embedded graphics cores added on for added functionality. "Intel is also tinkering with ways to let multicore chips share caches, pools of memory embedded in processors for rapid data access. Cores on many dual- and quad-core chips on the market today share caches, but it's a somewhat manageable problem. "When you get to eight and 16 cores, it can get pretty complicated," Bautista said. The technology would prioritize operations. Early indications show that improved cache management could improve overall chip performance by 10 percent to 20 percent, according to Intel." madison also writes, "In another development news Intel has updated its Itanium roadmap to include a new chip dubbed 'Kittson' to follow the release of Poulson. That chip will be based on a new microarchitecture that provides higher levels of parallelism."
I think Cell's taught us two important things about heterogeneous multicore:
:) Buy stock in gcc...
1. It's fairly hard to develop for.
2. It's bloody fast.
Looks like Intel's gonna be running with it some; that's good news for anyone making a living selling compilers!
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
While multicores, obviously, have their use, the future belongs to CPUs with massive internal implicit parallelism, IMHO.
I hate to break it to ya, but in a low-level language like C, doing proper bounds checks and data sanitization required for security does not help performance (although it doesn't harm it much either, and should of course always be done)
There is a lot of bloated code out there, but the bad news for people who always post "just write better code!" is that the truly processor-intensive stuff (like image processing, 3D games) is already pretty well optimized to take advantage of modern hardware.
There's also the definition of what "good code" actually is. I could write a parallelized sort algorithm that would be nowhere near as fast as a decent quicksort on modern hardware. However, on hardware from 10 years from now with a big number of cores, the parallelized algorithm would end up being faster. So which one is the 'good' code?
As usual, real programming problems in the real world are too complex to be solved by 1-line Slashdot memes.
AntiFA: An abbreviation for Anti First Amendment.
Be patient. The other five articles should appear soon.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
I've found that improved cash management does wonders for me, like allowing me to buy things like new processors.
This guy's the limit!
Where will all the CPU time go on desktops with these highly parallel processors?
Penryn (a die shrink of the Core2 Duo/Quad plus some SSE4) should have 3 GHz+ models. The real performance issue isn't clockspeed, it's instructions per second. When you make 128-bit SSE take fewer cycles, and you add execution units, improve scheduling logic, and reduce access latencies (through pre-fetching or larger caches, or faster buses), you make processors faster. A processor that runs at 2 GHz with 3 Instructions per clock is just as fast as one that runs at 4 GHz with 1.5 IPC. The reason clockspeed hasn't been increasing is because performance gains have been coming from other areas. Intel could probably sell a juiced-up 3.6 GHz Core 2 Extreme, but it'd run at 180 Watts or something, and cost like $1500.
For some reason javascript is slow on all browsers. I believe there is a W3C spec that mandates it.