Intel's Single Thread Acceleration 182
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 (Score:4, Informative)
It is well past time that BIOS went to the grave.
EFI (Score:2, Informative)
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:
A Marketing Triumph (Score:5, Informative)
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? (Score:2, Informative)
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 (Score:5, Informative)
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? (Score:5, Informative)
Re:UEFI? (Score:5, Informative)
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 (Score:3, Informative)
Re:Most applications will never become multi-threa (Score:5, Informative)
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 (Score:3, Informative)
--
Simon
Re:A Marketing Triumph (Score:3, Informative)
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 (Score:2, Informative)
Re:Most applications will never become multi-threa (Score:2, Informative)
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 (Score:3, Informative)
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! (Score:3, Informative)
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.