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."

6 of 184 comments (clear)

  1. Bloat by metamatic · · Score: 3, Insightful

    Every time I think software can't get any more bloated, I wait a year or two and it doubles in size again.

    --
    GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
    1. Re:Bloat by euice · · Score: 5, Insightful

      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".

    2. Re:Bloat by metamatic · · Score: 4, Insightful

      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
    3. Re:Bloat by bit01 · · Score: 3, 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.

  2. small code is hard work by NotInTheBox · · Score: 4, Insightful

    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
  3. The future of computing is transparent. by The+Living+Fractal · · Score: 5, Insightful

    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.