Who's right, us or them, is the wrong question.
It's apples and oranges, for this simple reason:
Software companies sell upgrades at a reduced price to achieve customer lock-in. They want to keep you from switching to a competing product. If upgrading and switching cost the same, there's nothing stopping you from switching. That's why upgrades are cheap.
On the other hand, most people listen to more than one band, and getting cheap music "upgrades" will not keep you loyal to your first band, because bands are not mutually exclusive.
What if we had a sort of "CPU NFS" in a way that individual instructions are handed off to remote machines, rather than entire jobs?
Nope, not worth it. One of the basic tenets of distributed computing is that the gain from splitting up the computation has to outweigh the cost of communicating the results of that computation. That is, if it takes a couple nanoseconds to do the instruction, but it takes a few hundred microseconds to send off that instruction and get the results back, then it's a lose.
The only way to make fine-grained parallel computing a win is to make communication between nodes really, really cheap. And it doesn't sound like they're doing that here. Therefore, they must be doing coarse-grained parallel computation, probably on the scale of many seconds of computation between communications.
This is really fantastic. Now all I need is to hook up a Game Boy emulator to the sewing machine instead, and make the sewing machine sew anything I want rather than just the preprogrammed things. How about a sewing machine that knows PostScript?
But seriously, one of the things that frustrates me the most about many embedded systems like sewing machines, microwaves, car stereos, and so on, is their lack of programmability. It frustrates me that my car stereo prefers to show me which CD track I'm on by default rather than what time it is. I'm a programmer, I could fix that... but I can't get at it. The more flexible and programmable these systems get, the better.
Re:NP Non-deterministic Polynomial
on
Does P = NP?
·
· Score: 3
Of course, there are two possible outcomes:
1. The algorithm has a flaw and won't work.
2. The problem presented was not NP Complete, but only NP or P.
Actually, there's a third possibility, by far the most likely one. The algorithm posed may solve the problem exactly, but still require NP time to do it. That is, the algorithm is right, but the analysis of the algorithm is wrong. I think most stories about NP=P finally being proven end up this way.
Who's right, us or them, is the wrong question.
It's apples and oranges, for this simple reason:
Software companies sell upgrades at a reduced price to achieve customer lock-in. They want to keep you from switching to a competing product. If upgrading and switching cost the same, there's nothing stopping you from switching. That's why upgrades are cheap.
On the other hand, most people listen to more than one band, and getting cheap music "upgrades" will not keep you loyal to your first band, because bands are not mutually exclusive.
What if we had a sort of "CPU NFS" in a way that individual instructions are handed off to remote machines, rather than entire jobs?
Nope, not worth it. One of the basic tenets of distributed computing is that the gain from splitting up the computation has to outweigh the cost of communicating the results of that computation. That is, if it takes a couple nanoseconds to do the instruction, but it takes a few hundred microseconds to send off that instruction and get the results back, then it's a lose.
The only way to make fine-grained parallel computing a win is to make communication between nodes really, really cheap. And it doesn't sound like they're doing that here. Therefore, they must be doing coarse-grained parallel computation, probably on the scale of many seconds of computation between communications.
This is really fantastic. Now all I need is to hook up a Game Boy emulator to the sewing machine instead, and make the sewing machine sew anything I want rather than just the preprogrammed things. How about a sewing machine that knows PostScript?
But seriously, one of the things that frustrates me the most about many embedded systems like sewing machines, microwaves, car stereos, and so on, is their lack of programmability. It frustrates me that my car stereo prefers to show me which CD track I'm on by default rather than what time it is. I'm a programmer, I could fix that... but I can't get at it. The more flexible and programmable these systems get, the better.
1. The algorithm has a flaw and won't work.
2. The problem presented was not NP Complete, but only NP or P.
Actually, there's a third possibility, by far the most likely one. The algorithm posed may solve the problem exactly, but still require NP time to do it. That is, the algorithm is right, but the analysis of the algorithm is wrong. I think most stories about NP=P finally being proven end up this way.