What payoff is there, at even 5%? Could you run gaim, or Mozilla, or any number of simple command line applications like Pine or mutt any faster if you compiled them from source? >>>>> You wouldn't run them any faster, in the sense that you'd save any real time. However, there are certain algorithms that can make the app feel smoother. For example, in Gentoo (no complex optimizations, just -march=pentium4 -O3) Konqueror resizes more smoothly. Why? The optimizations help out the text-reflow algorithms so they go faster. Do I save any time by having Konqueror resize more smoothly? No. Does it save me some irritation the two times a day that I actually *do* resize Konqueror? Yeah. And two less irritations a day is definately worth an overnight compile of KDE for me.
OpenOffice is going to be slow no matter what you use, so most people just use OpenOffice bin. By and large, anything under 8 hours can be done while you're sleeping, so it's usually not a big deal. On my 2GHz P4, everything I've ever tried (including KDE) is under 8 hours.
I'm sure the time you spend modifying compile-time optimization flags is quickly regained by the milliseconds faster in which your computer runs. >>>>>> That's a phenomenally stupid arguement. The compile time is a one-time investment, usually done while you're sleeping, partying, having sex, eating, whatever. The pay-offs in performance, even if it is a piddling 5%, are recurring every time you use the software.
Compiling from source: Nice, if you want it, but a pain if you don't. While some distros (FreeBSD, Debian, and RedHat, for example) give you the option, Gentoo has no alternatives. >>>>>>> Not true. There is a binary reference platform available, and if you're really obsessed with getting your software this very minute, you can always install the RPMs, which, by and large, work pretty well in Gentoo.
Except the latest version of Gentoo, unlike FBSD 5.x, is actually stable:) I like FreeBSD (ran a server on it for a couple of years) but I'm not very impressed with the progress on 5.x to this point.
Boost isn't a competitor to Qt. It's more of an extension to the C++ standard library. The two are nothing alike. Qt is classic C++, Boost is modern C++. Boost consists of low-level language extensions, Qt is a complete development framework. Nobody is claiming that Boost is a replacement for Qt. Going forward, Boost is going to be the equivlient of the low-level Java standard libraries. I do claim, however, that Boost + STL is a replacement for the low-level stuff in Qt, like strings, lists, signals, etc. Nobody rolls their own collections in Java, it's about time we stopped doing it in C++.
Longtime Gentoo user
on
Gentoo Reviewed
·
· Score: 5, Informative
I've been using Gentoo since 1.0-RC3. I switched my whole system completely over to Gentoo about a year ago, and haven't looked back since. Here are the top reasons I like Gentoo:
1) Community support. The Gentoo community is absolutely awesome. forums.gentoo.org is a one stop shop for any problem you might have. To this day, I have yet to encounter a problem I couldn't fix by a quick trip to the forums.
2) Excellent documentation. Everything is very verbose, and the most thinking you have to do is substitute devices names and the like for the appropriate values for your system. Previous Linux distributions I have used (and I've been using Linux since Slack 3.5) almost always required you to deviate a little from the written instructions, but this almost never happens with the Gentoo docs.
3) Great package management system. It easy for anybody that knows a bit of sh to write their own package build scripts (.ebuilds). As a result, the forums are full of ebuilds for the latest software. Thing of forums.gentoo.org as "0-day Linux Warez." Also, the ease of writing your own packages means you rarely have to bypass the package manager, since it's almost as easy to write your own ebuild (or, more often, edit an existing ebuild) as it is to compile the software manually.
4) Thoughtful extras. The NVIDIA Linux kernel drivers autodetect your kernel, and apply the appropriate patches if you're doing something like running a development kernel. It's these little tidbits that just makes life
5) Great configuration system. The init system makes sense. All environment variables are in files in the directory env.d. All module aliases are in seperate files in modules.d. All configuration parameters are in conf.d. Also, great utilities like etc-update for managing configuration files and whatnot.
PS> Note that nowhere in the top 5 is any reference to optimization. I use Gentoo not to be 1337, but because, after an initial investment in installation time, I ultimately get a very low maintenence, customizable, and flexible machine. So you anti-Gentoo trolls can just fuck off.
Boost is portable to most of the C++ compilers that matter. If Boost isn't supported on your compiler, do the rest of the community a favor and ditch that POS. It's about time pre-standard hacks were relegated to "deprecated" status. As for documentation, I'd argue that the Boost libraries are just as well documented as Qt.
Moc exists because signals and slots can't be implemented without full compiler support for standard C++. Until recently, few compilers offered full support, and a Moc-less version wouldn't have been portable. As for QString, it predates std::string. Why doesn't the iosteam constructor take an std::string instead of a char*? Because std::string's didn't exist when the API was written!
Actually, the last change was Technical Corrigendum 1 published in 2001. However, it was mostly minor defect fixes, so it's not really an excuse. I think they major reason the original parent is bitching is that he's used to Visual C++ 6.x, which just likes to pretend that the C++ standard hasn't changed since 1995:)
Re:Now if only it had a decent name
on
Ogg Now An RFC
·
· Score: 5, Informative
Well, technically, the codec is Vorbis, which is a pretty cool name, if you ask me.
Re:This is why Human Interface Design is important
on
Making Change
·
· Score: 1
The ivory tower academics are certainly earning their reputation for foolishness. >>>>>>>>>>>> Of course, the teeming masses are certainly earning their reputation for messing up well-laid plans with their idiocy!
Re:Intel C++ Compiler 7.1 Rules
on
GCC 3.3 Released
·
· Score: 1
Genericity is just the tip of the iceburg (and JDK 1.5's genericity is kinda hackish anyway). The template mechanism can be used as a complete code generator, and is the basis for lots of cool libraries like those found in the Boost, Spirit, Loki, and Phoenix libraries. In particular, the Phoenix library implements a rather decent lambda abstraction, completely through the use of templates. However, all these techniques are rather modern, so it will be awhile before compilers stop spewing 100-line template error messages at you. But the foundations of better error messages (the EDG front-end, Boost Concept Check, STLFilt) are there, so the situation seems to be getting better.
Re:Intel C++ Compiler 7.1 Rules
on
GCC 3.3 Released
·
· Score: 1
Yes, template syntax is rather crufty, and requires good error messages, and sometimes even external tools (STL-Filt) to use easily. However, C++ templates do stuff that Java and C# can only dream about, so many people are willing to put up with a little extra hastle to use them.
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. A quick trip to the Gentoo forums is all it takes. And you only have to choose flags once.
Also, I think you misread my post. I was prasing ICC's error messages, not GCC's.
I would disagree that ICC is more reliable. It's aggressive inliner has broken more code for me than GCC's.
I do agree that the "-ipo" flag is rather nice. Although, I doubt KDE cats all their source into one blob first. GCC doesn't do *any* IPO, not even inside a translation unit. Thus, cat'ing the source code into one file wouldn't make a difference.
In my experience, most of the stability problems caused by NVIDIA's drivers are either on machines with SMP, or machines using TwinView, both of which can be flaky. In my personal experience, the only problem I've ever had with NVIDIA's drivers is that they sometimes lock the sytsem hard just when starting X. This weirdness only started with the latest set of drivers, so I'm sure it's temporary, and I don't reboot often enough for it to bother me. I've used their drivers since my Riva TNT was still pretty new, and I don't think I've ever had X lock up on me. Heck, for the last 8 months I've been using development kernels with the NVIDIA drivers and they still haven't locked up on me.
I second that. On my setup, X is pretty much just as fast as WinXP, faster when the machine has a high load. Of course, I have everything nicely tweeked, I run only KDE 3.x applications, and I don't run pixmap themes. The only thing that is slower is window resizing, but that really isn't a speed issue, but a synchronization issue. Since I run pretty much everything full-screen (Alt-Tab + Virtual Desktops:) I don't even notice it unless I'm doing "wiggle tests" to see if the latest version of KDE is any faster:)
The reason it's different from debug and release mode is that the optimizer is invoked in release mode. In debug mode, the order of evaluation is probably very straightforward and results in what you expect. In release mode, the optimizer uses the ordering flexibility between sequence points to optimize loads and stores, so the order of evaluation probably becomes different.
That said, VC++ is a hideously broken C++ compiler. I have nothing good to say about it.
Re:Intel C++ Compiler 7.1 Rules
on
GCC 3.3 Released
·
· Score: 2, Informative
Actually, GCC is really close to Intel C++. If you check out the benchmarks it's neck-and-neck on most code except for some Pentium 4 code and some numeric code. These differences are mainly due to Intel C++'s better inliner and automatic vectorizer. I do agree, though, that Intel C++ rocks. It's free for personal use on Linux, very GCC compatible, and almost as conformant as GCC to the C++ standard. It's also got extremely good error messages, which very important for C++ programmers.
You have to remember that GCC's C support is stable. The C ABI hasn't changed since around 2.95.x. It's the C++ ABI that didn't stabilize until somewhere in the 3.2.x series. The C++ standard is very complex. GCC probably supports it about 99% correctly (better than almost any other compiler except maybe Comeau C++), which means there are still lots of corner cases to fix. Also, there are lots of speed improvements to work on, and C++ compile speed needs to get fixed. So all these releases are incremental steps on the way to getting everything worked out.
I saved about 6 lines of code for each declaration, and I had to write 30 or 40 accessors, so I came out about 80 lines ahead. But the point is that I only had to write the code once, and I can use it again. Meanwhile, the 180-240 lines of code to write the accessors manually is stuff that I'll never be able to reuse.
However, I completely agree with you that template metaprogramming's greatest flaw is that it's uses a seperate syntax. It's an unfortunate side-effect of the way templates evolved. However, I disagree that "extensive rewrites" are involved. By and large, it's really not that interesting to calculate stuff like factorial(n) at compile time. More useful is doing code generation (generating accessors, class hierarchies, etc) which is stuff you couldn't do at runtime anway.
We're not talking about laptops. We're talking about desktops. Powerful x86 laptops are noisy and have short battery life. Hell, I'd use a TiBook if didn't need all the horsepower of a desktop replacement laptop. For a high-end desktop machine, "barely audible" (meaning I can't tell it's on from my chair 3 feet away) is pretty damn good. A lot better than the new G4 towers, which have actually quite noisy.
We're not talking about system performance here. We're talking about processor performance. And for measuring processor performance, SPEC is a pretty good indicator.
How about this. It takes my P4 2GHz more than 8 hours to compile KDE. If I can compile it in 4 hours rather than 8, I'd say that's a huge savings. If my 3D CAD software runs at 20fps rather than 10fps, it's the difference between interactivity and watching a slideshow. The fact that many users do nothing more on their machines than surf the internet and use MS Office doesn't change the fact that there are a whole lot of users who do computationally demanding work with their machines. These users are also, in general, willing to pay more money for computer hardware, as evidenced by the profitibility of high-end 3D card manufacturers. Instead of ignoring these types of users, companies interested in their profit margins should be courting them.
Slashdot Mirror
What payoff is there, at even 5%? Could you run gaim, or Mozilla, or any number of simple command line applications like Pine or mutt any faster if you compiled them from source?
>>>>>
You wouldn't run them any faster, in the sense that you'd save any real time. However, there are certain algorithms that can make the app feel smoother. For example, in Gentoo (no complex optimizations, just -march=pentium4 -O3) Konqueror resizes more smoothly. Why? The optimizations help out the text-reflow algorithms so they go faster. Do I save any time by having Konqueror resize more smoothly? No. Does it save me some irritation the two times a day that I actually *do* resize Konqueror? Yeah. And two less irritations a day is definately worth an overnight compile of KDE for me.
OpenOffice is going to be slow no matter what you use, so most people just use OpenOffice bin. By and large, anything under 8 hours can be done while you're sleeping, so it's usually not a big deal. On my 2GHz P4, everything I've ever tried (including KDE) is under 8 hours.
I'm sure the time you spend modifying compile-time optimization flags is quickly regained by the milliseconds faster in which your computer runs.
>>>>>>
That's a phenomenally stupid arguement. The compile time is a one-time investment, usually done while you're sleeping, partying, having sex, eating, whatever. The pay-offs in performance, even if it is a piddling 5%, are recurring every time you use the software.
Compiling from source: Nice, if you want it, but a pain if you don't. While some distros (FreeBSD, Debian, and RedHat, for example) give you the option, Gentoo has no alternatives.
>>>>>>>
Not true. There is a binary reference platform available, and if you're really obsessed with getting your software this very minute, you can always install the RPMs, which, by and large, work pretty well in Gentoo.
Except the latest version of Gentoo, unlike FBSD 5.x, is actually stable :) I like FreeBSD (ran a server on it for a couple of years) but I'm not very impressed with the progress on 5.x to this point.
Boost isn't a competitor to Qt. It's more of an extension to the C++ standard library. The two are nothing alike. Qt is classic C++, Boost is modern C++. Boost consists of low-level language extensions, Qt is a complete development framework. Nobody is claiming that Boost is a replacement for Qt. Going forward, Boost is going to be the equivlient of the low-level Java standard libraries. I do claim, however, that Boost + STL is a replacement for the low-level stuff in Qt, like strings, lists, signals, etc. Nobody rolls their own collections in Java, it's about time we stopped doing it in C++.
I've been using Gentoo since 1.0-RC3. I switched my whole system completely over to Gentoo about a year ago, and haven't looked back since. Here are the top reasons I like Gentoo:
1) Community support. The Gentoo community is absolutely awesome. forums.gentoo.org is a one stop shop for any problem you might have. To this day, I have yet to encounter a problem I couldn't fix by a quick trip to the forums.
2) Excellent documentation. Everything is very verbose, and the most thinking you have to do is substitute devices names and the like for the appropriate values for your system. Previous Linux distributions I have used (and I've been using Linux since Slack 3.5) almost always required you to deviate a little from the written instructions, but this almost never happens with the Gentoo docs.
3) Great package management system. It easy for anybody that knows a bit of sh to write their own package build scripts (.ebuilds). As a result, the forums are full of ebuilds for the latest software. Thing of forums.gentoo.org as "0-day Linux Warez." Also, the ease of writing your own packages means you rarely have to bypass the package manager, since it's almost as easy to write your own ebuild (or, more often, edit an existing ebuild) as it is to compile the software manually.
4) Thoughtful extras. The NVIDIA Linux kernel drivers autodetect your kernel, and apply the appropriate patches if you're doing something like running a development kernel. It's these little tidbits that just makes life
5) Great configuration system. The init system makes sense. All environment variables are in files in the directory env.d. All module aliases are in seperate files in modules.d. All configuration parameters are in conf.d. Also, great utilities like etc-update for managing configuration files and whatnot.
PS> Note that nowhere in the top 5 is any reference to optimization. I use Gentoo not to be 1337, but because, after an initial investment in installation time, I ultimately get a very low maintenence, customizable, and flexible machine. So you anti-Gentoo trolls can just fuck off.
Boost is portable to most of the C++ compilers that matter. If Boost isn't supported on your compiler, do the rest of the community a favor and ditch that POS. It's about time pre-standard hacks were relegated to "deprecated" status. As for documentation, I'd argue that the Boost libraries are just as well documented as Qt.
Moc exists because signals and slots can't be implemented without full compiler support for standard C++. Until recently, few compilers offered full support, and a Moc-less version wouldn't have been portable. As for QString, it predates std::string. Why doesn't the iosteam constructor take an std::string instead of a char*? Because std::string's didn't exist when the API was written!
Actually, the last change was Technical Corrigendum 1 published in 2001. However, it was mostly minor defect fixes, so it's not really an excuse. I think they major reason the original parent is bitching is that he's used to Visual C++ 6.x, which just likes to pretend that the C++ standard hasn't changed since 1995 :)
Well, technically, the codec is Vorbis, which is a pretty cool name, if you ask me.
The ivory tower academics are certainly earning their reputation for foolishness.
>>>>>>>>>>>>
Of course, the teeming masses are certainly earning their reputation for messing up well-laid plans with their idiocy!
Genericity is just the tip of the iceburg (and JDK 1.5's genericity is kinda hackish anyway). The template mechanism can be used as a complete code generator, and is the basis for lots of cool libraries like those found in the Boost, Spirit, Loki, and Phoenix libraries. In particular, the Phoenix library implements a rather decent lambda abstraction, completely through the use of templates. However, all these techniques are rather modern, so it will be awhile before compilers stop spewing 100-line template error messages at you. But the foundations of better error messages (the EDG front-end, Boost Concept Check, STLFilt) are there, so the situation seems to be getting better.
Yes, template syntax is rather crufty, and requires good error messages, and sometimes even external tools (STL-Filt) to use easily. However, C++ templates do stuff that Java and C# can only dream about, so many people are willing to put up with a little extra hastle to use them.
Setting the right flags for GCC isn't exactly voodoo magic. A quick trip to the Gentoo forums is all it takes. And you only have to choose flags once.
Also, I think you misread my post. I was prasing ICC's error messages, not GCC's.
I would disagree that ICC is more reliable. It's aggressive inliner has broken more code for me than GCC's.
I do agree that the "-ipo" flag is rather nice. Although, I doubt KDE cats all their source into one blob first. GCC doesn't do *any* IPO, not even inside a translation unit. Thus, cat'ing the source code into one file wouldn't make a difference.
Ack. I should have qualified it. I meant the earlier VS compilers. I have heard that VS.NET 2003 is quite complient.
In my experience, most of the stability problems caused by NVIDIA's drivers are either on machines with SMP, or machines using TwinView, both of which can be flaky. In my personal experience, the only problem I've ever had with NVIDIA's drivers is that they sometimes lock the sytsem hard just when starting X. This weirdness only started with the latest set of drivers, so I'm sure it's temporary, and I don't reboot often enough for it to bother me. I've used their drivers since my Riva TNT was still pretty new, and I don't think I've ever had X lock up on me. Heck, for the last 8 months I've been using development kernels with the NVIDIA drivers and they still haven't locked up on me.
I second that. On my setup, X is pretty much just as fast as WinXP, faster when the machine has a high load. Of course, I have everything nicely tweeked, I run only KDE 3.x applications, and I don't run pixmap themes. The only thing that is slower is window resizing, but that really isn't a speed issue, but a synchronization issue. Since I run pretty much everything full-screen (Alt-Tab + Virtual Desktops :) I don't even notice it unless I'm doing "wiggle tests" to see if the latest version of KDE is any faster :)
The reason it's different from debug and release mode is that the optimizer is invoked in release mode. In debug mode, the order of evaluation is probably very straightforward and results in what you expect. In release mode, the optimizer uses the ordering flexibility between sequence points to optimize loads and stores, so the order of evaluation probably becomes different.
That said, VC++ is a hideously broken C++ compiler. I have nothing good to say about it.
Actually, GCC is really close to Intel C++. If you check out the benchmarks it's neck-and-neck on most code except for some Pentium 4 code and some numeric code. These differences are mainly due to Intel C++'s better inliner and automatic vectorizer. I do agree, though, that Intel C++ rocks. It's free for personal use on Linux, very GCC compatible, and almost as conformant as GCC to the C++ standard. It's also got extremely good error messages, which very important for C++ programmers.
You have to remember that GCC's C support is stable. The C ABI hasn't changed since around 2.95.x. It's the C++ ABI that didn't stabilize until somewhere in the 3.2.x series. The C++ standard is very complex. GCC probably supports it about 99% correctly (better than almost any other compiler except maybe Comeau C++), which means there are still lots of corner cases to fix. Also, there are lots of speed improvements to work on, and C++ compile speed needs to get fixed. So all these releases are incremental steps on the way to getting everything worked out.
I saved about 6 lines of code for each declaration, and I had to write 30 or 40 accessors, so I came out about 80 lines ahead. But the point is that I only had to write the code once, and I can use it again. Meanwhile, the 180-240 lines of code to write the accessors manually is stuff that I'll never be able to reuse.
However, I completely agree with you that template metaprogramming's greatest flaw is that it's uses a seperate syntax. It's an unfortunate side-effect of the way templates evolved. However, I disagree that "extensive rewrites" are involved. By and large, it's really not that interesting to calculate stuff like factorial(n) at compile time. More useful is doing code generation (generating accessors, class hierarchies, etc) which is stuff you couldn't do at runtime anway.
We're not talking about laptops. We're talking about desktops. Powerful x86 laptops are noisy and have short battery life. Hell, I'd use a TiBook if didn't need all the horsepower of a desktop replacement laptop. For a high-end desktop machine, "barely audible" (meaning I can't tell it's on from my chair 3 feet away) is pretty damn good. A lot better than the new G4 towers, which have actually quite noisy.
Uniforms? Seam? Was that a deliberate pun? If so, let me take a moment to ridicule you.
Ha ha ha.
Thank you.
We're not talking about system performance here. We're talking about processor performance. And for measuring processor performance, SPEC is a pretty good indicator.
How about this. It takes my P4 2GHz more than 8 hours to compile KDE. If I can compile it in 4 hours rather than 8, I'd say that's a huge savings. If my 3D CAD software runs at 20fps rather than 10fps, it's the difference between interactivity and watching a slideshow. The fact that many users do nothing more on their machines than surf the internet and use MS Office doesn't change the fact that there are a whole lot of users who do computationally demanding work with their machines. These users are also, in general, willing to pay more money for computer hardware, as evidenced by the profitibility of high-end 3D card manufacturers. Instead of ignoring these types of users, companies interested in their profit margins should be courting them.