Keep in mind that Google doesn't rely on the newest, fastest chips, they instead rely on numerous inexpensive paralell systems. Read their tech page if you don't believe me. http://www.google.com/intl/en/corporate/tech.html so "processing massive amounts of data on the web" doesn't really apply. In fact there are no or nearly no problems in computer science that benifit from using multiple cores or CPU's in a way that can't be replicated using a cluster or grid approach. While advances are always welcome, this area doesn't exactly cry out for hardware innovation.
Paralellism-on-a-chip doesn't let us do anything we couldn't already do, and most applications that benifit from it are outside the domain of the general consumer.
Faster graphics, sound, sure these things might benifit from on-a-chip paralellism, but consider how many PCs the average consumer has. Now consider the number of embedded processors they have weather they know it or not. Their vehicle, the HVAC system in their home, cell phones, radios, televisions and so on. Clearly, embedded processors vastly outnumber PC processors and, as I said, essentially none of these benifit from paralell computing.
Now lets consider the benfits of hardware advances in embedded systems/realtime technologies. The smaller and faster a DSP chip can be the smaller your cell phone can be, and the more information can be packed into a limited singal bandwidth, just as one example, Sounds good to me.
Now lets consider the benfiits of hardware advances in paralellism-on-a-chip. very few because corporations can string together many cheap PCs while outside of video games consumers don't benifit much from paralellism.
Considering the availablity of a cheap and effective substitute to paralellism on a chip, the relative prvalance of embedded systems, and the difference in potential gains from advances in each field, yes, I would say that any list that entirely discounts embedded/realtime systems is 'cherry-picked.'
Sure, I can try. All of this stuff about branch prediction is basically the result of something called 'pipelining.' The rational for pipelining goes something like this: an instruction on a modern computer chip is executed in several stages (fetch, decode, execute, and writeback, in an iconic sense) For any particular instruction you can't begin one stage before you've completed the previous stage. Different stages require different hardware on the chip, so in a non-pipelined CPU some parts of the chip are just sitting there much of the time, that is bad.
The reigning solution to resolve this is pipelining. Each of the stages I listed above is segregated, and as an instruction exits one stage, another instruction begins that stage.
This is all well and good except, what happens if the instruction being decoded depends on the results of the instruction being executed? The results are unknown, so do you sit and wait? You can get around this problem somewhat by complicating the chip a little to feed the results of in-process computations back to later instructions in the same pipeline that require them.
But now you've got a branch, and you can't even tell what instruction to load next until you know what the condition on that branch is going to evaluate to, the best a chip can do in this case is guess (branch prediction) but if you're wrong you have to throw out all the speculative computations you did. Modern processors rely heavily on pipelining so an incorrect guess can set them back significantly, especially if they make a habbit of it.
You're not running Google's backend at home, are you? The carefully cherry-picked sample of tasks provided doesn't represent an accurate cross section of the things computers are used for. Your car's engine isn't doing a lot of sound processing, is it? Your cell phone isn't doing a lot of 3D graphics?
I won't try to downplay the application of paralell processing in many profesisonal or academic situations, but the demands of consumers and realtime systems have a few things in common, they both seek to optimize response to relativly simple yet incredibly arbitrary tasks. Paralell processing is next to useless for that.
Okay, first, complaining about how long it takes to get an MBA is unfair. People in technical fields can work just as long and just as hard to obtain thier own degrees.
Your janitor analogy is incorrect. The problem with undereducated 'janitor' managers isn't that they don't know about heavy duty garbage bags, it's that they they demand the janitor wax the floors with a broom, or paint without moving furniture away from the walls. Managers don't need to know how to do the jobs of the people they manage, but they do need to understand enough to appreciate the consequences of their decision and respect the abilities of their employees. If it's my job to fix spyware over and over rather than install a program that'll do it automatically, fine, but my manager must accept that there's a time trade-off in that.
A manager also needs to know that someitmes, the anwser is no. I'd love for my boss to know that there's no way for two computers to communicate without a connection of some sort, be it cat 5, wireless, cellular or whatever. I *expect* to be beleived when I say this on the grounds of my qualifications. More often than not, though, that's not how it works and a 3 months struggle (or more) results to defend my 'position' that a requriement is technically unfiesable even when it flies in the face of common sense.
Don't be silly. Musicians don't set the price for thier music, generally. Nor do novellists set the price for thier books. As a software engineer I will be lucky to own about 1% of what I create in a professional capacity in my life and it is highly unlikely that my pay will be explicitly correlated to how well any product I contribute to sells. Many creative people are paid for the creation of their work and never again.
Creative arts have worked on a system of patronage before, and in effect they still do. When your publisher patron tires of you, you're done.
Right now I trade software and money for grades. I hope to someday be paid for it. I wholeheartedly endorse piracy.
Software development is a service. As a software engineer my job to study the situation of my stakeholders and produce and refine software that will facilitate them. As long as stakeholders exist that want new software, or want their existing software to be different than it is (and they always will) I'm not afraid pirates can steal my work because I'm selling effort towards something that does not yet exist.
If that's what software development is, I don't see how piracy of existing software hurts you, as somone who 'writes software' for a living. Can you explain?
Slashdot Mirror
Paralellism-on-a-chip doesn't let us do anything we couldn't already do, and most applications that benifit from it are outside the domain of the general consumer. Faster graphics, sound, sure these things might benifit from on-a-chip paralellism, but consider how many PCs the average consumer has. Now consider the number of embedded processors they have weather they know it or not. Their vehicle, the HVAC system in their home, cell phones, radios, televisions and so on. Clearly, embedded processors vastly outnumber PC processors and, as I said, essentially none of these benifit from paralell computing.
Now lets consider the benfits of hardware advances in embedded systems/realtime technologies. The smaller and faster a DSP chip can be the smaller your cell phone can be, and the more information can be packed into a limited singal bandwidth, just as one example, Sounds good to me.
Now lets consider the benfiits of hardware advances in paralellism-on-a-chip. very few because corporations can string together many cheap PCs while outside of video games consumers don't benifit much from paralellism.
Considering the availablity of a cheap and effective substitute to paralellism on a chip, the relative prvalance of embedded systems, and the difference in potential gains from advances in each field, yes, I would say that any list that entirely discounts embedded/realtime systems is 'cherry-picked.'
Sure, I can try. All of this stuff about branch prediction is basically the result of something called 'pipelining.' The rational for pipelining goes something like this: an instruction on a modern computer chip is executed in several stages (fetch, decode, execute, and writeback, in an iconic sense) For any particular instruction you can't begin one stage before you've completed the previous stage. Different stages require different hardware on the chip, so in a non-pipelined CPU some parts of the chip are just sitting there much of the time, that is bad. The reigning solution to resolve this is pipelining. Each of the stages I listed above is segregated, and as an instruction exits one stage, another instruction begins that stage. This is all well and good except, what happens if the instruction being decoded depends on the results of the instruction being executed? The results are unknown, so do you sit and wait? You can get around this problem somewhat by complicating the chip a little to feed the results of in-process computations back to later instructions in the same pipeline that require them. But now you've got a branch, and you can't even tell what instruction to load next until you know what the condition on that branch is going to evaluate to, the best a chip can do in this case is guess (branch prediction) but if you're wrong you have to throw out all the speculative computations you did. Modern processors rely heavily on pipelining so an incorrect guess can set them back significantly, especially if they make a habbit of it.
You're not running Google's backend at home, are you? The carefully cherry-picked sample of tasks provided doesn't represent an accurate cross section of the things computers are used for. Your car's engine isn't doing a lot of sound processing, is it? Your cell phone isn't doing a lot of 3D graphics?
I won't try to downplay the application of paralell processing in many profesisonal or academic situations, but the demands of consumers and realtime systems have a few things in common, they both seek to optimize response to relativly simple yet incredibly arbitrary tasks. Paralell processing is next to useless for that.
Okay, first, complaining about how long it takes to get an MBA is unfair. People in technical fields can work just as long and just as hard to obtain thier own degrees.
Your janitor analogy is incorrect. The problem with undereducated 'janitor' managers isn't that they don't know about heavy duty garbage bags, it's that they they demand the janitor wax the floors with a broom, or paint without moving furniture away from the walls. Managers don't need to know how to do the jobs of the people they manage, but they do need to understand enough to appreciate the consequences of their decision and respect the abilities of their employees. If it's my job to fix spyware over and over rather than install a program that'll do it automatically, fine, but my manager must accept that there's a time trade-off in that.
A manager also needs to know that someitmes, the anwser is no. I'd love for my boss to know that there's no way for two computers to communicate without a connection of some sort, be it cat 5, wireless, cellular or whatever. I *expect* to be beleived when I say this on the grounds of my qualifications. More often than not, though, that's not how it works and a 3 months struggle (or more) results to defend my 'position' that a requriement is technically unfiesable even when it flies in the face of common sense.
Don't be silly. Musicians don't set the price for thier music, generally. Nor do novellists set the price for thier books. As a software engineer I will be lucky to own about 1% of what I create in a professional capacity in my life and it is highly unlikely that my pay will be explicitly correlated to how well any product I contribute to sells. Many creative people are paid for the creation of their work and never again.
Creative arts have worked on a system of patronage before, and in effect they still do. When your publisher patron tires of you, you're done.
Right now I trade software and money for grades. I hope to someday be paid for it. I wholeheartedly endorse piracy. Software development is a service. As a software engineer my job to study the situation of my stakeholders and produce and refine software that will facilitate them. As long as stakeholders exist that want new software, or want their existing software to be different than it is (and they always will) I'm not afraid pirates can steal my work because I'm selling effort towards something that does not yet exist. If that's what software development is, I don't see how piracy of existing software hurts you, as somone who 'writes software' for a living. Can you explain?