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."

EFI used by more than Apple

[EMB Numbers]

EFI is used by more than just Apple. For example, HP Itanium systems use EFI. By virtue of being "extensible", EFI is vastly better than the BIOS which has frankly failed to evolve since Compaq reverse engineered it in the early 1980s.

It is well past time that BIOS went to the grave.

EFI

[Anonymous Coward]

Universal Extensible Firmware Interface (UEFI) -- the replacement for BIOS that has so far only been used in Intel Macs

Really. I know Google is hard to use, but even Wikipedia [wikipedia.org] would have given some detail on EFI history. (Hint: Itanium only ever used EFI). And it turns out that Macs are not even the first x86 machines to use it, either:

In November 2003, Gateway introduced the Gateway 610 Media Center, the first x86 Windows-based computer system to use EFI. The 610 used Insyde Software's InsydeH2O EFI firmware, based on the Framework. It still relied on a legacy BIOS implemented as a compatibility support module to boot Windows.

And there is always XScale.

A Marketing Triumph

[sibtrag]

Intel's "Enhanced Dynamic Acceleration Technology" is a triumph of marketing. Notice how the focus is on the transition where one core becomes inactive and the other one speeds up. This is the good transition. The other transition, where the chip workload increases & voltage/frequency are limited to keep within a power envelope, is called "throttling" and is much disliked in the user community.

Don't get me wrong, this is valuable technology. It is important that microprocessors efficiently use the power available to them. Having a choice on a single chip between a high-performance, high-power single-thread engine & a set of lower-performance, lower-power engines has great promise. But, the way this is presented is a big victory for marketing.

Re:Twice the speed?

[plasmacutter]

because it's better to have separate cores with separate pipelining for multiple threads than sharing a single core.

because of pipelining, if you have to swap between tasks, you actually lose a large number of instructuions, which means switching tasks often with a single core is significantly worse for performance than multiple cores.

Multi-core CPUs

[nevali]

With all this talk of multi-threading on multi-core CPUs, Slashdotters appear to have forgotten that we all run multi-tasking operating systems. An OS isn't forced to schedule all of the threads of a single application between cores: it's perfectly capable of spreading several different single-threaded applications between cores, too.

And no, EFI didn't appear first on Intel Macs. Intel Macs weren't even the first x86-based machines to employ it.

Re:Overclocking?

[Aadain2001]

I did my MS thesis on a topic very similar to this. Trust me, it's not worth it. While some applications that have inherent parallelism (image manipulation, movie encoding/decoding, etc) can see between 2x to 4x improvements when dynamically threaded, 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.

Re:UEFI?

[KonoWatakushi]

Rather than answer that question, I will ask another. Why would hardware manufacturers such as Intel and AMD want to limit their market by crippling the hardware to only run certain software? It is unlikely in the extreme that open source operating systems will be locked out, and that is what really matters.

As I understand it, UEFI will enable some thoroughly nasty DRM, but only so far as the OS vender chooses to take it. Apple and Microsoft will almost certainly make it a miserable experience for all involved, but will probably tire of shooting themselves in the feet at some point. There are alternatives after all and they are looking better every day.

Re:EFI used by more than Apple

[ThisNukes4u]

And besides, most modern OSes basically relegate the bios to the back burner. Its not like we're still calling bios interrupts from DOS anymore.

Re:Most applications will never become multi-threa

[iangoldby]

What we really need is either a language that can express things in such a way that the compiler can easily make good decisions about what can be parallelized

You mean Fortran 90?

Seriously, several constructs in Fortran are designed specifically for parallel execution. The language itself makes it hard to write code that the compiler can't heavily optimise. There's a reason why variable aliasing is strongly controlled in Fortran and why function parameters have an 'intent' attribute. Then there are constructs such as WHERE, which is by its very nature implicitly a parallel set of operations.

Re:Multi-core is good for jobs

[Simon]

Actually I can't think of any desktop applications that would really benefit from supporting multithreading to actually warrant the extra effort. Most desktop applications for the average person run perfectly fast as single threaded programs. And the high-end stuff like graphics and 3D rendering have supported SMP for a long long time. You could buy dual processor Pentium Pro machines back in the 90s. I don't see multicore processors fuelling demand for programmers.

--
Simon

Re:A Marketing Triumph

[Kjella]

Look, if you look at the benchmarks it's quite clear that you could either get the maximum clock speed *or* the big number of cores. How likely is it really that you'll have four cores, all equally at 100% load? Not unless you're doing something embarassingly parallel better left to a cluster.

Basicly, if you have a thermal envelope. You know that consumption rises with clockspeed squared. You can either have 4*(1GHz)^2 = 4Ghz processing power or 1*(2GHz)^2 = 2GHz processing power with the same power consumption. You can use more cores if possible, since they have better efficiency. You have maximum performance for a single thread if necessary.

One thing is thermal throttling that happens under heavy load which is when you need the processing power, it's like an engine that you can't use. Another thing is a system, that within a TPD of say 100W always makes the most possible out of it. You can eat your cake and have it too, not choosing one over the other at purchase. What's not to like about that?

Below max clock vs. TDP

[AcidPenguin9873]

What this amounts to is taking a part that is qualified to run at, say, 2.8GHz, and selling it with a default clock of 2.2GHz in order to meet TDP. Then, when one core is disabled, you crank up the other core's clock to 2.8GHz and stay within TDP. This sounds like a good idea for mobile computing, since power (i.e. battery life) is by far the most important thing. But for servers, I think you'd want to sell as many chips as you can with the highest rated clock freq, since those are higher margin.

Re:Most applications will never become multi-threa

[Anonymous Coward]

Just for the fortran-ignorant reader, note that there have been two fortran standards since F90 - 95 and 2003.

Also, the array-operations nicked from APL in modern fortran enable a lot of implicit parallelism, as does idiomatic fortran's referential transparency.

DON'T base your opinion of Fortran on GNU Fortran - it'd be like taking Emacs Lisp to be the state-of-the-art in Lisp. The Intel Fortran compiler can do magic things.

BIOS still screws up plenty

[bill_mcgonigle]

And besides, most modern OSes basically relegate the bios to the back burner. Its not like we're still calling bios interrupts from DOS anymore.

It's not as good as you hope. I have three new machines all with BIOS bugs that are a real problem - a SiS mobo that doesn't setup my MTTR registers correctly and so causes the machine to run murderously slow unless I tell the kernel to map out the last bit of RAM or setup my own MTRR registers by hand, an Asus mobo that causes all kinds of problems and kernel panice on the IDE CD-ROM device unless it's jumpered slave, on the secondary bus, and on the end of a single-headed cable (yeah, that was easy to figure out) and an nVidia chipset with BIOS bugs that causes the third and fourth SATA drives in a server to drop dead if they're heavily used (Tyan has sent us new BIOS flashes to try to fix this 'known problem'.).

My only success (that is, the gear actually works without crazy bugs) in the past couple years has been with all-Intel Mobos and HP Athlon boards.

Re:Sum the Cores!

[aXis100]

why not interleave

Because many of the CPU math results depend on other results in the chain. Spreading those dependant operands across multiple CPU's may not be efficient.