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.
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.
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.
Ahhh, journalism at its finest: "The new chips will be able to overclock one of the cores if the other core is not being used." Then two paragraphs later: "This is not overclocking. Overclocking is when you take a chip and increase its clock speed and run it out of spec. This is not out of spec."
That said, this seems to make perfect sense to me. If they're able to pump all that power into a single core while the other one is asleep/idle, all while keeping it within its operating parameters, then I'm all for it.
This guy's the limit!
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.
As many slashdotters are in software development or something related, we should all be grateful that multi-core processors are becoming so prevalent, because it will mean more jobs for hard-core code-cutters.
The paradigm for using many types of software is pretty well established now, and many new software projects can be put together by bolting together existing tools. As a result of this, there has been a lot of hype about the use of high level application development like Ruby on Rails, where you don't need to have a lot of programming expertise to chuck together a web-facing database application.
However, all the layers of software beneath Ruby on Rails are based on single-threaded languages and libraries. To benefit from the advances of multi-core technology, all that stuff will have to be brought up to date and of course making a piece of code make good use of a number of processors is often a non-trivial exercise. In theory, it should mean many more jobs for us old-schoolers, who were building web/database apps when it took much more than 10 lines of code to do it...
Peter
Because when I'm encoding a movie I want my UI to be responsive.
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.
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.
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.
Well, yes and no. I think the easiest model for multithreading today is message passing, but it doesn't suit all needs and requires you to design your app to support it from the start. Most mainstream languages (read C/C++, Java, and .NET) don't really support much beyond your basic mutex, semaphore, and monitor. There are a few other things out there that provide various ways of doing things, but none are universal and none seem to have really caught on.
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, or a compiler that can do that with existing languages. I think that the latter approach may prove impossible. To make informed decisions about threading, a compiler really needs to know things about the data, and most procedural languages just don't cope with that very well.
It seems that HPF may provide some of these things already. I did a few quick Google searches and it seems interesting, but I wonder how much better it is than current work that is being done on auto-vectorization of loops and such in modern compilers. I'll have to look into that language more closely before I can really draw any conclusions. I believe that IBM has been trying to do some interesting work in this area with the Cell processor, too, and I suspect that's why Sony makes interesting statements about how the true power of the Cell will never be fully realized.
Regardless, the next decade is going to be an interesting one for compiler writers, I suspect.
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.
In which case the bottleneck is not the CPU, it's the idiot writing the software.
If you can read this you've gone too far.