A big problem with Haskell is that it's very difficult to implement efficiently on todays hardware. The language itself also has no way of expressing any ingenuous in-place algorithms that are often dreamed up in performance critical areas in other languages (I think haskell.org even cites quicksort as one.)
Yeah I can't wait to see the job ads looking for people that know COBOL.NET, in addition to an alphabet soup of other crappy legacy languages they want to be used.:)
Re:Intel C++ Compiler 7.1 Rules
on
GCC 3.3 Released
·
· Score: 1
Setting the right flags for GCC isn't exactly voodoo magic....
You will need to often change flags to suit the application. Messing with the inlining knob is especially common for C++ code. At first it might make sense to set that particular one super-high... but when I did that, I ran into cases where GCC's memory usage would explode so much that the Linux OOM killer would kill the process! On windows it goes into swap-hell. Some more ram can fix that, but nobody should be expected to do that (and I don't think 512mb is "too low" for such a task.)
Also, I think you misread my post. I was prasing ICC's error messages, not GCC's.
Whoops, maybe so.
A quick trip to the Gentoo forums is all it takes. And you only have to choose flags once.
The Gentoo forums is one of the last places I'd ever go to learn that stuff. As someone who's already seen a zillion of those CFLAGS threads, it's obvious to me that many of them never read the manual either and throw in stuff willy nilly left and right (including redundant flags and unnecessary FP flags,..., the whole shebang.)
I would disagree that ICC is more reliable. It's aggressive inliner has broken more code for me than GCC's.
Show me some examples. Having used them both for quite some time now, I'm inclined to think you're being dishonest.
Although, I doubt KDE cats all their source into one blob first.
Thats basically what --enable-final does. And/or Makefiles set it up so a single file #include's a ton of others. That shouldn't be necessary.
Re:Intel C++ Compiler 7.1 Rules
on
GCC 3.3 Released
·
· Score: 1
How about the object code? Can its object code be linked to code compiled by gcc, or is using this an all-or-nothing proposition?
Yup. But not necessarily in the reverse. ICC doesn't support all of GCC's extensions, but enough of them to build the Linux kernel.
For the rest of us, the folks without intel CPUs
Considering that AMD uses intel's compiler to submit their own SPEC scores, I think you can include those too. Non-x86 stuff like MIPS/PPC/SPARC is out though, but I'm sure you knew that.
Re:Intel C++ Compiler 7.1 Rules
on
GCC 3.3 Released
·
· Score: 1
Those benchmarks you linked to aren't worth much. One thing to note thats not emphasized there is that the author was only able to get close by being told by a GCC insider about which of the zillions of knobs to turn just right for those benchmarks. Meanwhile, ICC optimizes extremely well by default and the "knobs" you need to know about can all be summarized nicely in a few-page listing by typing "icc -help." Contrast that to the practically encycopedic GCC manual that requires you to go through various backflips to tune apps. (And even then, GCC frequently misses optimization opportunities that it has support for, IME.)
The claim that ICC has poor error messages is just plain wrong. The EDG C++ front-end that ICC uses is the best there is. Period. This is widely known and even admitted by GCCers.
The error messages and warnings that ICC produces are in a league of their own compared to GCC. One thing inparticular that I find especially useful is it's ability to generate optimization reports and remarks about prohibitive dependencies in my software that prevents optimizations.
Another thing ICC has going for it is that it's way the hell more reliable (IME of course.) There's a damn good reason why -O2 is enabled by default when you run icc: it's a lot less likely to screw up your code, and it compiles fast even when optimizing -- faster with -O2 than gcc is at -O0!
To top it off, I can get it to do two-pass interprocedural optimizations with a simple "-ipo" flag. Thats a lot better way than concatenatting your source into one big giant blob like what KDE does atm.
If Walter Bright decided to allow the FSF to use major portions of his C++ compiler, which he sells commercially (and includes, I believe, much better support for C++ templates than GCC), he would have to assign copyright of his code to the FSF, therefore preventing him from using it in releases of his commercial compiler in the future.
Walter's compiler, DMC++ doesn't have better template support than gcc. What it does have going for it, is that it's the fastest C++ compiler there is... by a long shot, and it generates very good code (the only other comparable C++ w.r.t. code quality is icc IME). He's working on better template support and making sure boost works in an upcoming release. All pretty impressive for something done by a single guy.
I've often thought that your own emotions play against your perception of what and when to eat.
I distinctively remember when I was a little kid, about 5-7 years old, I always ate about the same portions and around the same times.
I've tried the "low carb" / "protein" style of diet and I didn't measure any calories at all. I think the primary benefit was that it was easier to quantify how much to eat, and that I became consistently hungry around certain times of the day.
It made it easier to 'self regulate'. I've lost about 15lbs with about 0 effort involved, besides just the conscious effort to eat something meaty with every meal.
Another thing I wonder is if part of why this sort of thing seems to 'work' is that our systems are evolved to be amenable to that kind of 'input'.
Templates slow compiles to a crawl, often adding tens or hundreds of thousands of lines to every inclusion of a given header in order to define the types it uses.
I can rebuild the entire repository of boost which is oogles of templates in about 1 minute. I don't think compile time is a serious problem, but using templates can include a ton of code, which is what can make templates so useful IMO -- you can chain together huge links of common code, and as a side-effect, the compiler has access to a lot of information. So it's no wonder such efficient code can be generated by using them; it's almost like using global optimization.
With subtly improper use, templates can bloat code size astronimically and create horrendous execution bloat.
You must be using a crummy compiler. It's also well known in the C++ community that templates can generate incredibly efficient code. Ever heard of POOMA? Blitz++?
Let me repeat: development tools HAVE NOT CAUGHT UP WITH C++ TEMPLATES.
What are you using? MSVC 6.0? If so then it's no surprise, MS has been a huge laggard and notoriously shitty in this area -- 7.0 and 7.1 work great. G++ has also been pretty good since 2.95, which was released in 1999.
Then there's Intel's ICC, which is outstanding. Metroworks latest compiler is also reportedly pretty good, judging by boosts tests it's way up there iirc.
There is no debugger available which makes templates as transparent as normal code, inline functions or even #defines.
Templates and inline fcns or #define's aren't comparable.
My suspicion is that you've had a really crappy time with some old/crappy tools which have colored your p.o.v.
There are tons of examples. I have the book and the book is loaded with "concrete" examples. It's also kind of obvious who wrote what, because Josuttis' doesn't use much exotic vocabulary, which is nice.
I know about those, but they don't meet the requirements I listed. The closest would be wxWindows, but it includes a lot more than is necessary and can hardly be called "modern." It's another C++ code base stuck in 1996.
It's pretty cool that something like this exists, especially for big existing codebases, but I so wish there was a nice modern cross platform windowing template library.
It's true that in competition, sabotage offers an advantage -- but typically only short-term. As is demonstrated by the prisoner's dilemma, social groups prefer cooperation even when it is in their best interest not to do so, and often construct mechanisms to thwart such parasitical behavior.
But I don't believe people behave in such a way for any calculated, game-theoretical reasons. One explanation may be that we simply have some innate quality that lends us to cooperative behavior because it has survival value.
Another may be that it's simply because people often have a grandeur vision of outcomes: we attempt to seek out the most optimal solution to problems, even if they have little chance of success.
Both of those seem pretty plausible to me, however I don't think people need to learn to "do good for selfish reasons," because they're already doing so, whether they think they are or not. Whether they're doing things for bad or "good," is also not relevant -- as merely doing anything "good" implies some kind of ethical and moral value system -- of which there is no consensus of what that should be.
This story is really old and no longer relevant. Wouldn't be surprised if it was a dupe of a several-year-old story thats already appeared on slop-dot.
"... programmer does not live in an ideal world. Even if she is perfect, she is sur- rounded by and must interact with code written by major software companies, organizations like GNU, and her colleagues."
I think much of the attractiveness isn't necessarily that the user gets a lot more performance out of the system with more aggressive optimizations -- but that the source based distros can are easier to configure, administrate and upgrade.
That has definately been my experience with FreeBSD and Gentoo.
Since the FSF's policy with GCC requires contributors to sign over their copyrights, they hold all the "cards" so to speak with regard to giving permission -- and I don't think they would.
They would probably say that it would diminish software "freedom" in some way.
In a previous article it was noted that someone from the gcc project recommended that you should use -funroll-all-loops. Did they say why?
Initially I would have thought only -funroll-loops should be used, but after having actually comparing the two on those benchmarks I did notice they improved performance -- which begs the question of why the gcc manual states:
-funroll-all-loops
Unroll all loops, even if their number of iterations is uncertain when the loop is entered.
This usually makes programs run more slowly. -funroll-all-loops implies the same options as -funroll-loops,
I also kept mine. One of my favorites.
Uh, ok, I've heard enough. Someone please tell me where I can get my "Fuck SCO" T-Shirt already. :)
A big problem with Haskell is that it's very difficult to implement efficiently on todays hardware. The language itself also has no way of expressing any ingenuous in-place algorithms that are often dreamed up in performance critical areas in other languages (I think haskell.org even cites quicksort as one.)
Yeah I can't wait to see the job ads looking for people that know COBOL.NET, in addition to an alphabet soup of other crappy legacy languages they want to be used. :)
Setting the right flags for GCC isn't exactly voodoo magic. ...
..., the whole shebang.)
You will need to often change flags to suit the application. Messing with the inlining knob is especially common for C++ code. At first it might make sense to set that particular one super-high... but when I did that, I ran into cases where GCC's memory usage would explode so much that the Linux OOM killer would kill the process! On windows it goes into swap-hell. Some more ram can fix that, but nobody should be expected to do that (and I don't think 512mb is "too low" for such a task.)
Also, I think you misread my post. I was prasing ICC's error messages, not GCC's.
Whoops, maybe so.
A quick trip to the Gentoo forums is all it takes. And you only have to choose flags once.
The Gentoo forums is one of the last places I'd ever go to learn that stuff. As someone who's already seen a zillion of those CFLAGS threads, it's obvious to me that many of them never read the manual either and throw in stuff willy nilly left and right (including redundant flags and unnecessary FP flags,
I would disagree that ICC is more reliable. It's aggressive inliner has broken more code for me than GCC's.
Show me some examples. Having used them both for quite some time now, I'm inclined to think you're being dishonest.
Although, I doubt KDE cats all their source into one blob first.
Thats basically what --enable-final does. And/or Makefiles set it up so a single file #include's a ton of others. That shouldn't be necessary.
How about the object code? Can its object code be linked to code compiled by gcc, or is using this an all-or-nothing proposition?
Yup. But not necessarily in the reverse. ICC doesn't support all of GCC's extensions, but enough of them to build the Linux kernel.
For the rest of us, the folks without intel CPUs
Considering that AMD uses intel's compiler to submit their own SPEC scores, I think you can include those too. Non-x86 stuff like MIPS/PPC/SPARC is out though, but I'm sure you knew that.
Those benchmarks you linked to aren't worth much. One thing to note thats not emphasized there is that the author was only able to get close by being told by a GCC insider about which of the zillions of knobs to turn just right for those benchmarks. Meanwhile, ICC optimizes extremely well by default and the "knobs" you need to know about can all be summarized nicely in a few-page listing by typing "icc -help." Contrast that to the practically encycopedic GCC manual that requires you to go through various backflips to tune apps. (And even then, GCC frequently misses optimization opportunities that it has support for, IME.)
The claim that ICC has poor error messages is just plain wrong. The EDG C++ front-end that ICC uses is the best there is. Period. This is widely known and even admitted by GCCers.
The error messages and warnings that ICC produces are in a league of their own compared to GCC. One thing inparticular that I find especially useful is it's ability to generate optimization reports and remarks about prohibitive dependencies in my software that prevents optimizations.
Another thing ICC has going for it is that it's way the hell more reliable (IME of course.) There's a damn good reason why -O2 is enabled by default when you run icc: it's a lot less likely to screw up your code, and it compiles fast even when optimizing -- faster with -O2 than gcc is at -O0!
To top it off, I can get it to do two-pass interprocedural optimizations with a simple "-ipo" flag. Thats a lot better way than concatenatting your source into one big giant blob like what KDE does atm.
If Walter Bright decided to allow the FSF to use major portions of his C++ compiler, which he sells commercially (and includes, I believe, much better support for C++ templates than GCC), he would have to assign copyright of his code to the FSF, therefore preventing him from using it in releases of his commercial compiler in the future.
Walter's compiler, DMC++ doesn't have better template support than gcc. What it does have going for it, is that it's the fastest C++ compiler there is... by a long shot, and it generates very good code (the only other comparable C++ w.r.t. code quality is icc IME). He's working on better template support and making sure boost works in an upcoming release. All pretty impressive for something done by a single guy.
I've often thought that your own emotions play against your perception of what and when to eat.
I distinctively remember when I was a little kid, about 5-7 years old, I always ate about the same portions and around the same times.
I've tried the "low carb" / "protein" style of diet and I didn't measure any calories at all. I think the primary benefit was that it was easier to quantify how much to eat, and that I became consistently hungry around certain times of the day.
It made it easier to 'self regulate'. I've lost about 15lbs with about 0 effort involved, besides just the conscious effort to eat something meaty with every meal.
Another thing I wonder is if part of why this sort of thing seems to 'work' is that our systems are evolved to be amenable to that kind of 'input'.
I can't wait until someone adds an "Anonymous layer".
Yeah that would be awesome. We of course need to have our god-given right of anonymous anarchy and illegal mp3/juarez trading preserved.
Templates offer compilers enourmous opportunities for optimization, inparticular constant folding and dead-code-elimination.
The whole "templates cause bloat" is something of an implementation problem that can probably be blamed especially on MSVC6.
Templates slow compiles to a crawl, often adding tens or hundreds of thousands of lines to every inclusion of a given header in order to define the types it uses.
I can rebuild the entire repository of boost which is oogles of templates in about 1 minute. I don't think compile time is a serious problem, but using templates can include a ton of code, which is what can make templates so useful IMO -- you can chain together huge links of common code, and as a side-effect, the compiler has access to a lot of information. So it's no wonder such efficient code can be generated by using them; it's almost like using global optimization.
With subtly improper use, templates can bloat code size astronimically and create horrendous execution bloat.
You must be using a crummy compiler. It's also well known in the C++ community that templates can generate incredibly efficient code. Ever heard of POOMA? Blitz++?
Let me repeat: development tools HAVE NOT CAUGHT UP WITH C++ TEMPLATES.
What are you using? MSVC 6.0? If so then it's no surprise, MS has been a huge laggard and notoriously shitty in this area -- 7.0 and 7.1 work great. G++ has also been pretty good since 2.95, which was released in 1999.
Then there's Intel's ICC, which is outstanding. Metroworks latest compiler is also reportedly pretty good, judging by boosts tests it's way up there iirc.
There is no debugger available which makes templates as transparent as normal code, inline functions or even #defines.
Templates and inline fcns or #define's aren't comparable.
My suspicion is that you've had a really crappy time with some old/crappy tools which have colored your p.o.v.
There are tons of examples. I have the book and the book is loaded with "concrete" examples. It's also kind of obvious who wrote what, because Josuttis' doesn't use much exotic vocabulary, which is nice.
I know about those, but they don't meet the requirements I listed. The closest would be wxWindows, but it includes a lot more than is necessary and can hardly be called "modern." It's another C++ code base stuck in 1996.
It's pretty cool that something like this exists, especially for big existing codebases, but I so wish there was a nice modern cross platform windowing template library.
Sure would make a nice addition to boost.
The title of this story completely misconstrues the author's position. The paper is titled "The Case Against Intellectual Monopoly " Not property .
It's true that in competition, sabotage offers an advantage -- but typically only short-term. As is demonstrated by the prisoner's dilemma, social groups prefer cooperation even when it is in their best interest not to do so, and often construct mechanisms to thwart such parasitical behavior.
But I don't believe people behave in such a way for any calculated, game-theoretical reasons. One explanation may be that we simply have some innate quality that lends us to cooperative behavior because it has survival value.
Another may be that it's simply because people often have a grandeur vision of outcomes: we attempt to seek out the most optimal solution to problems, even if they have little chance of success.
Both of those seem pretty plausible to me, however I don't think people need to learn to "do good for selfish reasons," because they're already doing so, whether they think they are or not. Whether they're doing things for bad or "good," is also not relevant -- as merely doing anything "good" implies some kind of ethical and moral value system -- of which there is no consensus of what that should be.
For selfish reasons, but that isn't necessarily a bad thing - it just has a negative connotation.
Do you think you would continue to be "polite" for "altruistic" reasons if people never reciprocated? I doubt it.
The idea of altruism is a fantasy. It does not exist, and thats why its definition seems irreconcilable.
This story is really old and no longer relevant. Wouldn't be surprised if it was a dupe of a several-year-old story thats already appeared on slop-dot.
"... programmer does not live in an ideal world. Even if she is perfect, she is sur-
rounded by and must interact with code written by major software companies,
organizations like GNU, and her colleagues."
Yeah, right. Next.
I think much of the attractiveness isn't necessarily that the user gets a lot more performance out of the system with more aggressive optimizations -- but that the source based distros can are easier to configure, administrate and upgrade.
That has definately been my experience with FreeBSD and Gentoo.
Since the FSF's policy with GCC requires contributors to sign over their copyrights, they hold all the "cards" so to speak with regard to giving permission -- and I don't think they would.
They would probably say that it would diminish software "freedom" in some way.
Their install info says it is targeted to work with glibc 2.2.4 and 2.2.5, but I've been running it on glibc 2.3.1 with no problems at all yet.