Slashdot Mirror
Intel Details Upcoming Gulftown Six-Core Processor
MojoKid writes "With the International Solid-State Circuits Conference less than a week away, Intel has released additional details on its upcoming hexa-core desktop CPU, next gen mobile, and dual-core Westmere processors. Much of the dual-core data was revealed last month when Intel unveiled their Clarkdale architecture. However, when Intel set its internal goals for what its calling Westmere 6C, the company aimed to boost both core and cache count by 50 percent without increasing the processor's thermal envelope. Westmere 6C (codename Gulftown) is a native six-core chip. Intel has crammed 1.17 billion transistors into a die that's approximately 240mm sq. The new chip carries 12MB up L3 (up from Nehalem's 8MB) and a TDP of 130W at 3.33GHz. In addition, Intel has built in AES encryption instruction decode support as well as a number of improvements to Gulftown's power consumption, especially in idle sleep states."
Cores are like girls in 'hot sluts gone wild' scenes - after a certain point you might hardly notice if there's even more of them, but you'd never say "no" to an increase.
Cores are like girls in 'hot sluts gone wild' scenes - after a certain point you might hardly notice if there's even more of them, but you'd never say "no" to an increase.
But my "operating system" can only deal with one hand- I mean core- at once!
Wrong question. When was the last time my computer was running a single thread that could use 100% CPU for more than a few milliseconds. Answer: All the time. For example whenever I open Slashdot with Firefox. I rather have less cores at higher speed than more cores.
Most programs can't be written to take full advantage of even one core. Most of the things that you do on a computer will run happily on a 1GHz CPU and still not bring usage over 50% more than occasionally. Most of the things that will tax a modern CPU can be made parallel, so will scale quite well to a number of cores. Even if your processor intensive task isn't using multiple cores, you still benefit a bit from being able to move everything else onto another core. With the recent Intel chips you also have 'Turbo Boost' (horrible name) which underclocks some cores while overclocking others, giving one core a speed boost for that CPU-eating single-threaded app while keeping the power usage and heat generation output. To prevent hotspots on the die, you can move the process around between the cores, giving each a boost for a little while.
I am TheRaven on Soylent News
Porting libdispatch requires a generic event delivery framework, where the userspace process can wait for a variety of different types of event (signals, I/O, timers). On Darwin, Apple used the kqueue() mechanism that was ported from FreeBSD, so it's quite easy to port the code to FreeBSD (just #ifdef the bits that deal with Mach messages appearing on the queue). Kqueue is also ported to NetBSD and OpenBSD, so porting it to these systems will be easy too.
Solaris and Windows both have completion ports, which provide the same functionality but with different interfaces. Porting to Solaris would require replacing the kqueue stuff with completion port stuff. Porting to Windows would ideally also require replacing the pthread stuff with win32 thread calls. Even Symbian has a nice event delivery framework that could be used, although I'm not sure what the pthread implementation is like in the Symbian POSIX layer.
Linux is the odd system out. All different types of kernel events are delivered to userspace via different mechanisms, so it's really hairy trying to block waiting until the next kernel event. This also makes it harder to write low-power Linux apps, because your app can't spend so long sleeping and so the kernel can't spend so much time with the CPU in standby mode.
If you don't need the event input stuff (which, to be honest, you do; it's really nice), you can use toydispatch, which is a reimplementation that I wrote of the core workqueue model using just portable pthread stuff.
It also adds some pthread extensions for determining the optimal number of threads per workqueue (or workqueues per thread, depending on the number of cores and the load), but these are not required. The FreeBSD 8.0 port doesn't have them; they were added with FreeBSD 8.1.
I am TheRaven on Soylent News
If you left for work, would it have really made any difference to you if it took five times as long?
Well, yeah. I wouldn't have been able to brag about it ;-)
we see things not as as they are, but as we are.
-- anais nin
What?
AES acceleration will be useful for VPNs, serving SSL websites, VoIP, full disk encryption ... and so on.
Why put AES on-board?
They're not: they're putting extra instructions on-board which help implement AES more efficiently. They may also allow you to implement other algorithms more efficiently, though I haven't looked at them in enough detail to be sure.
I thought AES was relatively fast as encryption algorithms go.
That still doesn't make it fast at an absolute level. Particularly when you're doing full-disk encryption with user account encryption on top and IPSEC on all your network connections.