Slashdot Mirror
The Future of Computing
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."
>> we will be compelled to write more efficient code
Spoken like a true Microsoft programmer.
That's very true. I always wonder why some programs have to be a few tens of megabytes (especially some shareware ones) and then a (usually open source) program comes along that's 1/10th of the size of the previous program and has more features (e.g. uTorrent vs everything else). I know that processor speed and memory are practically unlimited so you don't have to worry about them, but this is just stupid.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
Well, they keep thinking that 100 developpers can do the same job as a handful of good developpers. That's wrong most of the time, as in "9 women can have one baby in one month".
Writing small is difficult and I don't think it can be done in a group. Most software which is small is written bij less then 3 programmers.
Compare: "Easy writing makes hard reading." -- Ernest Hemingway
What I cannot create, I do not understand
...is strongly dependent on the interfaces it presents to the world. The pressure is to push more and more functions onto a chip so that external interfaces can be eliminated. This is the victory of the general purpose computer. While in the short term it is always possible to build faster, more speciallised hardware to perform a function, eventually a faster CPU chip which implements the same facility in software becomes cheaper and generic.
Gaming continues to be highly demanding on computer systems.
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.
VLC FOR MAC IS DYING! IF YOU DEVELOP, PLEASE SAVE IT!!
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.
I am TheRaven on Soylent News
> "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.
Yes, he is right. The problem is that http://en.wikipedia.org/wiki/Unix_philosophy 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?
It's the algorithm. It's straight complexity theory; C/C++ is not a panacea. If you write a 2^n or n! algorithm in C, it'll have its doors blown off by an nlogn algorithm in Python.
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.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Today we have bulky boxen and entire rooms filled with computers. We have computers taking up space in our offices and homes. We dedicate energy to just keeping them cool. Tommorow (ok, so not really tommorow, probably in the semi-distant future) we won't really see computers at all in terms of our daily routines. They'll be so miniaturized as to become transparent. The only aspect of computing we'll see in our daily lives will be the user interfaces. The actual computers themselves will be invisible, or at least barely noticeable. They'll become mere extensions of our every whim, capable of reinforcing and improving our minds in a seamless fashion. That, I believe, is the future of computing.
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
I do not respond to cowards. Especially anonymous ones.
Small binary size != Fast program
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.
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.
No, bloat is avoidable yet not avoided in high level languages too. For example, I wrote an RSS and Atom library in Ruby, because I didn't like the one in the standard library--it was ugly code and badly documented. I expected my replacement to be slower and larger, because it was clean understandable code. To my surprise it was half the size and twice as fast. But we're still stuck with the crappy one, because it was the first one hacked together and therefore became part of the standard libraries. And that's the root problem--we have a culture where implementation speed is valued over everything else.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak