Man, I just want to know what kind of compiler you guys are using, and what you are doing to it!
Which compiler is irrelevant, since compilers in general are incredibly complex and therefore at least somewhat buggy. But what am I doing to it? On the order of a million and a half test cases, that's what (some of them take a second or less to compile, others take hours because they're so huge and optimization takes a long time). You find a few bugs that way.
So are you saying that when a compiler you write generates bad code or gets an internal error, it's not your fault?;-)
Of course not. Not my fault. Never my fault. I work as part of a team, which means there are always plenty of other people to take the blame. They're kind of like Tibor at the Springfield Nuclear Plant.
As a compiler writer, I found this sentence to be particularly hilarious:
Because the compiler, unlike the programmer, never makes mistakes, the resulting code is also more likely to be free of bugs.
That's right, none of us has ever seen bad code generation or an internal compiler error. But, he does have a point. The compiler is less likely to make a mistake than a programmer.
Now, I'm not denying that what this guy is done is pretty good. But if you can't even get to/sbin/init, then has your system really booted up? Certainly not in any useful way. I think this story is a bit premature. Post another one when programs can actually run on FreeBSD on a Clawhammer. Only then will I really be impressed.
Sure, if you're compiling with no optimization, templates sure can create bloat. Another poster has pointed out that if you write intelligently, template stuff can be faster than code using inheritance and polymorphism.
What I haven't seen pointed out yet is that a smart interprocedural optimizer can factor out a lot of the bloat. Some functions will be identical regardless of template parameters. The duplicates can be eliminated and the code that calls these functions can be changed to just call the remaining function.
Other functions will be the same in large portions of the code (when you get down to an intermediate language level). These portions can be outlined (the opposite of inlining) and then the resulting duplicate functions can be eliminated, taking out more bloat.
And please, no one say that this can't realistically be done, because I know of one implementation that can actually do this.
Actually, I've seen plenty of race condition bugs that only manifest themselves on a multiprocessor machine running a particular version of an operating system. For example, AIX 4.3 and 5.1 use different scheduling algorithms, and many race conditions will only occur on 5.1 or above, because these versions of the operating system use a much more aggressive scheduler, and context switches tend to take less time. So, I am also skeptical about UML as a tool to "emulate" a multiprocessor box. If many bugs won't even manifest on a real multiprocessor box with a certain OS version, then it's highly unlikely that a uniprocessor box running some emulator will catch many bugs.
I have a much better solution to being annoyed by telemarketers. Well over half the calls my wife and I get are from her mother (4 times a day is unfortunately not out of the ordinary for her, as she essentially has no life). Now that this has been going on for a few years, I'm elated when I answer the phone and don't hear her voice. Even when it's a telemarketer. Telemarketers at least have a purpose for their mindless prattle, unlike my mother-in-law. I now consider telemarketers to be my best phone buddies. Problem solved.
Actually, I believe IBM does produce a large amount of the G4s. They were making the copper G4s. They also produced a large quantity of the G3s. So they have the manufacturer correct, sort of.
Yes, IBM manufactured some of the G3s and G4s under contract, but they didn't design them. For the Power series of chips, it's all IBM, from the design to the manufacturing, so the G5 and the Power5 will be largely unrelated (aside from the basic underlying PPC architecture).
I suppose this could mean that the G5 isn't fair away though.
Just because IBM is making the Power5 soon doesn't mean that Motorola is making the G5 soon. They're two different companies with very different design methodologies. If Motorola releases the G5 soon, I'll be surprised. After all, who will their customers for the G5 be? Not Apple, if we believe the rumours.
Eclipse *is* a really nice application, but I don't think IBM's motives in creating it were at all community-minded.
No, the motives weren't entirely community-minded. Remember that Eclipse forms the basis of the latest versions of the Websphere products. It was probably designed with this in mind first, with open source a mere afterthought. They most likely open sourced it for quick bug recognition and fixes from the community, and to give third party vendors an easy way to customize Eclipse for whatever Websphere-compatible products they want to release. Win-win for IBM.
Users will judge a product based on how it performs, and (hopefully) not how it looks.
Unfortunately, that's not how it works for most people. To most people, if a program doesn't "look right", then it doesn't "feel right", so it must not "work right". And when people reach this point, they've decided that the program is a "piece" of "crap", and to hell with the "functionality", they just "know" that it "blows large ass".
My favourite quote from the review...
on
Effective Java
·
· Score: 1
'Minimise the accessibility of classes and embers,'
Of course he made the software ages ago when he knew very little about programming compared to now, and the source was probably lacking every possible optimization that an expert coder would introduce, so YMMV.
As a compiler developer, I have to say that programmer-driven "optimizations" are (the vast majority of the time) very shortsighted and very local. Sure, you can hand-optimize a function to perform much faster with no (or low) optimization, but most of these optimizations inhibit aggressive interprocedural optimizations that the compiler could do (at high optimization levels) that would increase performance for that function and the areas that call it.
For a simple example, just think about function pointers in C. Sure, you might do better at low optimization levels if you assign to a function pointer and call through that pointer many times. But at high optimization levels, if you had used a switch or if/else type of structure to determine each call, the compiler could inline the most likely call (yes, reasonable heuristics do exist for most of these circumstances). If this call was to be made 90% of the time, you would get an incredible increase in speed by not going through the function pointer, as the inlined code could be aggressively optimized. Sure, the least likely cases would probably get plenty slower, but they would be incredibly unlikely.
To make a long story short, hand-optimization isn't all it's cracked up to be. Keep the code free of "tricks" and you'll give the compiler's optimizer more opportunities to shine.
Is it just me, or did anyone else expect something fun and different from the "Exploded View" on the Zalman website?
No pattern experience required
on
Design Patterns
·
· Score: 5, Interesting
Even with little previous exposure to patterns, I was able to understand the presented material easily and begin to see the applications.
Even with no exposure to patterns, I was easily able to understand this book. This book was my first exposure to patterns, and I don't think I could have had a better introduction to the subject. I highly recommend this book to anyone who knows anything about object-oriented design.
I think Herbert and Anderson did an excellent job with the "House" prequels. The characterization was well done and there was...gasp...action! Original Dune is a great series but it really got dry as the series wore on. Herbert and Anderson have added much needed life to the series while remaining true to the original.
Are you kidding? I avoided the prequels like the plague until about a week ago, when I got really bored and saw House Atreides in a book store. Almost immediately, I regretted picking up this sorry piece of crap. There was no subtlety at all in the first hundred pages or so of the book (that was all I could stomach). Too many unrelated plotlines that tie together too many things from the original series. Far too ambitious, with far too heavy a hand. The writers just seemed to feel the need to be clever and instead wound up insulting the readers' intelligence. I have a very hard time believing that this book is any better.
Instructions on how to make a quieter mother-in-law? I'd really like to see that.
Anyone else have a crazy Korean mother-in-law? You know what I mean!
Great idea! I'd like to see it too. But you'd have to make it applicable to more than just Korean mothers-in-law. I'm not absolutely sure where my mother-in-law's ancestors come from, but I think she's Bitchanese.
This is why there is a process for International Standards (for the moment, let's ignore fast-tracking of standards, which isn't being done for XML 1.1). If one company wants something, they can feel free to propose it, but the other members of the committee can vote it down. If this really does cause a significant incompatibility with a previous version, then the committee will realize it and vote it down. So, no one company can push something down the others' throats.
Does anyone who frequents Slashdot know of a tool that will take a language standard as its input, and generate a working, bug-free, efficient compiler?
Think about it. If such a thing were possible, why would compiler writers waste all their time doing it manually?
Actually, I really am a compiler writer, and yes, I do know that such a thing is, of course, impossible. And that was part of the joke in the post you replied to. Asking for the impossible, or nearly impossible. Sort of like request in the story: "Can you give me a link to the nearly impossible? If not, can someone do it for me?" Also, please note the ellipsis at the end of the post. That tends to denote a lack of seriousness in a post that is a series of requests.
On another note, I'm a compiler writer who's having problems writing my compiler. Does anyone who frequents Slashdot know of a tool that will take a language standard as its input, and generate a working, bug-free, efficient compiler? Barring that, is anyone proficient enough in Perl? That's the language I've been using to implement my compiler, and I find that it's great for parsing. And while you're at it, maybe you could...
Were you stealing bandwidth from MIT to do this? Or were you hacking into other people's boxes to get the bandwidth?
He's not going to answer this question. If he does, he's copping to another crime (assuming this wasn't one of the charges he's already been convicted of). I suggest that, even if this question gets moderated up to a 5, the editors don't send it, because the answer will just be "I plead the 5th".
A lot longer than that Grecian Formula lasted in my hair. Woke up the next morning and my pillow was all black. You see, it's all about what you're comparing the law to.
Which compiler is irrelevant, since compilers in general are incredibly complex and therefore at least somewhat buggy. But what am I doing to it? On the order of a million and a half test cases, that's what (some of them take a second or less to compile, others take hours because they're so huge and optimization takes a long time). You find a few bugs that way.
Sometimes I do wish I could do that. Ah, if only there were no such things as standards...
Of course not. Not my fault. Never my fault. I work as part of a team, which means there are always plenty of other people to take the blame. They're kind of like Tibor at the Springfield Nuclear Plant.
Because the compiler, unlike the programmer, never makes mistakes, the resulting code is also more likely to be free of bugs.
That's right, none of us has ever seen bad code generation or an internal compiler error. But, he does have a point. The compiler is less likely to make a mistake than a programmer.
Now, I'm not denying that what this guy is done is pretty good. But if you can't even get to /sbin/init, then has your system really booted up? Certainly not in any useful way. I think this story is a bit premature. Post another one when programs can actually run on FreeBSD on a Clawhammer. Only then will I really be impressed.
What I haven't seen pointed out yet is that a smart interprocedural optimizer can factor out a lot of the bloat. Some functions will be identical regardless of template parameters. The duplicates can be eliminated and the code that calls these functions can be changed to just call the remaining function.
Other functions will be the same in large portions of the code (when you get down to an intermediate language level). These portions can be outlined (the opposite of inlining) and then the resulting duplicate functions can be eliminated, taking out more bloat.
And please, no one say that this can't realistically be done, because I know of one implementation that can actually do this.
Actually, I've seen plenty of race condition bugs that only manifest themselves on a multiprocessor machine running a particular version of an operating system. For example, AIX 4.3 and 5.1 use different scheduling algorithms, and many race conditions will only occur on 5.1 or above, because these versions of the operating system use a much more aggressive scheduler, and context switches tend to take less time. So, I am also skeptical about UML as a tool to "emulate" a multiprocessor box. If many bugs won't even manifest on a real multiprocessor box with a certain OS version, then it's highly unlikely that a uniprocessor box running some emulator will catch many bugs.
Calm down, kid. Don't take everything so goddamned seriously. The vast majority of the people in the world are not out to get you.
I have a much better solution to being annoyed by telemarketers. Well over half the calls my wife and I get are from her mother (4 times a day is unfortunately not out of the ordinary for her, as she essentially has no life). Now that this has been going on for a few years, I'm elated when I answer the phone and don't hear her voice. Even when it's a telemarketer. Telemarketers at least have a purpose for their mindless prattle, unlike my mother-in-law. I now consider telemarketers to be my best phone buddies. Problem solved.
Yes, IBM manufactured some of the G3s and G4s under contract, but they didn't design them. For the Power series of chips, it's all IBM, from the design to the manufacturing, so the G5 and the Power5 will be largely unrelated (aside from the basic underlying PPC architecture).
I suppose this could mean that the G5 isn't fair away though.
Just because IBM is making the Power5 soon doesn't mean that Motorola is making the G5 soon. They're two different companies with very different design methodologies. If Motorola releases the G5 soon, I'll be surprised. After all, who will their customers for the G5 be? Not Apple, if we believe the rumours.
No, the motives weren't entirely community-minded. Remember that Eclipse forms the basis of the latest versions of the Websphere products. It was probably designed with this in mind first, with open source a mere afterthought. They most likely open sourced it for quick bug recognition and fixes from the community, and to give third party vendors an easy way to customize Eclipse for whatever Websphere-compatible products they want to release. Win-win for IBM.
Unfortunately, that's not how it works for most people. To most people, if a program doesn't "look right", then it doesn't "feel right", so it must not "work right". And when people reach this point, they've decided that the program is a "piece" of "crap", and to hell with the "functionality", they just "know" that it "blows large ass".
So sorry. My weird sense of humour strikes again.
As a compiler developer, I have to say that programmer-driven "optimizations" are (the vast majority of the time) very shortsighted and very local. Sure, you can hand-optimize a function to perform much faster with no (or low) optimization, but most of these optimizations inhibit aggressive interprocedural optimizations that the compiler could do (at high optimization levels) that would increase performance for that function and the areas that call it.
For a simple example, just think about function pointers in C. Sure, you might do better at low optimization levels if you assign to a function pointer and call through that pointer many times. But at high optimization levels, if you had used a switch or if/else type of structure to determine each call, the compiler could inline the most likely call (yes, reasonable heuristics do exist for most of these circumstances). If this call was to be made 90% of the time, you would get an incredible increase in speed by not going through the function pointer, as the inlined code could be aggressively optimized. Sure, the least likely cases would probably get plenty slower, but they would be incredibly unlikely.
To make a long story short, hand-optimization isn't all it's cracked up to be. Keep the code free of "tricks" and you'll give the compiler's optimizer more opportunities to shine.
Is it just me, or did anyone else expect something fun and different from the "Exploded View" on the Zalman website?
Even with no exposure to patterns, I was easily able to understand this book. This book was my first exposure to patterns, and I don't think I could have had a better introduction to the subject. I highly recommend this book to anyone who knows anything about object-oriented design.
Are you kidding? I avoided the prequels like the plague until about a week ago, when I got really bored and saw House Atreides in a book store. Almost immediately, I regretted picking up this sorry piece of crap. There was no subtlety at all in the first hundred pages or so of the book (that was all I could stomach). Too many unrelated plotlines that tie together too many things from the original series. Far too ambitious, with far too heavy a hand. The writers just seemed to feel the need to be clever and instead wound up insulting the readers' intelligence. I have a very hard time believing that this book is any better.
Anyone else have a crazy Korean mother-in-law? You know what I mean!
Great idea! I'd like to see it too. But you'd have to make it applicable to more than just Korean mothers-in-law. I'm not absolutely sure where my mother-in-law's ancestors come from, but I think she's Bitchanese.
read start: end of file apparent state: unit 5 named DATAIN.TXT
last format: list io lately reading sequential formatted external IO
abnormal program termination
This is why there is a process for International Standards (for the moment, let's ignore fast-tracking of standards, which isn't being done for XML 1.1). If one company wants something, they can feel free to propose it, but the other members of the committee can vote it down. If this really does cause a significant incompatibility with a previous version, then the committee will realize it and vote it down. So, no one company can push something down the others' throats.
Think about it. If such a thing were possible, why would compiler writers waste all their time doing it manually?
Actually, I really am a compiler writer, and yes, I do know that such a thing is, of course, impossible. And that was part of the joke in the post you replied to. Asking for the impossible, or nearly impossible. Sort of like request in the story: "Can you give me a link to the nearly impossible? If not, can someone do it for me?" Also, please note the ellipsis at the end of the post. That tends to denote a lack of seriousness in a post that is a series of requests.
On another note, I'm a compiler writer who's having problems writing my compiler. Does anyone who frequents Slashdot know of a tool that will take a language standard as its input, and generate a working, bug-free, efficient compiler? Barring that, is anyone proficient enough in Perl? That's the language I've been using to implement my compiler, and I find that it's great for parsing. And while you're at it, maybe you could...
He's not going to answer this question. If he does, he's copping to another crime (assuming this wasn't one of the charges he's already been convicted of). I suggest that, even if this question gets moderated up to a 5, the editors don't send it, because the answer will just be "I plead the 5th".
Or, in the immortal words of Eric Cartman: "He couldn't act his way out of a nutsack!" It applies equally to Fred Savage and Keanu Reeves.
A lot longer than that Grecian Formula lasted in my hair. Woke up the next morning and my pillow was all black. You see, it's all about what you're comparing the law to.