I agree, having watched a whole two episodes of Braniac, it's an almost complete disappointment.
The most disappointing part, though, is that the show would be very, very easy to fix. The problem isn't the things they do on the show. The majority of it is good, if a bit silly, science. I don't even have a problem with the fact that it's edited for 12-year olds with ADD.
The problem is the tone of the show, and in particular, the crass commentary.
There was one episode I saw, for example, which featured a segment asking how much weight you actually gain by eating a quarter-pound burger. It turns out to be measurably LESS than a quarter of a pound because of the energy required to actually do the eating. While not in the same league as Mythbusters, this is a very good piece of television science. However, the announcer then had to speak in British-euphemistic terms about the subsequent trip to the toilet, which was completely unnecessary.
I'm not squeamish about this sort of thing at all, but the impression that you get is that the show is not an offbeat science programme at all, but rather dumbed-down science for people who enjoy laughing when someone refers to a fart as a "bottom biscuit".
That's why the Second Amendment gives me an unabridged right to bear arms!
Let me paint you a picture.
The year is 1943. The US government is rounding up Japanese-American citizens, taking them to internment camps. This is a fairly obvious infringement of just about every civil right that we hold dear.
But look! One small group of Japanese-American citizens has armed themselves! The millitary comes to get them. They stand their ground, preparing to defend themselves with whatever modern weaponry they have.
And the process of making actual movies doesn't cost $100,000,000 but the process of fighting for the screen time does.
That's not the whole story.
One of the problems is a variant of Blinn's Law. Audience expectation rises over time, and studios feel they need to "up the ante" with every film season. Hence, you find a lot of expensive visual effects which don't add to the story of the film. Even if it's a good story, people WILL say "oh, it didn't look as realistic as that other film".
Another problem is the cost of stars. As Billy West pointed out, Cameron Diaz didn't get paid $19 million for Shrek 2 because she has a nine-foot-wide mouth. And it's not just their paypackets. An old phrase in Hollywood budgeting is "add one third for the shit". "The shit" in this case refers to misbehaviour by the talent. One "star" with a bug up their arse might hold up production, and everyone working in it, for multiple days. Admittedly, this doesn't happen as much as it used to.
In fact, there's less fighting for "screen time" than you might think. There's a real sense, in fact, in which movies don't really compete with each other. People don't sit down at the start of a season and say, "Well, I am seeing exactly three movies this Summer. Now let's see which three they will be..." Instead, people set a bar, and any movie over that bar will be seen and any under that bar will not be seen. Fighting for brainshare is much more important.
Just so everyone knows, because some people aren't paying attention: The AC isn't trolling. They're being satirical. This is the story that they are alluding to.
High school science classrooms are not a forum of scientific debate.
That's true, but I would have loved it if my high school science classroom had some material on what constitutes scientific debate, how it happens, and also a counter-example. Picking one example (Intelligent Design, Astrology, whatever) and showing why it's not Science sounds like a damn good idea to me. ID seems especially appropriate, since it's topical. In fact, if I was a Kansas biology teacher, I might do precisely that: read the statement from the Kansas school board, and then proceed to demonstrate why it isn't science.
Many programmers do make an attempt to allocate as much on the stack as possible, but I think most don't really consider it.
Multi-threaded programmers do. Allocating an unbounded (at compile time) amount of data on the stack is considered very bad practice when the size of your stack is limited.
Garbage collection is a continuum between raw C with free and malloc at one end and completely automatic concurrent real-time cycle-friendly scavenging at the other. Just because it's reference counting doesn't mean it's not garbage collection, especially if it's done behind the scenes.
Actually, there is one aspect of modern C++ with smart pointers that I like. There is a huge semantic difference between this:
void f1(Foo* p_f);
and this:
void f2(boost::shared_ptr<Foo>& p_f);
In this code, f1 is explicitly advertising in its type signature that it does not intend to manage the lifetime of the object passed in, where f2 is explicitly advertising that it may. This is valuable documentation, which you don't get for free in a language with automatic GC. (Though, to be fair, in a pure language, such as a functional or logic language, it makes no difference because data objects are not mutable.)
On the contrary, the C++ model is basically correct for some applications.
A "proper program" is programmed in the appropriate language for the job. Sometimes this is a domain-specific language. Sometimes you need the close-to-the-metal-yet-still-maintainable-for-larg e-applications qualities that C++ provides. And sometimes you don't.
Very few people write web applications in C++, and for good reason. Web servers run at the speed of the network card, not the speed of the L1 cache. Pulling out extra cycles is pointless especially if you lose the maintainability that a general purpose language like C++ provides. And yet you wouldn't call many of these "quick scripting hacks".
The answer, as always, is "it depends". I'm firmly inside the "right tool for the job" camp.
Manual memory management is not free. In some circumstances, it can be quite expensive. There is a group of programmers who are best described as "rabidly anti-GC". These people are almost all completely unaware of the costs that manual memory management can impose on your code.
A multi-threaded program, for example, can allocate memory from any arena, but it MUST return a block to the arena from whence it came, which can cause all sorts of difficult lock contention problems, making free() much more expensive than malloc(). (Ask anyone who has written high-performance memory-intensive multi-threaded programs.)
In some languages, like C, the situation is even worse. In structure-hungry programs, you can end up structuring your code around data lifetimes, which precludes you from using the most natural, maintainable and efficient algorithms. Garbage collection frees you from this, as the GCC people have discovered.
I do recommend reading Paul Wilson's excellent survey paper on the topic. It answers a lot of your questions, though it's by no means the final word.
Also just for jollies, I tried a quick experiment. You can see two versions of the sort test. One is your version. The other is mine, which uses iterators (which get compiled to pointers, the same as your asm version). Not only is my version shorter, it's also more reusable, since it will work with any STL-compliant container with random access iterators.
I compiled this with GCC 4.0.2 i486-linux-gnu with -O3. Results on my machine are: Your version, 10.45 sec. My version, 8.56 sec. And that's without trying. It looks like using pointers/iterators actually does make quite a bit of difference.
(I didn't test your asm version because it would require translating to AT&T assembly format and, besides, as previously noted, it's broken in several ways.)
The generated assembler, by the way, is very instructive. It does a whole bunch of optimisations which you don't do. Here, for example, is the top of the loop:
Note how it inserted nops so that the start of the loop was aligned to the start of a cache line (multiple of 16 bytes on a Pentium or compatible). This increases the efficiency of the instruction fetch and issue. Imagine if it were at the END of a cache line, for example. Then the following instruction, being in a different cache line, could probably not be fetched, decoded and issued in the same cycle.
Did you think about this issue when you were writing your assembly version? No, I didn't think so. Neither did I, but the compiler did. Amdahl's Law strikes again: Optimising register usage doesn't always help if there's an inefficiency elsewhere.
Bottom line, my register usage makes all the difference.
Your code is also highly, highly immoral in two important ways, but they're both related to the fact that you violate the ABI by saving the stack pointer to a static location, then using %esp as a general purpose register.
First off, it's not reentrant because the stack pointer is saved in a static location. Calling your sort function from two threads simultaneously will cause your program to misbehave.
Secondly, because you don't maintain the C stack, it's not signal-safe. Try setting a signal handler then sending it a signal while it's in the middle of your sort function to see what I mean.
If the C++ compiler were allowed to violate the ABI, then I'll wager that it could get pretty close to your code. But it's not, and for very good reasons.
When I was a postgrad student, we researched programming languages and their implementations. Specifically, we were trying to write an efficient compiler which generated very good code for a high-level language.
For something as sophisticated as a modern compiler, any results which we obtained are meaningless without providing all the source code. Evaluating an optimisation mechanism, for example, is pointless in isolation. What matters is the speed of the final code and that depends on all of the OTHER optimisations, code generation, register allocation and so on.
The same problem is applicable to just about anything. Science depends on reproducibility. Without access to the source code, an experiment is not reproducible, and therefore not science.
Such a comparison is meaningless without seeing the source code. As my supervisor used to say, "if there's no source code, it's not science".
C++ provides sort code as part of its standard library. If you don't mind being slow and hard to use, there's qsort(). If you are sane and don't care about C compatibility, there's std::sort(). In fact, I'd like to see your sort go head to head against std::sort. I'm willing to bet that it's both faster (because using better algorithms almost always beats programming at a lower-level), and it's more maintainable.
I dunno man, I think we are a poorer society without our philosophers.
I agree, but it's the philosophy faculties' fault. If they actually did philosophy rather than write commentaries on the works of dead philosophers, we might get somewhere. It's unfortunate that the best philosophy seems to be coming from popular science writers thee days, because they don't have the training to do it property.
Didn't you read the thread? Had Linus been Andy Tanenbaum's student, he would have failed.
Graduate schools are, quite reasonably, only going to produce software that is interesting from a research point of view. Linux is interesting today, but only because of eight or so years of uninteresting work (from a CS research point of view) before it.
Disney has been in a creative slump for a number of years. They did not catch on to the technological changes very quickly, and their stories have been lacking, feeling like new cookie-cutter versions of tropes that ceased to be fresh a long time ago.
I disagree with you about the technological changes. Disney has always been there when new technology has been available. In fact, there's only one piece of technology that they really missed, and that was the transition from cinema shorts to animated television series. They soon made up for lost time, though.
(BTW, if you made the mistake in thinking that Disney's problems are because people want to see 3D CG animation rather than 2D cel animation, you may want to consider getting a job as a Hollywood executive, because with that mentality, you'd fit right in. Every creative person in the business know full well that people couldn't care less about the tech so long as they're watching a good story well told. Remember that Final Fantasy and South Park came out in the same year. Final Fantasy had far, far superior technology. South Park had a far, far better script. Guess which one made more money?)
Disney's problems are entirely creative, in the sense that the creative people that they have aren't allowed to be creative.
Disney has had two large creative slumps in their history. The first was after Walt died. After all of the projects that Walt was involved in were finished, the company entered a slump exemplified by such films as That Darn Cat and Herbie Goes Bananas. The second slump can be identified as starting when Frank Wells died and left Michael Eisner in charge, which was followed shortly after by a mass defection of talent to DreamWorks and the effective firing of Roy Disney.
Interestingly, the second slump is exemplified by remakes of Herbie etc.
Slashdot Mirror
And courtesy of the Matrixesque Conspiracy Department, this thought: You might be doing that already, and be unaware of it!
I agree, having watched a whole two episodes of Braniac, it's an almost complete disappointment.
The most disappointing part, though, is that the show would be very, very easy to fix. The problem isn't the things they do on the show. The majority of it is good, if a bit silly, science. I don't even have a problem with the fact that it's edited for 12-year olds with ADD.
The problem is the tone of the show, and in particular, the crass commentary.
There was one episode I saw, for example, which featured a segment asking how much weight you actually gain by eating a quarter-pound burger. It turns out to be measurably LESS than a quarter of a pound because of the energy required to actually do the eating. While not in the same league as Mythbusters, this is a very good piece of television science. However, the announcer then had to speak in British-euphemistic terms about the subsequent trip to the toilet, which was completely unnecessary.
I'm not squeamish about this sort of thing at all, but the impression that you get is that the show is not an offbeat science programme at all, but rather dumbed-down science for people who enjoy laughing when someone refers to a fart as a "bottom biscuit".
More like:
Kudos on getting a goatse link honestly modded informative, by the way.
Let me paint you a picture.
The year is 1943. The US government is rounding up Japanese-American citizens, taking them to internment camps. This is a fairly obvious infringement of just about every civil right that we hold dear.
But look! One small group of Japanese-American citizens has armed themselves! The millitary comes to get them. They stand their ground, preparing to defend themselves with whatever modern weaponry they have.
What happens next?
So your real problem with it might be that the movie was live action?
That's not the whole story.
One of the problems is a variant of Blinn's Law. Audience expectation rises over time, and studios feel they need to "up the ante" with every film season. Hence, you find a lot of expensive visual effects which don't add to the story of the film. Even if it's a good story, people WILL say "oh, it didn't look as realistic as that other film".
Another problem is the cost of stars. As Billy West pointed out, Cameron Diaz didn't get paid $19 million for Shrek 2 because she has a nine-foot-wide mouth. And it's not just their paypackets. An old phrase in Hollywood budgeting is "add one third for the shit". "The shit" in this case refers to misbehaviour by the talent. One "star" with a bug up their arse might hold up production, and everyone working in it, for multiple days. Admittedly, this doesn't happen as much as it used to.
In fact, there's less fighting for "screen time" than you might think. There's a real sense, in fact, in which movies don't really compete with each other. People don't sit down at the start of a season and say, "Well, I am seeing exactly three movies this Summer. Now let's see which three they will be..." Instead, people set a bar, and any movie over that bar will be seen and any under that bar will not be seen. Fighting for brainshare is much more important.
Just so long as you don't look at pictures of that, you're fine.
Just so everyone knows, because some people aren't paying attention: The AC isn't trolling. They're being satirical. This is the story that they are alluding to.
That's true, but I would have loved it if my high school science classroom had some material on what constitutes scientific debate, how it happens, and also a counter-example. Picking one example (Intelligent Design, Astrology, whatever) and showing why it's not Science sounds like a damn good idea to me. ID seems especially appropriate, since it's topical. In fact, if I was a Kansas biology teacher, I might do precisely that: read the statement from the Kansas school board, and then proceed to demonstrate why it isn't science.
Then I forgive you, because GC was slow in the 80s.
Multi-threaded programmers do. Allocating an unbounded (at compile time) amount of data on the stack is considered very bad practice when the size of your stack is limited.
Garbage collection is a continuum between raw C with free and malloc at one end and completely automatic concurrent real-time cycle-friendly scavenging at the other. Just because it's reference counting doesn't mean it's not garbage collection, especially if it's done behind the scenes.
Actually, there is one aspect of modern C++ with smart pointers that I like. There is a huge semantic difference between this:
and this:
In this code, f1 is explicitly advertising in its type signature that it does not intend to manage the lifetime of the object passed in, where f2 is explicitly advertising that it may. This is valuable documentation, which you don't get for free in a language with automatic GC. (Though, to be fair, in a pure language, such as a functional or logic language, it makes no difference because data objects are not mutable.)
On the contrary, the C++ model is basically correct for some applications.
A "proper program" is programmed in the appropriate language for the job. Sometimes this is a domain-specific language. Sometimes you need the close-to-the-metal-yet-still-maintainable-for-larg e-applications qualities that C++ provides. And sometimes you don't.
Very few people write web applications in C++, and for good reason. Web servers run at the speed of the network card, not the speed of the L1 cache. Pulling out extra cycles is pointless especially if you lose the maintainability that a general purpose language like C++ provides. And yet you wouldn't call many of these "quick scripting hacks".
The answer, as always, is "it depends". I'm firmly inside the "right tool for the job" camp.
Manual memory management is not free. In some circumstances, it can be quite expensive. There is a group of programmers who are best described as "rabidly anti-GC". These people are almost all completely unaware of the costs that manual memory management can impose on your code.
A multi-threaded program, for example, can allocate memory from any arena, but it MUST return a block to the arena from whence it came, which can cause all sorts of difficult lock contention problems, making free() much more expensive than malloc(). (Ask anyone who has written high-performance memory-intensive multi-threaded programs.)
In some languages, like C, the situation is even worse. In structure-hungry programs, you can end up structuring your code around data lifetimes, which precludes you from using the most natural, maintainable and efficient algorithms. Garbage collection frees you from this, as the GCC people have discovered.
I do recommend reading Paul Wilson's excellent survey paper on the topic. It answers a lot of your questions, though it's by no means the final word.
Also just for jollies, I tried a quick experiment. You can see two versions of the sort test. One is your version. The other is mine, which uses iterators (which get compiled to pointers, the same as your asm version). Not only is my version shorter, it's also more reusable, since it will work with any STL-compliant container with random access iterators.
I compiled this with GCC 4.0.2 i486-linux-gnu with -O3. Results on my machine are: Your version, 10.45 sec. My version, 8.56 sec. And that's without trying. It looks like using pointers/iterators actually does make quite a bit of difference.
(I didn't test your asm version because it would require translating to AT&T assembly format and, besides, as previously noted, it's broken in several ways.)
The generated assembler, by the way, is very instructive. It does a whole bunch of optimisations which you don't do. Here, for example, is the top of the loop:
8049575: cmp %eax,%edx8049577: je loop_break
8049579: mov %eax,%edi
804957b: nop
804957c: lea 0(%esi),%esi
8049580: mov (%edi),%edx ; Loop starts here
8049582: mov %edx,0xfffffff0(%ebp)
Note how it inserted nops so that the start of the loop was aligned to the start of a cache line (multiple of 16 bytes on a Pentium or compatible). This increases the efficiency of the instruction fetch and issue. Imagine if it were at the END of a cache line, for example. Then the following instruction, being in a different cache line, could probably not be fetched, decoded and issued in the same cycle.
Did you think about this issue when you were writing your assembly version? No, I didn't think so. Neither did I, but the compiler did. Amdahl's Law strikes again: Optimising register usage doesn't always help if there's an inefficiency elsewhere.
Your code is also highly, highly immoral in two important ways, but they're both related to the fact that you violate the ABI by saving the stack pointer to a static location, then using %esp as a general purpose register.
First off, it's not reentrant because the stack pointer is saved in a static location. Calling your sort function from two threads simultaneously will cause your program to misbehave.
Secondly, because you don't maintain the C stack, it's not signal-safe. Try setting a signal handler then sending it a signal while it's in the middle of your sort function to see what I mean.
If the C++ compiler were allowed to violate the ABI, then I'll wager that it could get pretty close to your code. But it's not, and for very good reasons.
Bottom line, your code is incorrect.
When I was a postgrad student, we researched programming languages and their implementations. Specifically, we were trying to write an efficient compiler which generated very good code for a high-level language.
For something as sophisticated as a modern compiler, any results which we obtained are meaningless without providing all the source code. Evaluating an optimisation mechanism, for example, is pointless in isolation. What matters is the speed of the final code and that depends on all of the OTHER optimisations, code generation, register allocation and so on.
The same problem is applicable to just about anything. Science depends on reproducibility. Without access to the source code, an experiment is not reproducible, and therefore not science.
Such a comparison is meaningless without seeing the source code. As my supervisor used to say, "if there's no source code, it's not science".
C++ provides sort code as part of its standard library. If you don't mind being slow and hard to use, there's qsort(). If you are sane and don't care about C compatibility, there's std::sort(). In fact, I'd like to see your sort go head to head against std::sort. I'm willing to bet that it's both faster (because using better algorithms almost always beats programming at a lower-level), and it's more maintainable.
I agree, but it's the philosophy faculties' fault. If they actually did philosophy rather than write commentaries on the works of dead philosophers, we might get somewhere. It's unfortunate that the best philosophy seems to be coming from popular science writers thee days, because they don't have the training to do it property.
For the umpteenth time: embedded != small
Sure, a digital camera is an embedded device, but so is an MRI scanner.
Someone who receieved the pirated software could also report them to the BSA.
Didn't you read the thread? Had Linus been Andy Tanenbaum's student, he would have failed.
Graduate schools are, quite reasonably, only going to produce software that is interesting from a research point of view. Linux is interesting today, but only because of eight or so years of uninteresting work (from a CS research point of view) before it.
No taxation without representation.
I disagree with you about the technological changes. Disney has always been there when new technology has been available. In fact, there's only one piece of technology that they really missed, and that was the transition from cinema shorts to animated television series. They soon made up for lost time, though.
(BTW, if you made the mistake in thinking that Disney's problems are because people want to see 3D CG animation rather than 2D cel animation, you may want to consider getting a job as a Hollywood executive, because with that mentality, you'd fit right in. Every creative person in the business know full well that people couldn't care less about the tech so long as they're watching a good story well told. Remember that Final Fantasy and South Park came out in the same year. Final Fantasy had far, far superior technology. South Park had a far, far better script. Guess which one made more money?)
Disney's problems are entirely creative, in the sense that the creative people that they have aren't allowed to be creative.
Disney has had two large creative slumps in their history. The first was after Walt died. After all of the projects that Walt was involved in were finished, the company entered a slump exemplified by such films as That Darn Cat and Herbie Goes Bananas. The second slump can be identified as starting when Frank Wells died and left Michael Eisner in charge, which was followed shortly after by a mass defection of talent to DreamWorks and the effective firing of Roy Disney.
Interestingly, the second slump is exemplified by remakes of Herbie etc.