Intel's Single Thread Acceleration

SlinkySausage writes "Even though Intel is probably the industry's biggest proponent of multi-core computing and threaded programming, it today announced a single thread acceleration technology at IDF Beijing. Mobility chief Mooly Eden revealed a type of single-core overclocking built in to its upcoming Santa Rosa platform. It seems like a tacit admission from Intel that multi-threaded apps haven't caught up with the availability of multi-core CPUs. Intel also foreshadowed a major announcement tomorrow around Universal Extensible Firmware Interface (UEFI) — the replacement for BIOS that has so far only been used in Intel Macs. "We have been working with Microsoft," Intel hinted."

Overclocking?

[Nuffsaid]

For a moment, I hoped Intel had come out with something like AMD's rumored reverse-Hyperthreading. That would be a real revolution!

Twice the speed?

[Aladrin]

The article suggests that this technology makes 1 core run twice as fast by basically disabling the second core for a while. They go on to 'prove' how effective it is by running a photo processing thing that they don't explain. It runs twice as fast this way.

So... If they can have 2 cores at full speed, or 1 core at double speed... WHY THE FUCK do they have 2 cores in the first place?

"Caught up"?

[Z0mb1eman]

It seems like a tacit admission from Intel that multi-threaded apps haven't caught up with the availability of multi-core CPUs.

Or maybe Intel, unlike the story submitter, knows that many apps simply do not lend themselves to multithreading and parallelism. It's not about "catching up".

Multi-core for multithreaded apps? Check.
Trying to get each core as fast as possible for when it's only used by one single-threaded app? Check.

Makes sense to me.

Most applications will never become multi-threaded

[something_wicked_thi]

Why should they? The advent of multicore CPUs won't actually hurt single-threaded apps. They just won't get any faster. For most things, that's fine. Legacy apps that aren't changing are most likely already fast enough. Besides, not everything can be parallelized properly, anyway. Multithreaded applications will become more popular, but I think this trend will affect new applications much more than old ones because it's just not that important. Even new apps don't necessarily need parallelization because many things are "fast enough" on a single core.

By the way, I actually hope that many things never become multithreaded. In my experience, most coders simply aren't capable of thinking threading through clearly. For many people, the concept is just too complex. Hopefully, compilers will improve to the point where many things can be parallelized without the coder having to know very much, if anything, about the threading involved, but, today, we're nowhere near that. We desperately need higher-level threading primitives in computer science.

Thanks for the heads up...

[dintech]

"We have been working with Microsoft," Intel hinted."

Now I know to avoid it.

Re:Twice the speed?

[0100010001010011]

Because when I'm encoding a movie I want my UI to be responsive.

Re:Multi-core is good for jobs

[mr_mischief]

Taking advantage of multiple cores with a single-threaded per-client application just requires having more than one simultaneous user on your server. It doesn't at all require having a multi-threaded application per client. Most HTTP connections don't do anything very fancy, and really won't be helped much internally by multiple cores. The web server software itself, the database server, the fact that popular sites (or shared servers) get more than one visitor at a time, and similar concerns will make a much bigger difference with multiple cores than making a CRUD application or a blog multi-threaded.

Re:Most applications will never become multi-threa

[pla]

In my experience, most coders simply aren't capable of thinking threading through clearly

I agree completely, though you can expect to catch some flack for that one, from the hoardes of poor coders who think nothing (or rather, who don't think about the implications) of splitting off another thread to boost performance (even in a single core environment). ;-)

Personally, I consider myself a damned good coder - And I avoid multithreading wherever possible. If I really need the raw CPU power, I'll usually try to model it as a full slave process before resorting to messy threading.



We desperately need higher-level threading primitives in computer science.

We've had it for decades - Just look for multiprocessor support, and you have implicit multithreaded support automatically.

As one "mature" implementation, we could all start coding in HPF. I'd personally rather gnaw my own right leg off, but, to each their own.

Re:EFI used by more than Apple

[pla]

By virtue of being "extensible", EFI is vastly better than the BIOS

Yeah... Why, that nasty ol' standard BIOS makes hardware-level DRM just so pesky. And vendor lock-in for replacement hardware? Almost impossible! Why, how will Dell ever survive if it can't force you to use Dell-branded video cards as your only upgrade option? And of course, WGA worked so well, why not include it at the firmware level? Bought a "OS-less" PC, did we? No soup for you!


Sorry, EFI has some great potential, but it has far too much potential for vendor abuse. The (somewhat) standardized PC BIOS has made the modern era of ubiquitous computers possible. Don't take a "step forward" too quickly without first looking to see if it will send you over a cliff.

Re:Most applications will never become multi-threa

[Gr8Apes]

In my experience, most coders simply aren't capable of thinking
threading through clearly

I agree completely, though you can expect to catch some flack for
that one, from the hoardes of poor coders who think nothing (or rather,
who don't think about the implications) of splitting off another thread
to boost performance (even in a single core environment). ;-)

Hordes of even "good coders" can't properly code multi-threaded apps. Actually, after more than a decade as a programmer, I'm not sure there are hordes of good coders. There are good coders, and a disturbingly large percentage of them do not understand concepts like multi-threading or effective techniques of fail-safe systems coding.

Personally, I consider myself a damned good coder - And I avoid
multithreading wherever possible. If I really need the raw CPU
power, I'll usually try to model it as a full slave process before
resorting to messy threading.

You may be a good coder, but you apparently fall into the majority camp by your own admission. Not that there's anything wrong with that though. You at least realize that multi-threading isn't your thing.

We desperately need higher-level threading primitives in computer science. ...
As one "mature" implementation, we could all start coding in HPF. I'd
personally rather gnaw my own right leg off, but, to each their own.

As many folks pointed out to me previously, Eiffel seems to be pretty nice in this arena. I've never seen a production use of it, but who's to say it's not the next big thing? (Perhaps 3+M Java coders?)

The major issue with multi-threading remains though, and that's identifying the parallel processes. Take a series of sequential code blocks that involve retrieving pieces of information from several sources. If those retrievals are independent of each other, you can retrieve all the pieces concurrently (in parallel) and then sequence them together when all retrievals are done. Now the process takes the time of the longest retrieval plus assembly vs an sum of all retrievals and assembly. This type of process is quite common in enterprise systems working off of several DBs. Putting such code in a slave process requires inefficient messaging results back to the calling process, and adds unnecessary overhead. This is but one case where multi-threading helps performance significantly. I'm not sure that something like Eiffel would make this code any easier to write since the bulk of the multi-threaded work is in the design itself.

Re:EFI used by more than Apple

[99BottlesOfBeerInMyF]

Yeah... Why, that nasty ol' standard BIOS makes hardware-level DRM just so pesky.

Not really. It just makes improvements and DRM hacks. Add a TPM module to a BIOS-based system and include support in the OS and it will be just as effective for MS's purposes as an EFI one. BIOS makes modern hardware a pain in the butt. The fact that DRM modules are modern hardware is sort of orthogonal to the issue.

And vendor lock-in for replacement hardware? Almost impossible! Why, how will Dell ever survive if it can't force you to use Dell-branded video cards as your only upgrade option?

Umm, Dell is not even the biggest player in a market that is not monopolized. If Dell requires Dell branded video cards and people care (most probably won't) then people will switch to a vendor that does not do this and Dell will change or die. I don't think Dell or any other PC vendor has enough influence to force such a scheme upon the existing graphics card makers. Only MS really has that much influence and I don't think they have the motivation.

Bought a "OS-less" PC, did we? No soup for you!

I don't think you have to worry about this problem unless you're running Windows on it.

Sorry, EFI has some great potential, but it has far too much potential for vendor abuse.

I disagree. I don't see that vendors will abuse this any more than they already abuse BIOS. In any case, the change is coming. You just need to decide which side of the curve you want to be on. (Typed from an EFI laptop.)

Re:ACK!!!

[Chapium]

"the majority of your basic applications are too linear and have too many dependencies between instructions for dynamic threading to really be worth the investment in hardware"

Good lord, let me sell all my web, application, and DB servers then!!!! I've overpaid for 32 CPU systems!!!! ACK!!!

I wouldn't call server applications or dbms "basic applications."

let's not be subtle about this

[r00t]

Some people didn't get it. Here:

This chip has to throttle itself when you use all the cores. (probably a power/heat issue)

People hate throttling. Throttling is not marketable.

Intel marketing turned things around, saying that the chip speeds up (a.k.a. "stops throttling") when running single-threaded apps. Speeding up is good! It's like the old turbo buttons.

It's a sane idea. I'd been expecting to see chips that can't run at full speed continuously because of heat issues; this is pretty much the same thing. I should've patented it...