Slashdot Mirror
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."
For a moment, I hoped Intel had come out with something like AMD's rumored reverse-Hyperthreading. That would be a real revolution!
Nuffsaid
________
Don't know about his cat, but Schroedinger is definitely dead.
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.
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.
ClutterMe.com - easiest site creation on the Net. Just click and type.
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.
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.
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.
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.
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.
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.