The Future of Computing 184
An anonymous reader writes "Penn State computer science professor Max Fomitchev explains that computing has evolved in a spiral pattern from a centralized model to a distributed model that retains some aspects of centralized computing. Single-task PC operating systems (OSes) evolved into multitasking OSes to make the most of increasing CPU power, and the introduction of the graphical user interface at the same time reduced CPU performance and fueled demands for even more efficiencies. "The role of CPU performance is definitely waning, and if a radical new technology fails to materialize quickly we will be compelled to write more efficient code for power consumption costs and reasons," Fomitchev writes. Slow, bloated software entails higher costs in terms of both direct and indirect power consumption, and the author reasons that code optimization will likely involve the replacement of blade server racks with microblade server racks where every microblade executes a dedicated task and thus eats up less power. The collective number of microblades should also far outnumber initial "macro" blades. Fully isolating software components should enhance the system's robustness thanks to the potential of real-time component hot-swap or upgrade and the total removal of software installation, implementation, and patch conflicts. The likelihood of this happening is reliant on the factor of energy costs, which directly feeds into the factor of code optimization efficiency."
Bloat (Score:4, Insightful)
Re:Bloat (Score:5, Interesting)
Re:Bloat (Score:5, Interesting)
uTorrent != Open Source
uTorrent isn't the fastest torrent program around either, and neither does it have the most features. It probably doesn't strike the best balance either.
Next time you get the "uTorrent is b3tt4r!" bull from the #footorrents channel, read the "only 6mb memory requirement" or the "170KB binary size statistics: consider the fact that uTorrent is missing lots of features, isn't FOSS, depends on an OS with a circa 256mb base requirement, and isn't as fast or as nice with IO as some other clients [rakshasa.no].
Then perhaps later, consider that the hallmarks of a good program aren't good benchmarks, but good design. The fact that Debian comes on seven cdroms and with 18,000 programs doesn't mean that WinXP is faster because it only comes on one.
Re:Bloat (Score:4, Informative)
Re:Bloat (Score:2)
For a good time, try this:
I don't have ktorrent installed, but other simple KDE apps show dependencies on at least 22MB of librariesRe:Bloat (Score:2)
For a software giant, they[ms] aren't that userfriendly. Total bullshit.
If everything built in the industry is like this then I guess they have the backing of the power companies.
Re:Bloat (Score:5, Insightful)
Re:Bloat (Score:2)
Yes, companies are falling over themselves to pay 100 salaries instead of a small handful of slightly larger salaries.
Re:Bloat (Score:2, Offtopic)
Been there, done that. However, we failed to get HR to tell us what categories we'd been assigned to; the best we got was to be given a copy of the rating system so we could decide where we thought we sat, with a promise that we'd have some feedback - feedback that never came, of course.
b) 10% less than his boss
Prior to the jobspec matrix, we were told by our MD that we earnt as much as, or in some cases more than, some middle- to senior mana
Re:Bloat (Score:2)
This is also the reason why a mere increase in the number of cores is no panacea. Although programmers need to start taking explicit parallelism more seriously, certain tasks simply cannot be split up. In many cases a task cannot continue until it has data that has been calculated by a previous task. There is no way around this. So, with the exception of embarrassingly parallel [wikipedia.org] tasks developers and corporations are just going to have to bite the bullet in terms of incr
Re:Bloat (Score:4, Interesting)
Re:Bloat (Score:4, Insightful)
certain tasks simply cannot be split up.
That's a popular idea. It's almost always wrong.
It may be true that something can't be split up well automatically but pretty much any practical task can be parallelized to some degree manually.
Seriously, I challenge anybody here to name even one real-world CPU or IO intensive task that cannot be split up. Even things like encryption and compression can be pipelined and there are complicated mathematical and statistical tricks including speculative execution that can be applied as well.
It may not be cost effective to do the split but if money is no object some parallelism will almost always help. Yes, tasks can have chokepoints but these become irrelevant if you can parallelize the work before and after the chokepoint.
There are obscure mathematical exceptions, dependencies on external events and it may be hard to do with the tools being used but that's not what I'm talking about here.
---
Creating simple artificial scarcity with copyright and patents on things that can be copied billions of times at minimal cost is a fundamentally stupid economic idea.
Re:Bloat (Score:2)
http://islab.oregonstate.edu/koc/ece679/project/2
Re:Bloat (Score:3, Funny)
It's true! No GUI has ever been as snappy as classic Mac OS!
Re:Bloat (Score:2, Informative)
Re:Bloat (Score:3, Informative)
Re:Bloat (Score:2, Interesting)
depending on wich of the three great mac classic ages we're talking about 7, 8, or 9 that wasn't really true
7: had to run on both 68k machines as well as the newer ppc machines and the numerous clones of the day, but still managed to perform quite well on all of them
8: was the first to run on ppc and the g3 line of chips along with supporting a new proggraming system with the carbon libraries
9: well nine sucked and im turning into a troll as i type so i just call it non classic
Re:Bloat (Score:2, Interesting)
While companies that can decrease the production time of creating a program will spend less money on the developers. Efficiency is not a priority as most users do not understand the concept. If a program runs slowly on a user's computer the novice user will think it's a problem with the computer and not the program.
Re:Bloat (Score:5, Informative)
Really? Languages don't get much more high-level than Smalltalk, and a Squeak does things that C/C++ programs seem to require a lot more bloat to manage.
Re:Bloat (Score:5, Insightful)
Re:Bloat (Score:3, Interesting)
Here here. Well said. That, precisely, is the core of the problem. The only way that is going to change is if the market forces their hand. If/when the speed of a single core finally does hit a wall, we may see this. It's all about priorities. Developers are making an explicit choice in favor of reduced development time at the expense of exploding minimum machine requirements for nearly identical tasks. The end user really has no wa
Re:Bloat (Score:2)
Re:Bloat (Score:2)
Re:Bloat (Score:2)
New Type of Bloat: Hardware (Score:2)
The only solution to the curse of infinitesimally small features is modular redundancy: hardware duplication. Triple modula
heh (Score:5, Funny)
Spoken like a true Microsoft programmer.
This is called "the wheel of reincarnation" (Score:3, Insightful)
The Foley and van Dam classic, "Fundamentals of Interactive Computer Graphics" cites Myer and Sutherland's description of adding more intelligence to graphics processors until they become the equivalent of CPUs, at which point they repeatedly find themselves slower than mass-production CPUs and are turned back into simple devices driven by fast external CPUs once more (;-))
--dave
Re:This is called "the wheel of reincarnation" (Score:3, Interesting)
Re:This is called "the wheel of reincarnation" (Score:2, Insightful)
Code optimization != specialized blades (Score:2, Interesting)
Re:Code optimization != specialized blades (Score:2, Interesting)
Of course it is not. Why doesn't everybody realize, that this Max Fomitchev has absolutely no idea what he's talking about. This is complete rubbish. "Microblades" to save power? Come on, do the math: More power supplies that produce energy loss (no power supply has an efficiency of 100%), more complex software (because tasks are split up over different cpu's and have to communicate over a sort of network connection)...
Wirth's law (Score:2, Insightful)
That's why I don't buy those Python/Ruby/Java productivity boasts. I'd rather do it efficiently in C/C++ right now than wait for a faster CPU that may never come.
Re:Wirth's law (Score:2)
Re:Wirth's law (Score:2)
Re:Wirth's law (Score:2)
Re:Wirth's law (Score:3, Insightful)
For a one-off script that's gonna be run once and never used again, slow inefficient code that's quick to write makes sense... But for the majority of code that's going to be run over and over again, the time you saved writing the code could be wasted 10 times over waiting for it to run.
Re:Wirth's law (Score:2)
That's only relevant if the user is waiting for the code to run.
Consider a "report feature" in many systems. More often than not you are waiting for the database to return the query and then the printer to print it. While it might take 30 seconds to produce the report from start to finish the "code" you wrote only runs for 1 second total, even in a high level interpreted script. Is there really a point to spending 10x the effort to cut the code
Re:Wirth's law (Score:2)
Yeah. How often does that happen? If you can manage to allow ALL of your code to run while waiting for a user response (or the hard drive or whatever) then bravo. But that is not the case for the vast majority of the code out there and you know it. Obviously no one is going to start optimizing code with
Re:Wirth's law (Score:2)
Re:Wirth's law (Score:2)
That's why I don't buy those Ford/Honda/Toyota productivity boasts. I'd rather travel efficiently on my bicycle right now than wait for a faster vehicle that may never come.
Re:Wirth's law (Score:2)
The Ford is the faster vehicle, and we already have the infrastructure.
Re:Wirth's law (Score:2)
Precisely my point. In both the software and transportation scenarios, the modern mechanisms already exist and are already faster and more efficient than the old ones. Sorry if my sarcasm wasn't obvious enough.
Re:Wirth's law (Score:2)
O is real. C is real. D is not real.
O needs D.
O is not used because there is no D so C is used.
In you post:
O is D. O is real, but despite their being the same thing D is not. Problem #1. C is real.
O and D are the same thing, somehow dependent on each other. Problem #2.
O is not used because it is real but it is not real. Problem #3. C is used.
It's not the language, stupid! (Score:5, Interesting)
Either you have constant time, nlogn, or even n algorithms that run OK (CPUs today are fast enough that even for a decent sized n, an n algorithm will be executed shortly). However, no computer humans can ever build that works on the same principles as your desktop computer will be able to do 2^n, n^n, or n! algortihms in any kind of useful time for large n.
You might be able to get results in a lesser amount of time if you can parallelize the work (see the Distributed.net cracking efforts on factoring into large prime numbers), but if you can't make the algorithm work in parallel or otherwise reduce it to a polynomial time algorithm, even a supercomputer from the year 50,000 won't solve these problems for large n.
Don't focus on the language; that's the wrong area to look.
Re:It's not the language, stupid! (Score:2)
And here is where a couple of people would disagree with you. C/C++ has extremely well-performing optimizing compilers (alignment, instruction sets, etc.) and so for verrrry small datasets, a 2^n algorithm in C will most likely run faster than a n log n algorithm in, say, Ruby.
(I don't have data to support my hypothesis, but I wi
You're not understanding. (Score:3, Informative)
1 2 0 100
2 4 0.602059991327962 100.602059991328
3 8 1.43136376415899 101.431363764159
4 16 2.40823996531185 102.408239965312
5 32 3.49485002168009 103.49485002168
6 64 4.66890750230186 104.668907502302
7 128 5.9156862800998 105.9156862801
As you can see, for n less than 7, n * log n + 100 (which assumes our language is 100 times slower to run our n*log(n) algorithm vs. our 2
Re:You're not understanding. (Score:2)
Please don't forget that I emphasized "verrrrrry small datasets". I was trying to point out that, let's say, for three elements using a bubble-sort algorithm is faster than quicksort.
And yes, compilers aren't little magical black boxes. But the human brain is.
Re:You're not understanding. (Score:2)
If you do, you will find that the crossover is around n=647 for a relative speed of 100x (647*647 = 418609 vs 100*647*log(647)=418760), or around n=282 for a relative speed of 50x.
However, your broader point stands, since 50-100x ratios are what you might expect for a poorly interpreted language, and JITs or other optimizing compilers perform at the same order of magnitude
Re:You're not understanding. (Score:2)
However, the bad algorithm was 2^n not n^2 (which is also stupid in itself...)
Re:It's not the language, stupid! (Score:2)
A programmer who knows how to choose the right algorithm will do so regardless of the language being used. So given the correct algorithm, it boils down to the BIG FAT CONSTANTS that determine better performance. Lower level languages like C++ can make those constants smaller.
but it is not what the GP says (Score:2)
The GP is comparing for the same implementation the speed difference. So if you implement a stupid N^2 bubble sort in C++, it will be slow as hell, but stil better
overly simplistic analysis (Score:2)
Is C/C++ a panacea? Of course not -- straw man. But when your algorithms are equal, high-level languages will execute an al
Re:It's not the language, stupid! (Score:2)
Not so. [debian.org]
Re:It's not the language, stupid! (Score:2)
Re:It's not the language, stupid! (Score:2)
Will repeating this to myself 100 times help me believe it? Not that I would be one to dis Java. Of the languages in common use it seems most suited to the difficulties due to the SMP environments which are quickly becoming the standard. That reason alone may be enough to use it for high performance code especially once quad and higher cores become common. I suspect in a couple of years nearly everyone will be running qua
Re:It's not the language, stupid! (Score:3, Interesting)
I think that should help quell the fears of Java vs. C, anyway.
Re:It's not the language, stupid! (Score:2)
Re:It's not the language, stupid! (Score:2)
Your tests were wrong. Your C implementations were suboptimal compared to your java and erlang ones, or else they were comparing non-interesting examples. To pick one of many possible examples, any language with automatic garbage collection is going to be measurably slower than a language where the programmer optimises the memory allocation by hand, in many real-world cases (because garbage col
Re:It is the language, kind of (Score:2)
Re:Wirth's law (Score:2, Informative)
If the only good thing going for such languages is that they are "high-level", and higher level languages must be slow and clunky (like BASIC, which doesn't belong in the same category), then I could see your point. However:
1. Languages like Python gained popularity as a glue language. 90% of it is running C/C++ for the heavy lifting anyway.
2. Such
Re:Wirth's law (Score:2)
You aren't doing it (much) faster in C or C++; at least not in all cases. Even for algorithms that are routinely used to check language performance (such as Linpack) customised Java VMs equal C code. Java is not interpreted - it is translated to byte code that is then compiled into machine code with a considerable amount of run-time optimisation
Re:Wirth's law (Score:2)
I saw the Byte magazine in a newsstand for the first time in August 1978, the cover story was about Pascal and I bought it. I still have that magazine. Inside there's an article about how Pascal was compiled to an intermediate form called "P-code". As you can see, the Java VM isn't such a new invention.
But optimization isn't about byte code alone. As someone men
Re:Wirth's law (Score:2)
It certainly isn't. The VM is much older than that - Smalltalk was using a VM in 1972.
But optimization isn't about byte code alone. As someone mentioned in this thread, algorithms can be much more important.
Re:Wirth's law (Score:2)
Until the day when you can say "hey, Duke Nukem Whenever is written in Java", that's all theory. If you can do run-time optimization for Java you can also do it for C++. The only thing that keeps anyone from writing a byte-code compiler for C++ that dynamically optimizes it for the processor is that, in the bottom line, the advant
Re:Wirth's law (Score:2)
Re:Wirth's law (Score:2)
I see. Well, then let me rephrase that: I'd rather do it efficiently in C/C++ right now than wait for an efficient Python compiler that may never come.
However, it seems that Lisp compilers are becoming too fast for some people today, because some of the old Lisp gurus are migrating to Python [norvig.com]. A better proof of this "Wirth's law" couldn't exist.
Re:Wirth's law (Score:2)
Re:Wirth's law (Score:2)
Re:Wirth's law (Score:2)
small code is hard work (Score:4, Insightful)
Compare: "Easy writing makes hard reading." -- Ernest Hemingway
Re:small code is hard work (Score:2)
the cost of hardware... (Score:5, Interesting)
Spirals? (Score:2)
Re:Spirals? (Score:2, Funny)
Dupe? (Score:2, Troll)
Seriously. Not the same story, true, but the same title, over and over. Just look. [slashdot.org]
Re:Dupe? (Score:2, Funny)
"radical new technology"? (Score:5, Interesting)
While I believe processors are currently heavily outmuscleing the exchange rate of primary memory, and that this gap should be closed, I don't believe the era of power expansion is over.
While chipmakers are becomming increasingly environmentally conscious by increasing performance per watt, they are also abandoning hype based "clock speed" development and actually focusing on reducing cycles per instruction, raising instructions per second, optimizing pipelining, and increasing responsiveness.
While this might not be seen as power growth it is, but it's similar to the difference between overall horsepower vs torque on a vehicle.
in the previous decade, most vehicles had decent horsepower but low torque, now the carmakers focus on less fuel hungry but higher torque engines, but as a side effect they also get more HP per liter.
Some thoughts (Score:5, Interesting)
Yes, he is right. The problem is that http://en.wikipedia.org/wiki/Unix_philosophy [wikipedia.org] has been very long forgotten from the manifacturers of OS for 90% of the PC's around the world. I do not want to start a flamewar, just consider how many features of the OS you really need? It is arguably a GOOD practice to put everything you can in an OS, but for cryin' out loud, at least there must be a way to remove the unneeded parts.
> Slow, bloated software entails higher costs in terms of both direct and indirect power consumption, and the author reasons that code optimization will likely involve the replacement of blade server racks with microblade server racks where every microblade executes a dedicated task and thus eats up less power.
That looks like where we're heading now. Jut consider the 1000 projects for distributed computing out there, and the whole virtualization thingy. But this by itself cannot mean that much less power. If you want less consumption, you have to rely on technology AND on more optimized software.
> The collective number of microblades should also far outnumber initial "macro" blades. Fully isolating software components should enhance the system's robustness thanks to the potential of real-time component hot-swap or upgrade and the total removal of software installation, implementation, and patch conflicts.
YES!!! That's what we're talking about, man! We need separate modules to do the work. Just for info, try googling for Microkernels vs. Monolithic. Tannenbaum has good arguments in favor of microkernels in terms of stability. I don't want to take either side, but it is true that whilst a mere 99.999% of the cars don't suffer from reboots of their onboard computers, our desctops still do. Remember the old joke: "You've moved your mouse. Please restart your computer for the changes to take efect."
> The likelihood of this happening is reliant on the factor of energy costs, which directly feeds into the factor of code optimization efficiency."
Maybe we should move into higher-programming languages that take most of the optimizations hidden from the programmer. For example I have recently read a review that optimizied Java code is VERY near native C performance. Even if that is not true, C is not adapded enough for the various SSE, SIMD and so on optimizations in the modern PCs. Yes, GCC makes all kinds of optimizations, but maybe WE need to move into higher-order logic for our programs?
Re:Some thoughts (Score:2)
This is actually not true. Car computers *do* crash and reboot, they just do it automatically and very very quickly. The thing has to respond correctly within X milliseconds, or a supervising piece of hardware simply resets it, and it starts working again within Y more milliseconds - maybe you get a couple misfires, but the car basically keeps on
Spiral spirals (Score:2)
virtualization, generators, and languages (Score:4, Interesting)
while the article has lots of intersting data and information, he doesn't know much about predicting the future
He's right on focusing on memory (vs. CPU) - this is where the major bottlenecks are
He completely missed the boat though on virtualization. Everywhere I look there are different examples of virtualization that are driving development choices - and he doesn't mention it once.
he also is missing the tide happening right now with metaprogramming and generators
also missing the boat on the trends in language flexibility that are turning application development into "domain specific language" development. we're at a tipping point over the current 2-3 year horizon where developers are building out the language AT THE SAME time they write their application. coupled with effective reuse strategy, this will revolutionize how quickly and how functional all our apps can be.
it sucks that tesxt is static, there are a huge number of ideas here, and I have not expressed them as well as I'd like, but alas, once submitted, the text can't change, and it presents the same info to each reader, no matter what their context or background is. I like talking to people much better.
Re:virtualization, generators, and languages (Score:2, Insightful)
Be vague.
KFG
Re:virtualization, generators, and languages (Score:2)
Old is new and new is old. [wikipedia.org]
Re:virtualization, generators, and languages (Score:2)
Or stated for the simple minded in search of a moral compass: "There is nothing new under the sun..."
Single page print version of article (Score:3, Informative)
Buy SUNW (Score:2, Interesting)
Oh, and I don't have any Sun stock myself, heheh
The future of computing is transparent. (Score:5, Insightful)
Take for example Google. What happens when you can query a search into google without actually interfacing with an external device like a laptop with a wireless internet connection? Or into Wikipedia? You'll be able to answer questions within seconds of being asked. Maybe less. This is a bigger change than you might think. Where does this leave conventional schooling, for example?
To me, it's exciting. And I wish it were here already.
TLF
Re:The future of computing is transparent. (Score:2)
The true future of computing is highly parallel systems. Think quantum computing. We will eventually eliminate the entire concept of serialized computing like we have today. Computing time will no longer be an issue as everything will compute instantly. Software will be much more about the algorithm rather than the hardware. In a highly p
Re:The future of computing is transparent. (Score:2)
Re:The future of computing is transparent. (Score:2)
What about the idea of putting a stitch in time to save nine? Al says there's no such thing as time anyway.
Re:The future of computing is transparent. (Score:2)
Many times my crackpot friends and I will end up on 3-hour conference call marathons and start hashing out various schemes and ideas (nothing dangerous or illegal, I assure you). Oftentimes the flow of our conversation is shattered by a Google query or Wikipedia search; a quick pause to determine a specific point, settle a debate, what have you. This will almost spark further discussion (read: tangents), and the hours just start to fly by.
IMO, it would be
Article Difficult to Read (Score:2, Informative)
"Breaker" model (Score:2)
As I see it, the history of computing is one of repeated waves that crash against the beach as the next wave gathers behind it. In terms of corporate IT, this is marked by shifts back and forth between centralized and distributed computing, but the phenomenon encompasses all of computing.
What happens in each phase is that the new model is adopted first at the grass roots -- individual users or small groups see the "new thing" as a way to get something done, and start using it under the radar. It's frequ
Dr. Dobbs editors don't edit (Score:2, Interesting)
Discreet elements were gradually replaced with integrated circuits
"Discrete elements"
Intel's new "Woodcrest" server chip as only 14
"Woodcrest server chip has only 14"
speculative threading in the vane of to Intel's Mitosis.
new manufacturing technology in the
Wrong motivation (Score:2)
I don't think so. The motivation for multitasking was to allow data to be exchanged between applications while both were still running as well as allowing a longer-term task to run in the background while the user does other work. The trade-offs between running a single application and muliple applications at the same time are actually rather independent of CPU speed.
Compelled to write more efficient code (Score:2)
LACK of power created demand for multitasking (Score:3, Insightful)
Multitasking is for getting the most our of your computer (whether it's fast or slow) but pays off most rewardingly when it's slow. If processors and I/O were infinitely fast, people wouldn't give a damn about multitasking, because they would never be waiting for their computer to complete a task. It's when you have to wait for something that you most enjoy multitasking; it lets you use your machine for doing something else instead of twiddling your thumbs staring at the progress indicator.
Let's say you want to render a graphics scene, download a file, and edit a text document. An MSDOS user would do those things serially, sadly knowing that:
And this was true whether it was a 4.7 MHz XT or a 100 MHz 486. "Extra power" had nothing to do with it. Indeed, the 486 user probably lamented MSDOS' lack of multitasking less (not more, as the author suggests) because the rendering would be so much faster.
Meanwhile, the 7 MHz Amiga user, despite the seemingly "wimpiness" of his machine (HA!), did all three operations in parallel. His CPU stayed at 100% utilization, his serial port downloaded as fast as it could, and his text editor easily kept up with his typing. The Amiga user gets the most out of his machine. Not because the Amiga is fast, but because multitasking mitigates slowness.
It's the mere desire to get the most work done, that led to multitasking on personal computers. It wasn't the "extra power" that did it. It just seemed that way to the x86 users (and probably only the x86 users) because the slow chips (8086) just happened to have very poor support for multitasking compared to the fast chips (80386). So multitasking appears to correlate with speed. But for the x86ers, it was really a question of CPU features, rather than performance.
The crux of the author's error is this: "We had extra power and we wanted to do something with it." He has forgotten that "we wanted to do something with it" whether or not we had "extra power."
Re:Time to pull out my... (Score:2, Funny)
Translucent 3D! Just like real cards.
KFG
Re:Time to pull out my... (Score:3, Insightful)
Even Vista only requires a ~800 MHz computer for the "Vista Capable" label, stupid!
Seriously, if all you want to do is to play Solitaire, why don't you grab MS-DOS and a DOS version of Solitaire and check the minimum requirements? Chances are it'll end up at something less than 8 MHz at least. But it won't be that suitable for many other modern world scenarios than playing Solitaire, you won't get something too much better than monochrome tex
Re:Bloat (Score:2)