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.
To a degree.
I don't follow hardware and I don't write multi-threaded apps so i could be way off on this... But with the sheer volume of poorly designed/implemented single threaded applications wouldn't it be asking for trouble to urge speed in the industry conversion to the increased complexity of multi-threaded solutions?
Y'all multi-thread developers take as much time as you want.
Regards.
It makes perfect sense that you'd still try to speed up single-threaded applications. After all, if you have 4 cores, then any speedup to one core is a speedup to all of them. I realize that's not what this article is about. In this case, they are speeding up one at the expense of the other, but the article's blurb makes it sound like Intel shouldn't be interested in per-core speedups when that is clearly false.
Well... that depends.
How good is linux's support for UEFI?
This "single thread acceleration" will have to be supported by the OS?
Does it have the potential to break a half-bad application?
--
Every time your page doesn't validate, the W3C kills a foxy.
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.
Really. I know Google is hard to use, but even Wikipedia 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:
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.
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?
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
While I am all for having something a bit more intelligent than BIOS to init a computer, I can't help but wonder... Does this UEFI integrates DRM functions? Is this the Trojan Horse that will make all computers DRM-enabled?
Inquiring minds want to know!
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
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.
In the past, chips were limited to a maximum voltage because of the risk of long-term damage at higher voltages. As a results, the voltage could be cranked up close to the maximum, providing high-frequency performance. Around 2004, however, OEMs started becoming concerned about cooling extremely high-power chips like Tejas, and the chip manufacturers had to start pushing the power consumption back down. Now, we have chips that could operate at higher frequencies if the power budget were higher. When you have multiple cores and some aren't running, that busy cores can be run at a higher frequency (and potentially voltage) without exceeding the overall power budget (which is what TFA says Intel is doing).
My server
The link to "single core overclocking" states:
"This is not overclocking. Overclocking is when you take a chip and increase its clock speed and run it out of spec."
THis is just a technique to stay under the specified power envelope. Nowadays not the speed is the real problem, but the powerusage. Not that in single thread mode the CPU will run less instructions per watt.... and i guess for every 25% more cpu frequency you you 75% more power or or something like that.
"We have been working with Microsoft," Intel hinted."
Now I know to avoid it.
Exactly... I was going to quote the exact same phrase as the one you quoted: I don't agree with that dumb "tacit admission" statement. It's really about getting the best of both worlds. Not too mention that it's not just "multi-core for multithreaded apps" but also "multi-core for correctly multithreaded OSes".
I doubt it. My reading of the article is that the CPU detects when only one core is in use and does everything itself. But, even if it does require some level of OS support, I wouldn't worry about Linux's support of it (or of UEFI, for that matter, as Linux runs quite well on Macs and Intel does a good job of supporting Linux, anyway). Linux even has support for hotplugging CPUs, so, even if it comes to that (and I doubt it will), then it should still work.
Any change in a CPU's implementation should not be observable to anyone unless the observer knows to look for it (e.g. with the CPUID instruction). Intel won't release a chip that breaks existing apps. Besides, if you think about it, if apps work on a single-core CPU, why shouldn't they work on a dual-core CPU with one core disabled?
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
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.
since we've already got to write somewhat parallel code [because cores are pipelined what, 20 deep now?], it'd be nice if that parallelism extended easily to multi cores. For example, when dividing up some function that reduces [large array -> scalar], we've already got to split execution 20 ways. It'd be nice if there was some way to split such things into the minimum arbitrary number of independent threads supported by the machine, at runtime.
We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
http://www.mactel-linux.org/wiki/Main_Page
I think you are right. Doing something multithreaded takes a lot of extra thinking. Even for someone who knows what their doing. I took a parallel programming course, and that was where things got really fun. Things get really complicated once you start programming things to work in parallel. Not only that, a lot of apps won't really speed up a noticeable amount from using a multi-threaded architecture. I hope that compilers can help this out, because programming multiple threads is hard enough, not to even get started on parallel algorithms.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
VLC FOR MAC IS DYING! IF YOU DEVELOP, PLEASE SAVE 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.
So basically the limiting factor in CPU design nowadays is power consumption? It can only use upto a set quantity of power, regardless of the number of cores?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
The submitter said UEFI, It's usualy only called EFI. The Universal must have thrown them off.
Assuming they read the submission, of course.
Like they did with OpenFirmware?
Death to BIOS.
I was under the assumption that the big problem with macs supporting pc video cards was bios vs EFI. Will this move allow quicker adaptation of video cards to move to the mac? I would assume that if they start using UEFI just like apple does now, that it would just be a OS X driver issue, and no longer a bios vs EFI issue.
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.
### 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
As long as we are using C or C++ I doubt that will happen, those languages are just not build with multi-threading in mind and thus aren't easily to parallelize, other languages like functional ones on the other side make the job really easy. When you don't have side effects to worry about, executing things in parallel becomes rather easy and straight forward. So I hope that switching to multi-core will also mean that we will finally switch to more advanced languages, its really time, but so far using them didn't provide much different in the end, with multi-core on the other side they could really have some huge advantages, not only will they lead to better code, but also to faster code.
Till that happens multi-cores should still be quite beneficial, I currently have 120 processes running, while many of them just idle most of the time, its not that unusual to have two or more processes that want all the CPU they can get, good thing when you then actually have two CPU cores to give them.
Good lord, let me sell all my web, application, and DB servers then!!!! I've overpaid for 32 CPU systems!!!! ACK!!!
The cesspool just got a check and balance.
As you will then them to boot a efi system as with a mac pro when you put in a non efi card you get no video until you boot windows.
And an non EFI raid card may not be able to boot in a efi system.
> "We have been working with Microsoft," Intel hinted."
What a shame. All Microsoft care about is locking down the PC platform and further entrenching their malware. What's in this for OSX, BSD and Linux users (as opposed to Microsoft prisoners)?
Let's apply this thinking to another topic:
By the way, I actually hope that many things never become object oriented. In my experience, most coders simply aren't capable of thinking OOP through clearly. For many people, the concept is just too complex. Hopefully, compilers will improve to the point where many things can be implemented using OOP techniques without the coder having to know very much, if anything, about the architecture involved, but, today, we're nowhere near that. We desperately need higher-level OOP in computer science.
Just as with OOP, if the technology is not made available then architects and coders will never learn the concepts, because they'll have no exposure to it. Oh sure, an architect at a well-run software company *MIGHT* have the time to keep up with academic publications and the latest proposed technology, but seriously: when was the last time your emoployer gave you the time to pick up a new skill until it was time to actually use it? Sure, Google provides paid research time to their employees which could be used to keep abreast of new technologies and perhaps even experiment with them, but who else does? I know my employers haven't - but then again everyone regularly put in 60-70 hours per week with ongoing promises of an IPO and things finally stabilizing. The IPO never happened; the pigfucking CEO simply drew larger and larger salaries and bonuses year after year.
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.
Concurrent applications needn't be so difficult to program. Take a look at the actors model and STM.
What's unfortunate is that we're stuck on this idea that concurrency == multiple threads w/shared state. With that approach, sure, apps will never scale. You're right, we do need higher-level threading primitives. I'm just not so sure they're all at the compiler level.
most applications, like games and emulators, benefit more from one fast core contra multiple slower ones. There are also applications such as Matlab, where ease of use takes the high seat over performance.
By convincing Intel to make Santa Rosa EFI-Only, MS can ensure that none of their pesky users will be able to install XP on it.
Nothing like using monopoly influence to prop of sales of your lastest OS that no one really needs or wants.
I suspect this isn't so much about power as it is about temperature. With a dual-core chip, you expect both cores to contribute 50% to the heat load. If one core's throttled back, you can overdrive the other core without the chip overheating.
I think this analogy is a bit disingenuous. First, OOP isn't all that complicated, and I did acknowledge that better tools that hide the complexity will help things. The other thin you have to consider is that OOP and threading are meant to achieve two separate goals. OOP is meant to simplify design whereas threading is meant to increase performance, often at the expense of simplicity. Threading is fundamentally harder than OOP because it's harder to think about, and it only matters if you need performance. OOP is a good idea to make a good design. That is always important. Threading, as it exists today, is actually at odds with correctness as it is much harder to guarantee correctness in the presence of threading. As correctness trumps performance any day ("I can make any program run instantly if it doesn't need to produce a correct result"), threading should be used sparingly. Oftentimes, you can make better performing apps by concentrating on other things, anyway.
Anyway, I don't know why I'm writing so much. I could have just substituted "brainfuck" in place of OOP and shown that, just by substituting a word, you haven't proven anything. Just because it was a good idea to use OOP doesn't make it a good idea to use threading.
BTW, where do you get your information about Google employees having paid research time? Google employees have 20% time, certainly, but that isn't "paid research time".
Reading your post make it sound like a Webapp, to be multi-threaded, can simply create one thread per user connecting to the Webapp. Maybe it's not what you meant, but it's how I read your post. Things are way more complicated than that. Many of the biggest Websites are backed by Java (I'll just cite three: GMail, eBay, FedEx). In Java, it used to be that one new thread was created per user session... But this simply wouldn't scale: it is fine for toyish websites, running a few simultaneous users, but it won't scale. The cost for multi-threading in Java (and presumably in C# as well), after a certain number of threads, is just too high.
Making a multi-threaded Webapp by assigning a thread to each user is naive and unsustainable...
If your OS allows spyware to install itself into the EFI partition then it is broken. :)
"Personally, I consider myself a damned good coder"
It only counts if OTHERS consider you a damned good coder.
Thanks for that. I shouldn't have concentrated on the compiler. What I really think we need is language-level constructs, but that's certainly not what I said.
I like the actor's model. It sounds like a formalization of message-passing, which (as I mentioned cross thread), is, in my opinion, the best multiprocessing model we have so far.
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).
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.
The cesspool just got a check and balance.
We want it now! Run It On The Silicon!
Give us an FPGA coprocessor on chip.
Deleted
Seriously, several constructs in Fortran are designed specifically for parallel execution. Not quite. FORTRAN 90 was an attempt to freshen up FORTRAN 77 to become like other languages (pointers, recursion, structures, dynamical memory management), but nothing there is particularly suited for or enforcing the parallel programming. There is an attempt though to make FORTRAN 90 "high performance", HPF (High-Performance Fortran), by adding some even older things, like side-effect free constructs that would help compiler automatically vectorize certain operations (vectorization is important in scientific/engineering applications), but, historically speaking, already LISP was better for parallelization than FORTRAN, like when you add two lists with (mapcar #'+ a b), compiler knows that all individual additions can be done in parallel. Nowadays you can use OpenMP (which is SMP oriented and newest versions of gcc support it) or MPI (which is message-passing oriented) both in FORTAN or C(++) that lets you give instructions where and how to parallelize; in terms of more general programming languages, there are Erlang and Ocamm.
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.
...other languages like functional ones on the other side make the job really easy
I/O
Monads
CSP for the win
d
http://www.vitanuova.com/inferno/limbo.html
http://plan9.bell-labs.com/magic/man2html/2/threa
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Sooon the chinese will release the Dragon3 CPU. The Dragon3 CPU will be MIPS and will run at 3000 Bogomips. That is equivalent to a 1.5GHz pentium but without MMX (the most failed extension ever), SSE (this one too!), Virtualization Technology and DRM stuff. Then, chinese hackers will add a Dragon3 backend to gcc (easy since its MIPS) and then port linux kernel to it. And then, voila. The world will switch over to Dragon3 CPUs with OpenBIOS and no DRM. You'll be able to run windows with qemu. x86+nVidia+GPU will become a high performance playstation for kids....
Chinese: the government that cares more about its 1Bn citizens than US lobbies.
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...
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.
When one core is idle, the other one will only speed up by 200 or 400 MHz. So you have a choice between, say 2.4+2.4 GHz or 2.6+0 GHz.
I guess those who like UEFI (Unsolicited Electronic Finger in the Asshole) would appreciate Intel's probings into this area.
Data partitioning is what defines whether or not something can be parallelized and to what degree. The reason why Fortran (which another poster mentions) has the 'ability' to make decisions about what can be parallelized is fairly strong. If you notice, they are mostly restrictions on functions (no memory aliasing) and hints (the data in this loop can all be worked on in parallel).
Even when you look at Message Passing, you'll notice that all the synchronization and methods are centered on data movement (availability to the node to be worked with). You'll also notice that many of the producer/consumer (master/slave, etc.) built-in algorithms require the programmer to structure the data in such a way as to packetize the blocks of data to fit certain qualifications so that the built-in algorithms have no data sharing violations.
Compilers and hardware figure out instruction streams that are parallelizable fairly well. OOOE and pipelines are all about this in hardware and autovectorization is easy provided there are hints that the compiler is allowed to use it (and strictures such as 'no aliasing allowed' are sort of hints). It's partitioning the data that's hard, and can be very much a runtime issue.
...heterogeneous cores? Like where both cores are from the software perspective still SMP but one core is physically better for overclocking. For example, manufacturing standards could be raised so that one core has better specifications than the other and/or chips manufactured so that one core gets more cooling, etc...
Apologies for feeding the troll.
Godless heathen.
'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."'
$10 bucks says this heralds a new age of DRM.
I understand that it doesn't work at this point, sorta like "don't cross the streams" from ghostbusters.. But really, we're talking about a long series of math problems at this point, why not interleave? I understand the math is hard, that's why intel has all of those Phd's. Getterdun. I wants me some Quake 9 a 4.2 billion frames per second. Plus, programming multithreaded is all superhardish!
The advent of multicore CPUs HAS hurt single-threaded app performance. You must compare today's multicore CPUs with what would otherwise exist if development efforts were invested, instead, on accelerating single core performance like had always been done in the past. In that light it's clear that today's single threaded apps would be running faster had technology not changed direction.
I'm not arguing that multicore isn't the right thing to do but your assertion is not correct. Who knows what reality would be today if multicore wasn't pursued, but odds are it would be faster than a single Core2 core.
Multicore CPUs will likely affect single-threaded app performance. Core will probably become slower and simpler so more can be shoveled onto a CPU. If the number of transistors per CPU can't grow (as Moore's Law hits a brick wall), then reducing the number of transisters per core is how manufacturers will increase the number of cores per CPU.
One workaround, though, would be asymmetric multiprocessing: pair one fast single-core CPU with a slow many-core CPU.
cpeterso
The advent of multicore CPUs HAS hurt single-threaded app performance. You must compare today's multicore CPUs with what would otherwise exist if development efforts were invested, instead, on accelerating single core performance like had always been done in the past. In that light it's clear that today's single threaded apps would be running faster had technology not changed direction.
I think you're wrong. Multicore didn't require any particular development -- basically it's a cut-and-paste job. Intel even went for the real cut-and-paste job with their quad-core; just producing two dual-core processors and putting them in one package. Increasing single-thread performance on the other hand requires serious research at this point. All the cheap stuff has been done. IPC increases a few percent here and there, with lots of effort, and frequency increases a bit faster than that. Look at the Itanium for a serious attempt at single-thread performance. Not doing well.
Finally! A year of moderation! Ready for 2019?
EFI being able to run code, contact the internet and police my actions even BEFORE ANY OS loads, before I have ANY CONTROL?
FSCK EFI. I refused to buy any Intel Mac because of it, because I know what it will be used for.
Until I have user control of EFI, what comes and goes in/out of my machine they won't get my money.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Open Firware has been around a lot longer than intel's EFI, and is used by Sun, IBM and Apple for their RISC boxes.
There is a free-as-in-speech implementation for the PeeCee called OpenBIOS.
It's implemented in FORTH.
Stick Men
well, congrads on setting an unnecessary upper bound on the types of programming problems you're willing and able to tackle. being able to partition a problem into subtasks, understanding their interdependencies and devising the proper inter-process communication mechanism for sharing results and data, while non-trivial, is not infeasible. and it's necessary. supercomputers are all clusters now, and in many ways always have been. server farms are the norm now, and are being built at an alarming rate. there ARE actual mhz limits in this world, and compensating for the old von-neumann bottleneck with bigger and bigger caches is a generating a horrible ROI, silicon wise. so if you can't grow up, grow out.
:)
the whole "carburetors are good enough / fuel injection is for pussies" argument will only turn you into that grouchy old man whining about where all the ASM jobs have gone. multithreading on multiprocessor/cluster systems (and non-uniform memory architectures) are the future.
(btw, i left my cushy programming gig to pursue my phd in exactly this area - gotta love volunteered poverty
http://kered.org
Precisely! I'm expecting this bug to show up in Vista any day now! ;-)