Well, to be fair, CPU load could indicate memory bandwidth problems, not necessarily CPU speed problems. However, I still think you have a point about caching, and it's one I even raised myself.
(What I find astonishing is the anger that my claim seems to have generated. I even had someone cursing at me and accusing me of never having done any non-trivial development work. I had no idea the claim would be so controvercial that someone would believe I must be either a novice or a liar to make it.)
Fine. But none of this makes my statement
"wrong" as you claimed. You were the one who introduced the straw-man^H^H^H^Hcounter-example of incremental builds.
Fine, I wish I had never maid the claim. However, I think there are a few things still to consider:
1. I said 30 minutes, not the original poster. He was only talking about running Word, and wasn't talking about development at all.
2. It seems to me that 50-line homework assignments are that much less likely to have a CPU-bound build process. How much time could the CPU really spend gnawing on 50 lines of code?
3. On my dual Celeron, the Linux kernel builds in half the time if I use the "-j2" build flag. That's hard to explain if the build is IO-bound or memory bound, since an SMP wouldn't alleviate either of these. (Well, having twice the cache might help the memory issue I suppose, but caching improvements tend not to be linear like that.)
4. I have a 23,000-line project that gets compiled as a single compilation unit, so gcc's optimizer can go to town on it. That bangs the CPU pretty hard, and I have observed that it compiles twice as quickly on machines with twice the MHz rating. (Of course, that doesn't actually guarantee anything.)
5. Modern optimizers use dataflow engines that iterate over the same CFG many times. For most functions, I'd expect the CFG to fit in the CPU's cache, and thus memory and IO are a non-issue.
Thus, I don't think the claim that builds are CPU-bound is absurd. Rather, I think it's absurd to claim that builds are never CPU-bound, though I agree that they often are not.
Interesting post. I'm not sure why you claim that I'm wrong when you provide a number of examples of CPU-bound build enviromnents.
In fact, your post states fairly clearly that only incremental builds are disk-bound, and even then it's only the link stage. (Or do your files really take more than 2 seconds to load from disk?)
Clearly I should have said "some of my build processes are CPU-bound". Or, I should have picked a different example.:-)
To answer your question, I have been a professional software developer for a number of years. However, that's not relevant to the issue of whether compiles are CPU-bound, so let's get back to the point.
I agree that some builds may not be CPU bound. Computers with faster processors also tend to come with faster memory and faster disks, so that may give the appearance that a machine with 2xCPU gives twice the performance, while in fact it's not due to the CPU at all.
Regardless, the optimizers in modern compilers produce CFG data structures that they walk repeatedly to do optimizations. For most functions, the CFG ought to fit in the cache (L2 at least) and so there's not that much memory traffic. Furthermore, during this process, there's little disk IO.
However, if your project involves compiling a lot of little files, or doesn't use a high level of optimization, or does a lot of processing besides actual compiling, then you might indeed see a lot of IO or memory traffic.
And anyway, the real point is that there are CPU-bound jobs out there, even if builds are not among them.
Insightful?? I think this is a troll, but I'll bite anyway...
Just because you only run Word, and don't run any CPU-bound jobs as part of your daily work, doesn't mean they don't exist. For development work, for example, builds are often CPU-bound, so a 2.4GHz machine will compile six times as quickly as your 400MHz machine. That's a big deal when a build takes 5 minutes instead of 30.
They would have to hurl that vase at at least 19 kilometers per second for it to leave the solar system, and even at that rate, it would not go nearly as quickly as the Voyager probes. 19km/s would be just enough for it to just barely crawl away from the solar system at a velocity asymptotically approaching zero.
Besides, your analogy falls flat. I presume your point was that the age of the technology is irrelevant when it comes to leaving the solar system? Then consider this: what is it that pushed the 1970s technology of the Voyagers out of the solar system? Answer: more 1970s technology. If your 16th century vase were propelled by 16th century rockets, then your analogy would be valid.
The data was recorded in a little black box that parachuted back to earth, somewhere within an n-kilometer radius for some moderately large value of n, and so it took some time to find it.
Put simply: You're doing something in a game of cards that gives you an unfair advantage so that you can win more money. That sounds like the definition of cheating to me...
You used the word "unfair" in there, with no justification, and the rest of your argument depends on it. How is counting cards unfair?
It's pretty condescending to think Indians don't know how to build toilets. The lack of sanitation is not a scientific issue, but an economic/social one. As such, it has little to do with the planned moon launch.
And, as someone else pointed out, the budget for this moon shot amounts to something like a dollar per poor person in the country. That's not going to buy them better sanitation, so the point is moot.
Slashdot Mirror
(What I find astonishing is the anger that my claim seems to have generated. I even had someone cursing at me and accusing me of never having done any non-trivial development work. I had no idea the claim would be so controvercial that someone would believe I must be either a novice or a liar to make it.)
Fine. But none of this makes my statement "wrong" as you claimed. You were the one who introduced the straw-man^H^H^H^Hcounter-example of incremental builds.
1. I said 30 minutes, not the original poster. He was only talking about running Word, and wasn't talking about development at all.
2. It seems to me that 50-line homework assignments are that much less likely to have a CPU-bound build process. How much time could the CPU really spend gnawing on 50 lines of code?
3. On my dual Celeron, the Linux kernel builds in half the time if I use the "-j2" build flag. That's hard to explain if the build is IO-bound or memory bound, since an SMP wouldn't alleviate either of these. (Well, having twice the cache might help the memory issue I suppose, but caching improvements tend not to be linear like that.)
4. I have a 23,000-line project that gets compiled as a single compilation unit, so gcc's optimizer can go to town on it. That bangs the CPU pretty hard, and I have observed that it compiles twice as quickly on machines with twice the MHz rating. (Of course, that doesn't actually guarantee anything.)
5. Modern optimizers use dataflow engines that iterate over the same CFG many times. For most functions, I'd expect the CFG to fit in the CPU's cache, and thus memory and IO are a non-issue.
Thus, I don't think the claim that builds are CPU-bound is absurd. Rather, I think it's absurd to claim that builds are never CPU-bound, though I agree that they often are not.
In fact, your post states fairly clearly that only incremental builds are disk-bound, and even then it's only the link stage. (Or do your files really take more than 2 seconds to load from disk?)
Clearly I should have said "some of my build processes are CPU-bound". Or, I should have picked a different example. :-)
To answer your question, I have been a professional software developer for a number of years. However, that's not relevant to the issue of whether compiles are CPU-bound, so let's get back to the point.
I agree that some builds may not be CPU bound. Computers with faster processors also tend to come with faster memory and faster disks, so that may give the appearance that a machine with 2xCPU gives twice the performance, while in fact it's not due to the CPU at all.
Regardless, the optimizers in modern compilers produce CFG data structures that they walk repeatedly to do optimizations. For most functions, the CFG ought to fit in the cache (L2 at least) and so there's not that much memory traffic. Furthermore, during this process, there's little disk IO.
However, if your project involves compiling a lot of little files, or doesn't use a high level of optimization, or does a lot of processing besides actual compiling, then you might indeed see a lot of IO or memory traffic.
And anyway, the real point is that there are CPU-bound jobs out there, even if builds are not among them.
Just because you only run Word, and don't run any CPU-bound jobs as part of your daily work, doesn't mean they don't exist. For development work, for example, builds are often CPU-bound, so a 2.4GHz machine will compile six times as quickly as your 400MHz machine. That's a big deal when a build takes 5 minutes instead of 30.
Sure they do. AU are used by astronomers all the time. Why not?
As far as I can tell, they're on their way back out again. I think we're on schedule for the Miami Vice/Flock of Seaguls look again.
Did this story really ever say "light-years"? Because when I read it, it said "light-hours".
Besides, your analogy falls flat. I presume your point was that the age of the technology is irrelevant when it comes to leaving the solar system? Then consider this: what is it that pushed the 1970s technology of the Voyagers out of the solar system? Answer: more 1970s technology. If your 16th century vase were propelled by 16th century rockets, then your analogy would be valid.
"I call the big one 'Bitey'." -Homer
I think you mean censor, not censure.
API is not Application-Programmer Interface: it's Application Programming (or Program) Interface; that is, the interface you use when you're programming an application.
LOL. Been there.
The data was recorded in a little black box that parachuted back to earth, somewhere within an n-kilometer radius for some moderately large value of n, and so it took some time to find it.
Yeah! And while they're at it, why don't all those programmers just not put all those bugs in the software in the first place?
Well, that's insightful, considering Taco said it all already.
Yup. This has to be the dumbest question I have ever seen on this site. "Why does ID charge $250,000 when they could charge $100?"
Good point. I hadn't thought of that.
And, as someone else pointed out, the budget for this moon shot amounts to something like a dollar per poor person in the country. That's not going to buy them better sanitation, so the point is moot.