Let me put it like this. What if the kid was a whiz programmer, and they said he had taught himself "C, C++, Perl, Python, Ruby, Java, Lisp, Prolog, and x86 assembly in a week"? It's nonsense. There's more information there than can be read in a week, let alone applied and digested.
What does that imply about the claim, then? Well, for our hypothetical whiz programmer, it means he knows how to write "hello, world" a lot of different ways, but lacks the capacity to use the strengths of each language. He's committed the grievous error of the breadth-first search in an expertise-driven field. And I submit that the same thing holds for our actual math genius, here -- which I would further claim is a tragedy.
If they held this kid accountable and really put him through the full coursework, he could turn into a very powerful mathematician, or physicist. But if they're letting him skate by with thinking he's taught himself everything there is to know about every major branch of mathematics inside of a week, they're ruining his ability to carry his investigation with scientific rigor. What he's learned is no doubt the trigonometric identities, the power and chain rules, and similar "first brush" material, and will spend the next two decades with mistakes and discoveries that have already been made countless times before.
Genius is a reason to work more, not less. Removing responsibility from our best and brightest is one of the biggest threats to our prosperity.
This is an important right. Surely you won't argue that an artist shouldn't have the right to sue to protect their own intellectual property. So what we're talking about here is duration and damages. The way it's setup now -- it's plain to see that the duration is too long and the damages are too high. But that's what courts do: they decide what's appropriate. It doesn't matter what the labels say. Because Limewire probably says they want to go home scot-free with their attorney's fees paid for. How is that any less of a total over-reach? The right answer is some place in-between. And that place will be decided by the courts.
This could not be more wrong.
The courts have never extended copyright. They have nothing to do with this. At all.
All copyright extensions have resulted from legislation, meaning Congress. Which makes the curious inability of copyright to ever expire seem a bit strange.
Also, I've been waiting my whole life for someone to justify 80+ year copyright terms, in any way at all. That's an open invitation. I'd settle for someone justifying 20+ year terms. In any capacity. My opinion is you can't, because it doesn't make any sense.
Okay, I'll bite. Let's say we've got an enclosed and connected laptop keyboard that is 4mm thick. (This is what you proposed in your comment.) Assuming all the leading tech companies of the world donate three years of their best engineers' time to help you figure out how you're going to build it, the end result is exactly like typing on a rock. What, exactly, does this gain over a more focused, thinner, lighter, cheaper tablet design, when you can type on the screen itself and gain fully programmable buttons?
In addition, your numbers are pessimistic. Samsung just announced the Galaxy Tab 10.1 -- it's a tablet with a 10.1 inch screen that's less than 9mm thick.
Yes it is. Their first duty should be increasing their quality of service for their customers, the ones they have locked into a 2 year contract. Choosing to buy a bunch of new customers instead of improving and maintaining their infrastructure is like being slapped in the face with their cock.
Completely wrong. Their first duty is, and should be, staying in business. The "quality of service for their customers" will develop something of a negative trend if they bust and file bankruptcy.
What you're saying is no one should save money, ever, becuase it's obviously better to spend it on yourself as soon as you give it.
There is absolutely nothing wrong with AT&T maintaining equity, and nothing wrong again with them using it to increase their customer base and coverage footprint. Expecting them to keep themselves constantly "broke" is a little alarming, tbh.
Yeah, problems always look easy after someone else has solved them for you, I guess.
Your advocacy of blissfully ignoring the internals fits in well with all the "yay Visual Studio!" and "yay.NET!" that I'm hearing in these comments; a legion of dull-eyed "developers" that are perfectly happy to eat only the food provided them, trusting their master to give them the right balance of nutrients. I'm sorry if that sounds harsh, but this whole thing is disgusting.
How much better is Direct3D on Linux? How's that fork of Direct3D coming? When you leave state of the art to the corporations, and the corporations have huge marketshare, innovation dies. Is that what we want? Are we, after all the struggles to get here, content to lay under this particular tree until we rot?
But even that is just a result of people using a proprietary, Windows-specific API (DirectX) which then has to be completely reimplemented while working blind in Linux. Games that use OpenGL often have superior performance when ran in Linux, even when they have to go through WINE. And as for linux-native games, I don't think that "sudo apt-get install some-game" is really "hours of config time."
None of those links are a year old. One of them is from two weeks ago. If you want an overnight revolution you're in the wrong place; software is hard.
In time, we can probably clean up the half-ass trash that ATI released. I'm not ragging on them -- big props for releasing the stuff at all, and we can, in time, take care of the rest. But it's still half-ass buggy trash *grin* there's a lot of cleaning to do.
You know, what you said would make perfect sense if it were said by someone who managed after all these years to still not know what "Open Source" means. H.264 is a good product, but it's not a free one -- beer-wise or speech-wise. WebM is open source and free in both senses.
You can go get some source code right now if you want to. Tweak the algorithms. Compile it locally. Integrate as a first-class caller. That's open. Not another lock-in attempt with everyone in on it this time.
It wouldn't have the first thing to do with people beating a path to your door, and lots to do with "what YouTube does, I can do for cheaper (less ads, more content) -- and better is just a side effect." You are falling for the classic error of having this idea that just because something is popular it is inviolate. Look at MySpace. That was a pretty thorough monoculture, and yet one quarter it just deflated. Facebook. Altavista. Geocities. Gawker. Are you really claiming eternally enduring web sites? Show me a website that has survived on something besides merit.
You're assuming that algorithms are a product, which I am not convinced of. Video encoding is one of a class of problems which is not yet solved; i.e. we're constantly improving at it. Having a large target use an open-source tool attracts more development, not less; or, put another way, business dollars are not the only source of development funding.
Do you really think that a site driven by a qualitatively better codec couldn't threaten YouTube, especially if its lower bandwidth requirements lowered its costs? You keep talking about monoculture -- but surviving as a company because you have secret tools is hardly a strong business model. Tell me why there still exist compilers besides GCC, or web servers besides Apache, or heck, shells besides bash? By your theory, those should all be monocultures with no alternatives. Yet markets thrive around all of them. (Well, maybe not a financial market around bash, but a market nontheless *grin*)
Your way, there are a million development hours split across a hundred codecs. My way, those hours improve in the same place, and the people who want something different can still go and create it. Trying to introduce some kind of software socialism where the company gets to hide its toys so that people don't use them only leads to the situations that exist in the real software markets -- Microsoft on every machine. Now that's a monoculture.
Just for fun, submit a patch to Mozilla that changes the factory default search of Firefox to Bing, and see how "immune to this kind of treatment" Open Source Software really is.
They're free to accept it or not accept it. I tell you what, though, if I wanted a build of Firefox that changed the default page to Bing, I could do it, and run it, and no one would stop me. I could even make it a formal fork and distribute it for the people that wanted it. I can't imagine many would want it, so it wouldn't get much action. Why do you advocate "propping up" inferior, unwanted software? And why don't you try making a custom build of Internet Explorer?
So you don't think Google is interested in the real money it could save by creating better codecs, allowing them to reduce bitrate for current quality, and saving them a tremendous amount of bandwidth?
Also, I take issue with this: "people might invent better codecs...bring them to market." Do you bring equations to market? No, of course not. You bring products to market. Charging for encoding/decoding is a doomed business model and it deserves to be for a lot of reasons, not the least of which is the age-old data format lock-in that companies more interested in profit than innovation (the very ones you are defending) have been pushing for years. That's what I and many other people here are trying to tell you -- open-sourced code is immune to this kind of treatment, because it can't be taken back or controlled; and when it grows large enough to attract a plurality of development, it becomes strong just on the basis of people not wasting time reinventing the wheel and instead contributing their effort to new frontiers.
Eh, it's a logical step. Graphics is, has been, and will always be about parallelism and matrices. Supercomputing is almost always about simulation and high-order computation, which works out to the same thing. Really good graphics hardware, thirty years ago, or now, or thirty years in the future, will always be good science hardware, and supercomputing is driven by science.
From the fucking dictionary: 1. a state in which the supreme power rests in the body of citizens entitled to vote and is exercised by representatives chosen directly or indirectly by them.
? This is what I just said. Right up there. I'll quote it for you:
A representative democracy with constitutional limitations to protect the individual is the very DEFINITION of a republic. Do some reading.
So, violate contracts and break the law. I don't know if that counts as "positively useful". In addition, you're kind of glossing over how this would go down. "Our suspect is no longer being tracked by his GPS tag, but his last position was right at the middle of what became a zone of GPS failures. Perhaps we might have to use the same methods we've been using for hundreds of years to find him instead of looking at the GPS readout."
Re: 1984 -- if things were that bad a GPS jammer to fool with your tracking device is laughably token resistance. Re: things are already that bad, no, they're not.
A computer having its available data indiscriminately wiped is a comparable disaster to a catastrophic car failure in the amount of disruption it can cause. You are consummately guilty of not thinking about the implications of what you advocate, and in the classic manner are attempting to shout down anyone who might expose flaws in your reasoning.
Now, you've extended the analogy farther than it was originally grown, and in doing so invalidated it. Computers are not cars. Routine maintenance on a computer will not keep it in working order in the same manner as a car. An engine's enemy is entropy. Your computer's enemy is far more insidious, if a bit less relentless.
There is no 'routine maintenance' that can be performed on computers to safeguard them. There is no simple five-step program that any person can follow. The closest you can get is mass-market virus scanners and the like, and while those might stop 90% of the problem -- at considerable cost to the host environment -- the 10% remaining is the worst 10%. There isn't a period of warning with computers like there is with cars -- indeed, it's much the opposite. Once you've noticed a problem it's far too late. Preventive security on complex systems is hard.
Your talk of responsibility is immature nonsense. No one is resisting responsibility. But your stance to 'solve' this problem is to say, well, just make everyone responsible for everything -- we'll take every person in America and make them get a four-year degree in system security, and then if anything goes wrong we'll have someone to blame it on! If anyone doesn't bother putting themselves through the highest level of education specifically on the topic of securing their systems, then they should obviously lose their data! It's a complete denial of reality.
So, tell me, is this how you feel about your banking institution? You really don't care if they are breached if they 'learn their lesson'? Your health care provider? Your employer? Your daughter? Do you really believe that data is only valuable to the person that possesses it?
We're all living in the Real World, and your views will someday -- when you're older, no doubt -- incorporate that. For now, you've built up some oversimplified model of society, and its application is not only undesirable, it is completely unfeasible.
Yeah, I mean, I think they should make cars that blow up if you don't check the oil, belts, timing belts, brakes, transmission, coolant, tires, hoses, spark plugs, wires, distributor caps/rotors, and air filters precisely at the best mileage for each! That way, people who refuse to help themselves by daring to drive a car without knowing the full maintenance schedule (and implications of missing parts of it) will be taken out of the education. Those stupid, incompetent, lazy people.
I never suggested that synchronization is free. However, a CAS or other (x86-supported!) atomic instruction would suffice, so you are talking about one extra cycle and a cache read (in the worst case) for the benefit of working (at least) twice as fast; you will benefit from extra cores almost linearly until you've got the entire thing in cache.
The cache stuff is pretty straightforward. More CPUs = more cache = more cache hits. Making the assumption that a[], b[], and c[] are contiguous in memory only increases this effect -- in your scenario, there is only one cache, and you'll have at most * 3 of the values local; whereas for every cpu you add in distribution the value increases linearly for quite some time.
This is ignoring the trivially shallow dependance of the originally proposed computation (there's a simple loop invariant) and making the assumption that a difficult computation is being done.
You might be tempted to pre-compute B[i]+c[i] in one thread and add in a[i-1] in another, but you then have 2 problems. First, if you aren't doing a barrier sync in the loop the second thread might pass the first and the result is junk, but if you are, you're burning more time in the sync than you saved. Next, the time spent in the second thread loading the intermediate value cold from either RAM or L1 cache into a register will exceed the time it would take to perform the addition.
Given some time, I can easily come up with far more perverse cases that come up in the real world.
...of course there's going to be some kind of synchronization. The suggestion otherwise implies a lack of experience in the field; failure to plan sync before anything else is an undergrad mistake.
I fail to see how the sync burns more time than you save by threading the computation. It seems to me that doing operation a and operation b in sequence will almost always be slower than doing them simultaneously with one joining the other at the end (or, better and a little trickier, a max-reference count for the dependent thread).
Re: cache, you are making strong assumptions that you're going to get cache hits for equidistant indecies across three arrays. In the kind of real-world computations that need this kind of hardware, you're not going to look at three flat 100 element arrays. You're going to be looking at 10k x 10k x 10k arrays, and the number of cache hits you get is not going to decrease by parallelizing the work -- indeed, since you're getting more cache for every node, the cache hits are going to increase with any degree of optimization. This is true in all cases.
There is nothing 'perverse' about the case you have presented. It's a trivial optimization problem that doesn't require more than a basic knowledge of cache and some hint of the target architecture. The more perverse cases are the ones that get worked on at the highest level, and I have seen no proof of any computational problem that is sequential in the fastest case.
You do realize that if you go off-node on your cluster even over infiniband the 1uS is about equal to a late 1960's core memory access time right?
Sure, but having 1960 mag core access to entirely different systems is pretty good, I'd say. And it will only improve.
It's a false dichotomy. There are some problems that clusters are bad at. That is true. The balancing factor that you are missing is that there are problems that single-proc machines are bad at, also. For every highly sequential problem we know, we also know of a very highly parallel one. There are questions that cannot be efficiently answered in a many-node environment, but there are also questions that can be answered far faster. What you're saying is basically that a desktop computer running modern games doesn't need a GPU, it just needs a faster CPU. It's failing to optimize for the problem; driving the screw with a hammer, if you will.
There is no such thing as effective "brute force parallelize". Effective concurrent computation requires thought. Sequential programming is MUCH easier to design and optimize for; that's the draw of single-proc systems. There is nothing inherently non-partitionable about "a[i] = b[j] * c[k] + d[l]"; indeed, I would submit that there are very easy threading optimizations that can be done for any combinations of i,j,k,l; a single thread of execution is GUARANTEED to be slower than even the most trivially optimized multithreaded case. Any multithreaded case benefits from additional execution units up to the number of threads as long as the computation bandwidth (NOT the interprocess bandwidth!) increases enough to account for the increase in computation latency (which is linked to, but not identical to, interprocess latency).
Sequential is dying, because it's suboptimal. Trying to burn the gas faster and faster doesn't get around the fact that the engine just isn't that efficient.
Well, yeah, if you deliberately design a program to not take advantage of the architecture it's running on, then it won't take advantage of the architecture it's running on. (This, btw, is one of the great things about Linux, but that's not really what we're talking about.)
One mistake you're making is in assuming only one kind of general computing improvement can be occurring at a time (and there is some good, quality irony in that *grin*). Cray (and others) can continue to experiment on the edge of the thermal/lightspeed barrier, while others can simultaneously increase computing resources by running clusters.
There's nothing inherently detrimental about clusters, and almost all tasks can be parallelized to some degree. There are, of course, always latency and bandwidth issues in distributed memory systems, but InfiniBand (which is what serious clusters use) has latency in the 1 microsecond range, which is only about five times memory latency itself, and a bandwidth that you'll never saturate with current data distribution models (we're working on that).
It's true that typically performance to processor growth is sublinear, but it's also nonzero. For even moderately parallel tasks, a $300k cluster can outperform a $3M supermachine, and the failure of that to extend to the very boundary is more an effect of our inability to grok the parallel coding model (parallel code is hard); as we understand more and more about concurrent programming you will see the oft-cursed 'penalty' of cluster computing dwindle more and more towards nothing.
PC manufacturers have no obligation to set up a special process to attend to the desires of the vanishingly small % of the population that wants a bare metal PC.
Ah, yes, I would like to refer you to the article being discussed. You see, quite honestly, yes, they do.
You should not confuse your opinion of what is important with some kind of objective measure of what is important.
Slashdot Mirror
It's not about being "smart (for math)".
Let me put it like this. What if the kid was a whiz programmer, and they said he had taught himself "C, C++, Perl, Python, Ruby, Java, Lisp, Prolog, and x86 assembly in a week"? It's nonsense. There's more information there than can be read in a week, let alone applied and digested.
What does that imply about the claim, then? Well, for our hypothetical whiz programmer, it means he knows how to write "hello, world" a lot of different ways, but lacks the capacity to use the strengths of each language. He's committed the grievous error of the breadth-first search in an expertise-driven field. And I submit that the same thing holds for our actual math genius, here -- which I would further claim is a tragedy.
If they held this kid accountable and really put him through the full coursework, he could turn into a very powerful mathematician, or physicist. But if they're letting him skate by with thinking he's taught himself everything there is to know about every major branch of mathematics inside of a week, they're ruining his ability to carry his investigation with scientific rigor. What he's learned is no doubt the trigonometric identities, the power and chain rules, and similar "first brush" material, and will spend the next two decades with mistakes and discoveries that have already been made countless times before.
Genius is a reason to work more, not less. Removing responsibility from our best and brightest is one of the biggest threats to our prosperity.
This is an important right. Surely you won't argue that an artist shouldn't have the right to sue to protect their own intellectual property. So what we're talking about here is duration and damages. The way it's setup now -- it's plain to see that the duration is too long and the damages are too high. But that's what courts do: they decide what's appropriate. It doesn't matter what the labels say. Because Limewire probably says they want to go home scot-free with their attorney's fees paid for. How is that any less of a total over-reach? The right answer is some place in-between. And that place will be decided by the courts.
This could not be more wrong.
The courts have never extended copyright. They have nothing to do with this. At all.
All copyright extensions have resulted from legislation, meaning Congress. Which makes the curious inability of copyright to ever expire seem a bit strange.
Also, I've been waiting my whole life for someone to justify 80+ year copyright terms, in any way at all. That's an open invitation. I'd settle for someone justifying 20+ year terms. In any capacity. My opinion is you can't, because it doesn't make any sense.
Okay, I'll bite. Let's say we've got an enclosed and connected laptop keyboard that is 4mm thick. (This is what you proposed in your comment.) Assuming all the leading tech companies of the world donate three years of their best engineers' time to help you figure out how you're going to build it, the end result is exactly like typing on a rock. What, exactly, does this gain over a more focused, thinner, lighter, cheaper tablet design, when you can type on the screen itself and gain fully programmable buttons?
In addition, your numbers are pessimistic. Samsung just announced the Galaxy Tab 10.1 -- it's a tablet with a 10.1 inch screen that's less than 9mm thick.
Yes it is. Their first duty should be increasing their quality of service for their customers, the ones they have locked into a 2 year contract. Choosing to buy a bunch of new customers instead of improving and maintaining their infrastructure is like being slapped in the face with their cock.
Completely wrong. Their first duty is, and should be, staying in business. The "quality of service for their customers" will develop something of a negative trend if they bust and file bankruptcy.
What you're saying is no one should save money, ever, becuase it's obviously better to spend it on yourself as soon as you give it.
There is absolutely nothing wrong with AT&T maintaining equity, and nothing wrong again with them using it to increase their customer base and coverage footprint. Expecting them to keep themselves constantly "broke" is a little alarming, tbh.
Yeah, problems always look easy after someone else has solved them for you, I guess.
Your advocacy of blissfully ignoring the internals fits in well with all the "yay Visual Studio!" and "yay .NET!" that I'm hearing in these comments; a legion of dull-eyed "developers" that are perfectly happy to eat only the food provided them, trusting their master to give them the right balance of nutrients. I'm sorry if that sounds harsh, but this whole thing is disgusting.
How much better is Direct3D on Linux? How's that fork of Direct3D coming? When you leave state of the art to the corporations, and the corporations have huge marketshare, innovation dies. Is that what we want? Are we, after all the struggles to get here, content to lay under this particular tree until we rot?
But even that is just a result of people using a proprietary, Windows-specific API (DirectX) which then has to be completely reimplemented while working blind in Linux. Games that use OpenGL often have superior performance when ran in Linux, even when they have to go through WINE. And as for linux-native games, I don't think that "sudo apt-get install some-game" is really "hours of config time."
None of those links are a year old. One of them is from two weeks ago. If you want an overnight revolution you're in the wrong place; software is hard.
In time, we can probably clean up the half-ass trash that ATI released. I'm not ragging on them -- big props for releasing the stuff at all, and we can, in time, take care of the rest. But it's still half-ass buggy trash *grin* there's a lot of cleaning to do.
You know, what you said would make perfect sense if it were said by someone who managed after all these years to still not know what "Open Source" means. H.264 is a good product, but it's not a free one -- beer-wise or speech-wise. WebM is open source and free in both senses.
You can go get some source code right now if you want to. Tweak the algorithms. Compile it locally. Integrate as a first-class caller. That's open. Not another lock-in attempt with everyone in on it this time.
What's the difference between fake and genuine empathy? What is genuine empathy?
It wouldn't have the first thing to do with people beating a path to your door, and lots to do with "what YouTube does, I can do for cheaper (less ads, more content) -- and better is just a side effect." You are falling for the classic error of having this idea that just because something is popular it is inviolate. Look at MySpace. That was a pretty thorough monoculture, and yet one quarter it just deflated. Facebook. Altavista. Geocities. Gawker. Are you really claiming eternally enduring web sites? Show me a website that has survived on something besides merit.
You're assuming that algorithms are a product, which I am not convinced of. Video encoding is one of a class of problems which is not yet solved; i.e. we're constantly improving at it. Having a large target use an open-source tool attracts more development, not less; or, put another way, business dollars are not the only source of development funding.
Do you really think that a site driven by a qualitatively better codec couldn't threaten YouTube, especially if its lower bandwidth requirements lowered its costs? You keep talking about monoculture -- but surviving as a company because you have secret tools is hardly a strong business model. Tell me why there still exist compilers besides GCC, or web servers besides Apache, or heck, shells besides bash? By your theory, those should all be monocultures with no alternatives. Yet markets thrive around all of them. (Well, maybe not a financial market around bash, but a market nontheless *grin*)
Your way, there are a million development hours split across a hundred codecs. My way, those hours improve in the same place, and the people who want something different can still go and create it. Trying to introduce some kind of software socialism where the company gets to hide its toys so that people don't use them only leads to the situations that exist in the real software markets -- Microsoft on every machine. Now that's a monoculture.
Just for fun, submit a patch to Mozilla that changes the factory default search of Firefox to Bing, and see how "immune to this kind of treatment" Open Source Software really is.
They're free to accept it or not accept it. I tell you what, though, if I wanted a build of Firefox that changed the default page to Bing, I could do it, and run it, and no one would stop me. I could even make it a formal fork and distribute it for the people that wanted it. I can't imagine many would want it, so it wouldn't get much action. Why do you advocate "propping up" inferior, unwanted software? And why don't you try making a custom build of Internet Explorer?
So you don't think Google is interested in the real money it could save by creating better codecs, allowing them to reduce bitrate for current quality, and saving them a tremendous amount of bandwidth?
Also, I take issue with this: "people might invent better codecs...bring them to market." Do you bring equations to market? No, of course not. You bring products to market. Charging for encoding/decoding is a doomed business model and it deserves to be for a lot of reasons, not the least of which is the age-old data format lock-in that companies more interested in profit than innovation (the very ones you are defending) have been pushing for years. That's what I and many other people here are trying to tell you -- open-sourced code is immune to this kind of treatment, because it can't be taken back or controlled; and when it grows large enough to attract a plurality of development, it becomes strong just on the basis of people not wasting time reinventing the wheel and instead contributing their effort to new frontiers.
Eh, it's a logical step. Graphics is, has been, and will always be about parallelism and matrices. Supercomputing is almost always about simulation and high-order computation, which works out to the same thing. Really good graphics hardware, thirty years ago, or now, or thirty years in the future, will always be good science hardware, and supercomputing is driven by science.
"some useful algorithms are sequential" != "no useful algorithms are parallel"
Care to define "real workloads" for us, cowboy?
Wrong again, Bob.
From the fucking dictionary:
1. a state in which the supreme power rests in the body of citizens entitled to vote and is exercised by representatives chosen directly or indirectly by them.
? This is what I just said. Right up there. I'll quote it for you:
A representative democracy with constitutional limitations to protect the individual is the very DEFINITION of a republic. Do some reading.
A representative democracy with constitutional limitations to protect the individual is the very DEFINITION of a republic. Do some reading.
So, violate contracts and break the law. I don't know if that counts as "positively useful". In addition, you're kind of glossing over how this would go down. "Our suspect is no longer being tracked by his GPS tag, but his last position was right at the middle of what became a zone of GPS failures. Perhaps we might have to use the same methods we've been using for hundreds of years to find him instead of looking at the GPS readout."
Re: 1984 -- if things were that bad a GPS jammer to fool with your tracking device is laughably token resistance. Re: things are already that bad, no, they're not.
A computer having its available data indiscriminately wiped is a comparable disaster to a catastrophic car failure in the amount of disruption it can cause. You are consummately guilty of not thinking about the implications of what you advocate, and in the classic manner are attempting to shout down anyone who might expose flaws in your reasoning.
Now, you've extended the analogy farther than it was originally grown, and in doing so invalidated it. Computers are not cars. Routine maintenance on a computer will not keep it in working order in the same manner as a car. An engine's enemy is entropy. Your computer's enemy is far more insidious, if a bit less relentless.
There is no 'routine maintenance' that can be performed on computers to safeguard them. There is no simple five-step program that any person can follow. The closest you can get is mass-market virus scanners and the like, and while those might stop 90% of the problem -- at considerable cost to the host environment -- the 10% remaining is the worst 10%. There isn't a period of warning with computers like there is with cars -- indeed, it's much the opposite. Once you've noticed a problem it's far too late. Preventive security on complex systems is hard.
Your talk of responsibility is immature nonsense. No one is resisting responsibility. But your stance to 'solve' this problem is to say, well, just make everyone responsible for everything -- we'll take every person in America and make them get a four-year degree in system security, and then if anything goes wrong we'll have someone to blame it on! If anyone doesn't bother putting themselves through the highest level of education specifically on the topic of securing their systems, then they should obviously lose their data! It's a complete denial of reality.
So, tell me, is this how you feel about your banking institution? You really don't care if they are breached if they 'learn their lesson'? Your health care provider? Your employer? Your daughter? Do you really believe that data is only valuable to the person that possesses it?
We're all living in the Real World, and your views will someday -- when you're older, no doubt -- incorporate that. For now, you've built up some oversimplified model of society, and its application is not only undesirable, it is completely unfeasible.
Yeah, I mean, I think they should make cars that blow up if you don't check the oil, belts, timing belts, brakes, transmission, coolant, tires, hoses, spark plugs, wires, distributor caps/rotors, and air filters precisely at the best mileage for each! That way, people who refuse to help themselves by daring to drive a car without knowing the full maintenance schedule (and implications of missing parts of it) will be taken out of the education. Those stupid, incompetent, lazy people.
A fire.
I never suggested that synchronization is free. However, a CAS or other (x86-supported!) atomic instruction would suffice, so you are talking about one extra cycle and a cache read (in the worst case) for the benefit of working (at least) twice as fast; you will benefit from extra cores almost linearly until you've got the entire thing in cache.
The cache stuff is pretty straightforward. More CPUs = more cache = more cache hits. Making the assumption that a[], b[], and c[] are contiguous in memory only increases this effect -- in your scenario, there is only one cache, and you'll have at most * 3 of the values local; whereas for every cpu you add in distribution the value increases linearly for quite some time.
This is ignoring the trivially shallow dependance of the originally proposed computation (there's a simple loop invariant) and making the assumption that a difficult computation is being done.
You might be tempted to pre-compute B[i]+c[i] in one thread and add in a[i-1] in another, but you then have 2 problems. First, if you aren't doing a barrier sync in the loop the second thread might pass the first and the result is junk, but if you are, you're burning more time in the sync than you saved. Next, the time spent in the second thread loading the intermediate value cold from either RAM or L1 cache into a register will exceed the time it would take to perform the addition.
Given some time, I can easily come up with far more perverse cases that come up in the real world.
...of course there's going to be some kind of synchronization. The suggestion otherwise implies a lack of experience in the field; failure to plan sync before anything else is an undergrad mistake.
I fail to see how the sync burns more time than you save by threading the computation. It seems to me that doing operation a and operation b in sequence will almost always be slower than doing them simultaneously with one joining the other at the end (or, better and a little trickier, a max-reference count for the dependent thread).
Re: cache, you are making strong assumptions that you're going to get cache hits for equidistant indecies across three arrays. In the kind of real-world computations that need this kind of hardware, you're not going to look at three flat 100 element arrays. You're going to be looking at 10k x 10k x 10k arrays, and the number of cache hits you get is not going to decrease by parallelizing the work -- indeed, since you're getting more cache for every node, the cache hits are going to increase with any degree of optimization. This is true in all cases.
There is nothing 'perverse' about the case you have presented. It's a trivial optimization problem that doesn't require more than a basic knowledge of cache and some hint of the target architecture. The more perverse cases are the ones that get worked on at the highest level, and I have seen no proof of any computational problem that is sequential in the fastest case.
You do realize that if you go off-node on your cluster even over infiniband the 1uS is about equal to a late 1960's core memory access time right?
Sure, but having 1960 mag core access to entirely different systems is pretty good, I'd say. And it will only improve.
It's a false dichotomy. There are some problems that clusters are bad at. That is true. The balancing factor that you are missing is that there are problems that single-proc machines are bad at, also. For every highly sequential problem we know, we also know of a very highly parallel one. There are questions that cannot be efficiently answered in a many-node environment, but there are also questions that can be answered far faster. What you're saying is basically that a desktop computer running modern games doesn't need a GPU, it just needs a faster CPU. It's failing to optimize for the problem; driving the screw with a hammer, if you will.
There is no such thing as effective "brute force parallelize". Effective concurrent computation requires thought. Sequential programming is MUCH easier to design and optimize for; that's the draw of single-proc systems. There is nothing inherently non-partitionable about "a[i] = b[j] * c[k] + d[l]"; indeed, I would submit that there are very easy threading optimizations that can be done for any combinations of i,j,k,l; a single thread of execution is GUARANTEED to be slower than even the most trivially optimized multithreaded case. Any multithreaded case benefits from additional execution units up to the number of threads as long as the computation bandwidth (NOT the interprocess bandwidth!) increases enough to account for the increase in computation latency (which is linked to, but not identical to, interprocess latency).
Sequential is dying, because it's suboptimal. Trying to burn the gas faster and faster doesn't get around the fact that the engine just isn't that efficient.
Well, yeah, if you deliberately design a program to not take advantage of the architecture it's running on, then it won't take advantage of the architecture it's running on. (This, btw, is one of the great things about Linux, but that's not really what we're talking about.)
One mistake you're making is in assuming only one kind of general computing improvement can be occurring at a time (and there is some good, quality irony in that *grin*). Cray (and others) can continue to experiment on the edge of the thermal/lightspeed barrier, while others can simultaneously increase computing resources by running clusters.
There's nothing inherently detrimental about clusters, and almost all tasks can be parallelized to some degree. There are, of course, always latency and bandwidth issues in distributed memory systems, but InfiniBand (which is what serious clusters use) has latency in the 1 microsecond range, which is only about five times memory latency itself, and a bandwidth that you'll never saturate with current data distribution models (we're working on that).
It's true that typically performance to processor growth is sublinear, but it's also nonzero. For even moderately parallel tasks, a $300k cluster can outperform a $3M supermachine, and the failure of that to extend to the very boundary is more an effect of our inability to grok the parallel coding model (parallel code is hard); as we understand more and more about concurrent programming you will see the oft-cursed 'penalty' of cluster computing dwindle more and more towards nothing.
PC manufacturers have no obligation to set up a special process to attend to the desires of the vanishingly small % of the population that wants a bare metal PC.
Ah, yes, I would like to refer you to the article being discussed. You see, quite honestly, yes, they do.
You should not confuse your opinion of what is important with some kind of objective measure of what is important.