Measuring The Benefits Of The Gentoo Approach 467
An anonymous reader writes "We're constantly hearing how the source based nature of the Gentoo distro makes better use of your hardware, but no-one seems to have really tested it. What kind of gains are involved over distros which use binary packaging? The article is here."
Misses the point (Score:5, Interesting)
Having said that, it looks like the guys doing the testing got their CFLAGS wrong. Gentoo's performance should never be worse than Mandrake -- I reckon they forgot omit-frame-pointer. Also, the kernel compile is unfair, because gentoo-sources includes a whole load of patches that Mandrake and Debian don't.
Finally, what's with measuring compile times? How is that a fair way of measuring performance? Hey, look, my distcc + ccache + lots of CPUs system with gcc3.2 can compile stuff faster than your single CPU gcc2 system... It's like comparing chalk and oranges.
Re:Misses the point (Score:5, Insightful)
Except in this case they all had the same hardware on each machine...
Define 'same' (Score:5, Insightful)
The only way to have the same hardware is to use the same machine for each distro. Period.
Re:Define 'same' (Score:5, Informative)
People tend to forget the complexity of a PC and the inevitable, microscopic differences each part made. Thus differences in resistance, heat generated, and performance.
Re:Misses the point (Score:5, Interesting)
I would have liked to see some tests with things that are more CPU than IO bound, but, realistically, how often do you do those things in the normal case?
If the main reason is to use portage for the convenience (same reason many people use debian), maybe they need to expand portage to support binary packages.
Re:Misses the point (Score:5, Informative)
From emerge --help:
--usepkg (-k short option)
Tell emerge to use binary packages (from $PKGDIR) if they are available, thus possibly avoiding some time-consuming compiles.This option is useful for CD installs; you can export PKGDIR=/mnt/cdrom/packages and then use this option to have emerge "pull" binary packages from the CD in order to satisfy dependencies.
--usepkgonly (-K short option)
Like --usepkg above, except this only allows the use of binary packages, and it will abort the emerge if the package is not available at the time of dependency calculation.
You can also, of course, emerge rpm and install any RPM packages. I'm not sure about debian
Gentoo is also accept pre-orders for it's upcoming 1.4 release. Information can be found here, at the Gentoo Store. [gentoo.org]
They even have precompiled packages optimizaed for Athlon-XP's - drool! [gentoo.org]
Re:Misses the point (Score:5, Informative)
Re:Misses the point (Score:4, Interesting)
So is linux (Score:3, Interesting)
Re:So is linux (Score:3, Informative)
Re:Misses the point (Score:5, Interesting)
Now, the cpu speed has increased by a larger factor than memory speed and disk speed over the last few years, but it's still quite a large bottleneck in many operations, including the ones tested in this (admitedly lacking) test.
Even the speed of a kernel compile, which is often given as a classic `disk I/O bound' process, is extremely CPU bound. How do I know? Running `top' on an idle box shows 0% cpu utilization. Once I start the compile, it goes to well over 90% cpu utilization and stays there until the compilation is done. (just to be complete, I'm testing this on a dual p3 700 box with SCSI disks, doing a `make -j2'. But even my 2ghz Athlon computer with IDE disks works similarly.)
Perhaps I'll do some tests with adjusting the CPU multiplier on a given box, see how that affects compilation times. That would be an excellent test ...
Re:Misses the point (Score:4, Informative)
Compiling binaries with optimization for a particular processor help with i-cache and d-cache utilization. The fewer instructions fetched (or the order in which they are fetched) makes a big difference in performance.
Boosting CPU cache size (up to practical cache limits), increasing FSB speed and avoiding disk IO are much more significant than CPU M/GHz.
Compilation, especially optimized (-0X) compilation is _VERY_ CPU intense. If you have enough RAM to avoid the disk thrashing caused by writing numerous intermediate files you will peg your CPU.
Most user activities (aside from games) on computers are not bottlenecked by CPU but by various heirarchical IO constraints and hence the previous poster was correct that the CPU is not a significant bottleneck on modern systems.
Re:Misses the point (Score:3, Insightful)
maybe I'm not representative of 'most users'
at work I do video processing and at home i play games and encode DVDs to mpeg4.
Even 2.4ghz cpus take hours to encode entire movies... I can get a little better than realtime encoding to mpeg4, but when you add two-pass, and the fact that the videos are so damn long... I wish i could get a terahertz CPU...
you try running a 2 pass encode on a 6 hour 720x480 DV video file and then tell me your CPU is fast enough.
it always make
Re:Misses the point (Score:3, Informative)
Seriously though, doubling the access speed of your RAM is likely to do more good on that sort of task than doubling the CPU speed.
Re:Misses the point (Score:3, Interesting)
(hint: P4 beats the opteron, even though the opteron has a higher real world memory bandwidth and less memory latency and larger cache)
Yea, memory bandwidth
Re:Misses the point (Score:5, Informative)
You obviously don't use GIMP or analyse OS mapping data much. I have the RAM to get the info into memory, IO is not an issue for much of my work.
Having said that, portage is the main reason I've converted all my machines to Gentoo; it's just not a serious option to go back to RPM based systems after using it for a week or so.
TWW
Re:Misses the point (Score:5, Insightful)
Re:Misses the point (Score:3)
Actually,
No.
Canterwood systems have a Pentium 4 with the 800 megahertz FSB and Dual DDR 400. Dual DDR 400 happens to have a total theoretical bandwidth of 6.4 Gigabytes a second, exactly the same as the P4's front-side bus. Plus, the busses are running synchronously so latency is lower.
The Apple G5 has a 1Ghz FSB and Dual DDR 400. Hmmm... that extra 200 mhz of FSB doesn't really do much, does it? It's stil
Re:Misses the point (Score:3, Informative)
Actually I think the key sentence of the article was this:
Doh! No wonder it sucked.
O3 turns on things like inlining that are only worthwhile in certain circumstances, but are often counterproductive. So the results aren't surprising in the least.
Re:Misses the point (Score:3, Interesting)
I will agree that the biggest thing for me with gentoo is actually being able to strip stuff out of an install with a simple USE flag. I actually prefere to build things myself but having a package management system that takes care of dependencies for that is a godsend.
Re:Misses the point (Score:2, Insightful)
Next, they said right in the article that they used an identical copy of the kernel source on each machine, so patches shouldn't make a difference.
Finally, its not that I dont agree with you, their tests did have flaws, it just seems that some of your facts are wrong in attacking them. There are some points that need to be examined, even if some of their conclusions are premature.
Re:Misses the point (Score:5, Interesting)
FreeBSD Update [daemonology.net]. Ok, it only upgrades the base FreeBSD install, starting at binary releases, along the security branches; but it uses binary patches [daemonology.net] to dramatically cut down on the bandwidth usage (and therefore the time used). A typical install of FreeBSD 4.7-RELEASE (released in October 2002) has 97 files totalling 36MB bytes which need to be updated for security reasons; FreeBSD Update does this while using under 1.6MB of bandwidth.
Re:Misses the point (Score:3, Insightful)
That's fine if you happen to be broadband but sucks if you don't. In an ideal world, everyone would be motivated to waste the hours to grab the update, but how many bother, especially with the workings of Linux becoming more opaque and the users less knowledgable? The conseq
Re:Misses the point (Score:3, Funny)
Hehehe....and Mandrake's "urpmi" is one character shorter than that.....
Re:Misses the point (Score:3, Funny)
...and 11 hours later: (Score:2, Funny)
Re:Misses the point (Score:3, Funny)
Re:Misses the point (Score:5, Insightful)
A hearty helping of wtf is in order. Some of your other points are ok, though ;).
Re:Misses the point (Score:5, Insightful)
RTFA. "The same 2.4.21 source was copied to all machines and compiled using the same options. However, it should be noted that the Debian system used gcc 3.3.1 whilst the Mandrake and Gentoo installations used gcc 3.3.2"
Re:Misses the point (Score:4, Interesting)
Real-world benchmarks is a serious matter, I don't even know why this article made its way into
It's rather obvious that those people were not familiar with CPU optimizations and were not thorough with the benchmarking considering they didn't even bother to check for the version/revision of the base package of the distros they were working with even though they do admit that even minor revisions play a considerable role with performance.
1) What are the version/revisions of GCC on those machines? A package compiled and optimized with GCC 3.3 or even the 3.4 beta will obviously offer much better performance than an old deprecated gcc 3.2 that will be installed by gentoo by default if you haven't set up your ACCEPT_KEYWORDS
2) What hard-drive optimization did they set-up? Distros like Mandrake, Debian or Redhat set up HDParm optimizations after the first install, gentoo barely does... That would already make a big difference while opening a 32,000 lines spreadsheet...
3) What are the versions/minor revisions of the Gnome window manager on all those boxes? and GTK? Those packages provide the controls and rendering for Gnumeric... having any difference in these is not fair-play either... (try to install the same version of Gnumeris on a redhat 9.0 and a redhat 7.2 and see if the performance is the same)
To get back on the example of the sports-car race, this is kind of like benchmarking a porche and a ferrari, but you put diesel in the ferrari and forget to inflate your tires...
Basically, if you don't have experience using gentoo on a system for a while and know how to optimize your system, don't go and say that the optimizations don't work... they work perfectly well for me but I couldn't see a difference in my first 2 weeks of using gentoo... it's something you have to learn... you can't just install it and pretend the distro will self-optimize for you...it's not even supposed to.
Re:Misses the point (Score:5, Interesting)
USE="x86 oss 3dnow apm arts avi berkdb crypt cups encode gdbm gif gpm gtk imlib java jpeg kde libg++ libwww mikmod mmx motif mpeg ncurses nls oggvorbis opengl pam pdflib png python qt quicktime readline sdl slang spell ssl svga tcpd truetype X xml2 xmms xv"
Without knowing what support Debian or Mandrake used to compile binaries, this is still an apple/oranges comparison. My notebook isn't configured to compile with KDE or Gnome extensions because the hardare is too old and I use Fluxbox. Mandrake and Debian may still turn out faster (the Gentoo Mozilla e-build was legendary for being slow), but that's not quiet yet proven.
Re:Misses the point (Score:2)
Rus
No. Gentoo is not a performance leader. (Score:5, Interesting)
Omit-frame-pointer is not a regular optimization. Working without stack traces to hand to a developer if you have a problem isn't really a reasonable optimization unless you're doing something like an embedded system, where you couldn't get at the stack trace anyway.
This is *exactly* what the real tech-heads have been saying for years, what my tests confirm, etc. A minor change in a couple of compile flags above -O2 almost *always* makes very little difference. Compiling your own packages really just plain doesn't matter. Maybe if gcc really was incredibly tuned to each processor, but certainly not with the current compiler set.
Also, the kernel compile is unfair, because gentoo-sources includes a whole load of patches that Mandrake and Debian don't.
And perhaps the inverse is true, too?
Look, the point is, Gentoo is not significantly faster than any other general distro out there. If you use it, it's because you like their tools or packaging scheme. You aren't cleverly squeezing out more performance.
Oh, and last of all, I've seen compiler folks saying that it's not that unusual for -O3 to perform worse than -O2. When I was taking our cache performance analysis bit in university, cache hits and misses really *is* the dominant factor in almost all cases. Loop unrolling and function inlining can be a serious loss.
Finally, compiling for different architectures generally makes very little difference on any platform other than compiling for i586 on a Pentium. The Pentium runs 386 code rather slowly. The PII and above will happily deal with 386 code.
And pentium 4 (Score:3, Insightful)
However, AFAIK PPro/P2/P3/Athlon runs these "legacy" code quite well, so relatively little gain can come from compiler option tweakings.
Re:No. Gentoo is not a performance leader. (Score:5, Interesting)
If you know how to and properly configure your compiling flags, the speed gains are tremendous
Bullshit. The vast majority of software I've run benchmarks on will never see less than a 10% performance gain (and that's being *very* generous...most will see no measurable change) with anything other than the default -O2 or -O3.
Oh, hell. I was a lot like you not so many years ago, sure that I could speed things up if I just found the right ways to manipulate the code. The only cure for it is actually sitting down and benchmarking things yourself, since you're sure that everyone else is doing something wrong.
Go ahead, you'll see what I mean. Try building libs that tie up a lot of CPU cycles in multiple apps like libjpeg -- that's where you're going to see your best payback for any optimizations. Time a couple runs.
but if you just try gentoo, the learning experience and speed gains are very noticeable.
I think I've adddressed speed gains. As for learning experience, Gentoo is not synonymous with compiling software from source (from that standpoint, Slackware and similar distros blow Gentoo away). I've never bought into the "learning experience" claims -- let folks start out on the GUIs their distro maker provides, and then, regardless of distro, you can quite happily find out what's going on.
This is not to say that I don't think Gentoo is a worthy distro. I'm a bit of a package management aficiado, and emerge certainly interests me. However, the kind of sweeping claims I see the occasional Gentoo user make on Slashdot are ridiculous. The general-purpose Linux distros are all fairly close together. Distro fans tend to be produced when someone fails to understand how to properly use a different distro (or got accustomed to one), or has sucked down some false claims from other folks, or just don't want to consider that the distro they've sunk lots of time into learning isn't far better than any other choice.
Now, if you happen to like Gentoo, go for it. But like it for the legitimate reasons, not inflated false ones. Don't make exaggerated claims WRT to it, because misinformation certainly doesn't help out Linux folks in the long run.
Re:No. Gentoo is not a performance leader. (Score:3, Informative)
I'm all for folks recommending things they enjoy. The only thing that upsets me is the repeated number of Gentoo users that come on Slashdot or Usenet and make claims that simply are not true about the benefits distro. I see a *ton* of Debian fans pushing their own distro, but usually it comes down to someone claiming an ide
Let's take a look at your claims (Score:5, Interesting)
[sigh] Nobody ever listens to me [Dark City].
Okay, let's take a look at how informed you are. First of all, -mathlon-xp implies -m3dnow, -msse, and -mmmx. -O2 or -O3 is default already on most systems. The only differences -O3 produces is -frename-registers (which does essentially jack on the x86 line) and inlining (which tends to produce very minimal or negative benefits, given the fact that cache misses (which this aggravates) are far more of a timesink for most programs than setting up and returning from function calls). -pipe produces no runtime benefit, though I leave it in my own flags. -fforce-addr, -frerun-cs-after-loop, and -frerun-loop-opt are implied by -O2 or -O3 already. -falign-functions=4 is considered a slowdown for the Athlon line by the gcc team relative to the default (64 on current gcc). I haven't tested -maccumlate-outgoing-args, and I'm not familiar with what it internally does -- the only benchmark I could google for indicated a slowdown caused by it. -ffast-math is a decision of dubious value. Very little code uses floating point math, so ffast-math rarely has an effect. The code that does and actually cares about this degree of performance generally has native implementations that are faster than -ffast-math, since they're special-cased. This can cause software breakage. (We already saw the realization that these sorts of optimizations are of dubious value with Motorola's LibMotoSh for the PPC). -fprefetch-loop-arrays is implied by -O2.
The overwhelming majority of code does *not* have an #ifdef __SSE__ with alternate code.
Basically, the only seriously useful flag you used is that which all distros use -- -O3 (and I generally feel that -O2 is a better choice on modern processors, where cache is so critical). -march=athlon-xp can help, but it's unlikely to make a measurable difference on any but a very few pieces of software. Most distro vendors already benchmark and ship versions of software that benefits with a different arch -- look at RH's different RPMs. -fomit-frame-pointer is arguable -- but you're going to probably see *well* under a 10% performance difference, and you have no ability to track down crashing bugs or send in useful bug reports. -ffast-math can cause breakage, and provides little benefit for almost any package (one exception is povray -- it's a floating point heavy package that tries to be portable). I custom-build povray, but then RH doesn't package povray anyway, so that's not too much of a concern.
Anyway, my point is not to criticize you. I spent my days with a three line CFLAGS string as well, sure that I was producing nicer and better code than anyone else. Then came my benchmarking days and a compiler class and some days picking apart gcc-generated assembly...and I realized that I really wasn't gaining anything.
If you like Gentoo, do it for the legitimate features that it provides (like emerge), and not for some fanciful performance improvements.
Re:Misses the point (Score:5, Interesting)
If you have a fast processor. My Duron 800 can keep itself busy for a weekend compiling OpenOffice.org
Even with the compiling, it takes less time to install some stuff (eg nmap) than it would take to locate the relevant
This is on my Thinkpad 600X, which is a 500 PIII/192MB, with a pretty slow disk:
[root@bgmilne-thinkpad mnt]# rpm -q nmap
package nmap is not installed
[root@bgmilne-thinkpad mnt]# time urpmi nmap
installing
Preparing...
#some hashes replaced to fool the lameness filter#
1:nmap
#some hashes replaced to fool the lameness filter#
5.34user 1.36system 0:26.76elapsed 25%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1712major+8394minor)pagefaults 0swaps
You would need quite a system to beat 26s I think.
Also, the kernel compile is unfair, because gentoo-sources includes a whole load of patches that Mandrake and Debian don't.
From the article:
"The same 2.4.21 source was copied to all machines and compiled using the same options. However, it should be noted that the Debian system used gcc 3.3.1 whilst the Mandrake and Gentoo installations used gcc 3.3.2
I don't see the point of:
-not using the default compiler on the system
-if you don't use the default compiler on each machine, at least use the same compiler across them all
But, otherwise, the comparison looks pretty fair.
Re:Misses the point (Score:5, Insightful)
However, I think that a kernel compile _is_ a fair measure of overall system performance. It involves lots of disk, memory, and processor access, so it's a decent indicator of across the board performance.
As far as kernel compile versions go, from the article:
So the kernel source was the same, not Gentoo source.
You say the performance problems are because they got the CFLAGS wrong. If this is the case it only seems to underscore how easy it is to screw up optimizations with Gentoo. It's great for people that know all the proper optimizations for a particular piece of hardware, but I think the majority of people just don't know this offhand.
In any case I find it very interesting the big differences you can see in performance between distributions on the same hardware (and I'm assuming similar kernel versions).
Re:Misses the point (Score:3, Interesting)
Re:Misses the point (Score:3, Insightful)
Makes you wonder how many Gentoo users actually get their compiler flags right, doesn't it?
Interesting, but I have to wonder. (Score:2, Insightful)
Maybe to the uninitiated this seems informative, but to me it doesn't.
Oopsie! (Score:2)
Despite missing an obvious point, I still stand by my original sentiment: this article isn't very informative at all.
Look, Maw, I'm feedin' them trolls! (Score:2)
I did, and seriously doubt this could be a fair test. The only way you could completely miss the point I made and then make it again for me is if you're either trolling or forgetting to take your medication. Which is it?
Have patience and in some 10 years you will be able to make much of even a short, beautifully written article like that.
In 10 years I've seen tech writing go from "let's praise anything Microsoft" to "let's bash anything
Slow? (Score:5, Interesting)
Anyway, I like the idea of gentoo, and I saw I a lot of Debian users head over to gentoo because the idea of controlling everything including the build was nice, however, I saw the gentoo idea also pretty much die, since a log of these users are power desktop users and not everyone could wait 3 days for X to build.
What I like about debians packages is that if you do make a mistake you can always pretty much correct the package by fixing your souce list or goingt o packages.debian.org and getting the older working package and installing it manuaall with a simple dpkg -i old_package.deb.
In gentoo, you had to rbuild to the whole thing, whihc with x coud take forever. And so what I saw gentoo suddenly doing was having a lot of pre-complied binaries start being provided by gentoo because they saw the problem with building taking forever, and so it kind of killed the whole idea of building for yerself, in which case, if you are going to stick with built pacakged why not have them maintained by some of the best developers around (ie debian)
The othjer thing I noticed is that a lot of developers of software acutally use debian. I've noticed many a time that some cool software wa being made and the developers wouls provide source and they would provide a debian package and nothting else. Ie Debian appears to be the preferred developer's distro. In this I would like to hear discussion,.
Thansk all
Re:Slow? (Score:2)
Interesting, but I have to wonder. (Score:4, Interesting)
Try using binaries compiled for an i686 on a Via C3-1G, for example.
Yes, if your entire reason for using Gentoo is to have control over how apps are built, starting from stage3 pretty much defeats the purpose, and yes, if you don't know what you're doing, then rebuilding X can be a real drag. However, I have to say that I appreciate the fact that Gentoo manages to avoid a lot of legal issues by having the user build the packages her/himself. Honestly, I'd love to be Ogg Vorbis-only for music on my computer, but when I own a portable MP3 player, an MP3-capable DVD player, an in-dash MP3 player, and use OS X at work where QuickTime Ogg Vorbis support is dodgy at best, I want lame. And I want lame support built into kdelibs or whatever lame support needs to be built into so that I can drag-and-drop 192kbps ABR MP3s from an audiocd:// ioslave window to my mp3 folder. ;-D
My own experience has been that Gentoo outperforms Debian on my hardware, but only after I've done some tweaking on Gentoo. YMMV.
Re:Interesting, but I have to wonder. (Score:3, Interesting)
How true, I wish we had a 3dmark type program for Linux, where we could test X performance in 2d/3d, audio, hd, cpu, mem and even latency for each area. Maybe even report performance and features for OpenGL, to see what the drivers do and dont support.
A good benchmark program could be used to see if newer kernels are really faster (ie 2.6) or even those nice pre-emptive kernel
Re:Interesting, but I have to wonder. (Score:2)
I've got RH9 on this machine right now; I happened to be checking my email before moving a chroot'ed Gentoo build over to another drive for installation when I read this article.
Gentoo may take massive amounts of CPU time to build, but it's worth it, oh yes, it's worth it, IMHO.
Re:Slow? (Score:3, Insightful)
Desktop power users on 386's are a rare breed nowadays. I don't know how long it took X to build on my P2 366 w/ 192 meg RAM because I started it before going to bed and it was done in the morning. Maybe these power users should consider hardware before choosing distros.
And so what I saw gentoo suddenly doing was having a lot of pre-complied binaries ....
Lots? OpenOffice has a precompiled option, Opera does because
No distro is the king for "developers" (Score:3, Insightful)
That being said, I'm dubious that blowing the time on compiling your ftp server with all optimizations every time you download a new version really is a worthwhile use of time and effort.
Maybe xmame. Maybe glibc. Maybe the kernel. That's about it. Definitely not 99% of the software on the system.
I don't really think any one distro is much better than the others for development. I happen to use Red Hat, which I do plenty of development on
Re:Slow? (Score:3, Interesting)
Working with debs. (Score:3, Informative)
I've never had a dependency problem I couldn't fix in Debian with a little noodling around with the system. On the other hand, I do sometimes recompile source debs to get options that I need. For instance, I deploy Netatalk with dhx authentication. I hav
FreeBSD's ports (Score:4, Interesting)
Purported performance gains are one thing source packages give you (although I don't enable super optimizations because you never know when gcc bugs with -march=pentium4 -O3 or whatever will bite you).
There are two major reasons I like installing from source, though. One is that you can customize the build to your system; lots of software packages have various compile time options, and when I have the source I can choose exactly how it's going to be built.
Another thing is that when you install from source, you can hack the program to your heart's content. On my desktop box there are around 15 programs that I have to modify to get to act like I want (from simple things like getting cdparanoia to bomb immediately when it detects a scratch to halfway complex things like rewriting parts of klipper and XScreenSaver, which now picks a random screen saver on MMB and lets me scroll through all screensavers with the wheel =).
I don't modify stuff on my servers, but I still get to choose exactly how things are built, which I very much enjoy.
Remember the KDE mandrake/gentoo fiasco? (Score:3, Interesting)
Remember the KDE optimizations that where not included in the Gentoo source release? Everyone was wondering why KDE was faster on Mandrake. There where talk for over 2 months before people realized it was an option Mandrake was compiling with.
Myself, Gentoo's biggest feature was the kernal compile options, adding patches for pre-emptive mulitasking, and improved responsiveness. I noticed the improvements on all my machines, but the compile times where a draw back. And sometimes the applications wouldnt compile.
Mandrake while my favorite choice, doesnt include the best pre-emptive kernels. Which do make a noticable difference. So after installing mandrake, and putting a newer kernel on the system normally takes care of that.
I'm just waiting till beta2 of mandrake cooker 9.2 with the 2.6 kernels, that should make Gentoo and Mandrake on par for speed.
Re:Remember the KDE mandrake/gentoo fiasco? (Score:2)
Myself, Gentoo's biggest feature was the kernal compile options, adding patches for pre-emptive mulitasking, and improved responsiveness.
Really? Hmm.. I run Gentoo and I use vanilla kernels because I find they perform better. I'm on an SMP box though, so that might have something to do with it. But I tried a couple Gentoo kernels and I had *seriously* bad performance problems. Whenever I was compiling the mouse cursor would get all jittery, as would the scrolling song title in XMMS - even if I niced the
Re:Remember the KDE mandrake/gentoo fiasco? (Score:3, Informative)
Re:Remember the KDE mandrake/gentoo fiasco? (Score:2)
Wow, thank you, didnt know about that kernel, looks like it has the patches I was talking about. Did a quick lookup [pbone.net] on pbone and found the info on it.
This kernel includes patches useful for multmedia purposes like: preemption, low-latency and the ability for processes to transfer their capabilities. The preemtion patches allow a task to
Re:Remember the KDE mandrake/gentoo fiasco? (Score:3, Informative)
You mean like this one (from contrib for 9.1)?
Name : kernel-multimedia-2.4.21.0.16mdk
Group : System/Kernel and hardware Source RPM: kernel-multimedia-2.4.21.0.16mdk-1-1mdk.src.rpm
L icense: GPL
Packager : Danny Tholen
URL : http://www.kernel.org/
Summary : A preemptible Linux kernel, which reduces the latency of the kernel.
Description
This kernel includes patches useful for multmedia purposes lik
Re:Remember the KDE mandrake/gentoo fiasco? (Score:3, Interesting)
From a LFS perspective (Score:5, Interesting)
Most of the comparisons in the article were for X-related graphics applications, and while they were comparing the versions of the applications, they were not comparing the libraries underneath them (glibc, X11, and probably the window manager too come into play) and they should've compared versions there too. It becomes complicated because for a typical X11-based app there are probably several dozen libraries involved (in addition to all the configure-time options for them...)
Why use it? (Score:3, Interesting)
OTOH my laptop runs RedHat, because I needed at least one machine running it to stay current with where they dump configs (it's the distro they use at work). Coupled with Apt-RPM it's competent enough, and I have no major problems with the performance.
So yeah, I have to agree with the article - you may like it one way, others may want to do theit own thing. No matter what you chose, you (probably) have binary compatibility, so who gives a sh!t about the holy wars, just as long as you aren't running Windows
Gentoo similiar to *BSD? (Score:2, Offtopic)
I ended up bagging it because there is a fair amount of stuff for Linux that is missing in BSDs (or I wasn't willing to
The Mindcraft method, against itself (Score:5, Insightful)
You'd be yelling bloody murder if Microsoft sponsored a study without doing this sort of research before pitting Windows vs. Linux.
Re:The Mindcraft method, against itself (Score:4, Interesting)
The odd thing is that, from what I've read, a lot of Gentoo folk seem to be trying to compile everything with -O3. This is, frankly, bloody stupid. This turns on a lot of 'optimisations' that are only useful on a few programs and actually harmful for most, and is probably one of the reasons it looked bad in this test.
O1 is the safe level of optimisation. Even O2 runs the risk of doing more harm than good, although it's a fairly low risk. O3 runs a very high risk of doing more harm than good. In many cases Osize is probably the best option anyway, because I/O is more commonly the bottleneck than cpu capability.
And the processor optimisations can also be risky. Every processor out there is designed to run commercial i386 code as fast as possible anyway.
The big wins in compiling yourself are control of configure options, not compiler optimisations. I think source-based distributions are a great idea, but I have to wonder if most people using them right now are getting the benefits.
Re:The Mindcraft method, against itself (Score:3, Informative)
What exactly are you trying to say?
-Os decreases cache misses, and that's just as important on a P4 as on any other CPU.
Opening applications is something most users probably do a lot more often than running bzip.
Makes an excellent point (Score:4, Insightful)
And that is a good point to take home. Optimizing compiles is _not_ the panacea for speed and responsiveness that - a minority, I believe - of source-based distros tend to bring up. There are so many other factors intimately involved in it that any benefits are generally lost in the noise.
For some specific components, it can be a good idea - but for those, most distros tend to ship several optimized versions that the installer chooses between at installation time.
Another domain that benefits are specialized, compute-intensive applications; things like simulators or other technical stuff. But then, those apps are generally tweaked and compiled by their users no matter what distro is used anyway.
You still have dependency hell (Score:5, Interesting)
So the fun starts when you start installing stuff, they don't include support for other components because they weren't there at compile time, you then discover the missing support, have to install the missing libraries and then recompile every package.
This is an especially big issue with multi-media stuff, and gets many layers deep as some libraries have optional components depending on other optional components.
About the only way to guarantee a fully uptodate system is to keep doing complete recompiles of the entire system until there are no changes.
Re:You still have dependency hell (Score:5, Informative)
Please go here [gentoo.org] and reas as much as possible for installing Gentoo so you don't do something stupid.
Re:You still have dependency hell (Score:3, Informative)
I usually say: Gentoo is for users who can read.
Matches my real world dual-boot experience (Score:2, Interesting)
One more thing (Score:5, Interesting)
Upon testing with hdparm, it was apparent that this machine was having troubles setting above udma2. Eventually this problem was traced to the HD cable, a salutary lesson in the variability of identical hardware setups.
Very telling pair of sentences.
Unfair test (Score:5, Insightful)
The distributions were running with different software versions initially and although this was corrected there seems to have been little consideration given to the minor tweaks given to each different installation used. Which services were running on each system? Were the kernel settings identical in use? Were the machines experiencing differences in performance due to the X setup causing X to add different loads?
etc.
Fundamentally this test was probably not complete enough to suggest anything in particular. Perhaps it would have been better to boot a single machine three times and perform the sequence of events exactly the same each time as this would have also ruled out some other potential factors.
Jon.
Reasons I like Gentoo (Score:2)
1. The very large collection of packages. For example, I don't believe you can apt-get install vmware.
2. The very sensible defaults. After emerge wine, I could run Lotus Notes 5 with no changes at all. I tried to set that up on a RH box with wine compiled from source, and it chucked up loads of errors and didn't work.
That said, it does take a long time to set up from stage 1. You're probably looking at about 3-4 days for the base system, X, KDE, Mozilla, and OpenOffice. I'll use it for my personal
Debian alien (Score:2)
VMWare on Debian is best accomplished with alien to convert VMWare's RPM to a .deb, and installing this via dpkg.
As for sane defaults -- Debian tends strongly toward this in my experience.
Happy as a wet turtle Gentoo user (Score:3, Informative)
CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -mmmx -msse -m3dnow"
In some simple tests I have done I have seen this as worth while. I have two pages I have created that might be worth a read:
CFLAGS Guide [grebowiec.net]
Is -mmmx and such worth it? [grebowiec.net]
Hope you enjoy these reads.
Re:Happy as a wet turtle Gentoo user (Score:2)
It takes months to get a mail server properly tweaked, or the delicate Apache installation operational. It really sucks to sweat bullets between living with a root-exploit, trying to re-synthesize RedHat's configuration from source, or praying that everything still works after doing an OS upgrade in place.
T
Re:Happy as a wet turtle Gentoo user (Score:2)
Re:Happy as a wet turtle Gentoo user (Score:2, Informative)
Re:Happy as a wet turtle Gentoo user (Score:5, Informative)
If anything you were also using a relatively small dataset. If you get a large enough data set (or code size) -O3 might actually hurt you (loop unrolling and function inlining will bloat both code and data size and make it much more likely to have a cache miss).
Anyways, synthetic benchmarks are one thing but your is so synthetic as to be rediculous.
Diminishing returns (Score:2)
So when does the time taken to compile the app with extra optimizations exceed the time you save on tasks performed in that app? Of course, that's only if an optimized build is faster, which in this tests did not appear to be th
Ob. Translate-o-matic post (Score:5, Funny)
Enjoy!
Photo views a little skewed? (Score:2, Funny)
Does it seem strange to anyone else that in the linked photo gallery [linmagau.org], the only picture with a female [linmagau.org] has been viewed 3 times more than any of the other pictures?
Sheesh.
I guess there's just not much scenery to show off at distro day.
The real advantage of a source based distro (Score:2)
On a less serious note, the server seems to be having a little bit for trouble; maybe they attempted to install Gentoo on their server (j/k).
I don't mind compiling times (Score:2)
Catch 22 (Score:5, Insightful)
celeron (Score:2)
I think the performance benefits are related to compiling for a specific arch say P4 over how standard distros package at i386 for compatability reasons. This test would be much more interesting if it was done with an Athlon XP or P4. I'm not familiar with celeron arch though, would /etc/make.conf setup be the same for a celeron as a p4? Why would anyone buy a celeron with Athlons at 2Ghz rated athlons go
Portage (Score:2)
A new version of some software was freshly released? sometimes all it takes is renaming the ebuild. I hope they don't complicate this anymore than it already is; it's their greatest asset.
The question is: is this ease of packaging because the p
Default Install = Stage1? (Score:5, Insightful)
I beg to differ subjectively (Score:3, Insightful)
model name : Celeron (Coppermine)
stepping : 3
cpu MHz : 597.077
cache size : 128 KB
Compiling Gentoo on there allowed the machine a third chance at life, the second one being when I got it (already old then) and installed RedHat on it, over that would-be-OS it came with. It just feels that much faster again. I am no longer annoyed by it at all. It took more than 4 days to compile all I wanted from the Gentoo 1.4rc4, but it was *well* worth it.
I moved my personal little server, an Athlon Thunderbird, with the same impression. Currently running
emerge system
on my brand new Athlon XP 2600, expecting much from it.
Bottom line: Nothing but Kudos for Gentoo, wondering what went wrong during the tests described, or whether somehow the subjective speedups I have experienced are just auto-suggestion. I think not. I have been staring at CRT's since 1980, thats 23 years folks! And I tell ya compiling stuff yourself is worth it. So if you have time on your side, go for LFS [linuxfromscratch.org], which I did, and slowly ground into Q-GNU/Linux. If you have some time, but not *that* much time, go for Gentoo [gentoo.org], if you have no time, you poor shmuck, either get a life, or install SuSe
This article is flawed... (Score:4, Insightful)
Moore's Law (Score:3, Insightful)
Given how much better Portage is than any of the other management systems, I'd say Redhat is going to suffer big loses at the hands of Gentoo (Debian would too but the effect will be drowned out by the damage Debian is doing to Debian).
So far I've converted six machines to Gentoo, all from Redhat because I couldn't face upgrading with RPMs anymore.
TWW
All this really shows is that these were bad tests (Score:4, Interesting)
You should repeat every one of the tests a number of times, and make sure that you get the same (or similar) results each time. You should not NEVER expect a 4:1 ratio of performace doing the exact same task on identical hardware. Bells should be going off that say "casual testing" when you see something like that.
Besides, there are so many variables that have to be kept the same between the different installs - which services are running, how they are configured, what kernel options are set, what patches have been applied to the kernel, which modules are loaded... If you pick up Redhat 9 and do a "kitchen sink" install, you will hardly have the same amount of free RAM for caching, etc. compared to doing the "regular" install of some other distro that leaves out things. Hopefully it's obvious that such a comparison that would not be fair at all.
In short, you should take a given kernel source, with a fixed set of patches, options, settings, modules, etc., and complile it with the default i386 options and then a second time with all the fancy optimizaions, then compare those. LEAVE EVERYTHING ELSE THE SAME! Repeat with glibc.
The results in this article are just pathetic. They vary all over the place and are crying out for more rigorous testing methods and procedures. Making a good test is really a science, you have to design the test to specifically measure what it is that you're interested in. For all we know one of those tests could have already had a majority of the libraries loaded into the disk cache, resulting in the huge performance differences.
If you're going to address the benefits... (Score:5, Interesting)
I'd tried RedHat, Mandrake, and a few other distros that set everything up for me so I could "just use it." The problem was that in just using it, I had no idea what I was trying to use. I would go looking for software to do x, y, or z, and I'd either find nothing that seemed to do the job, or a jillion different apps that all did the job differently, and I didn't know why to pick one over the other. Add to that the sense of being at the wheel of an out-of-control car every time I wanted to make a change to a
Gentoo was a brilliant introduction into how to install a Linux-based OS. It started me off easy -- here's the command line, here are the commands to install the system, here are the
Installing Gentoo was more like playing with LEGOs than installing a system, and when I got done with it, I had a computer that I knew, really *knew*. I knew all the init.d services and what they did. I knew what module was controlling what hardware in my kernel *and* how to fix it if it didn't detect properly. I knew all the apps installed, even by their weird names and locations, and I knew what they were there for. I knew it because I built it that way. And I never had to hunt down a dependency or resolve a version conflict. NOT ONCE. Redhat and Mandrake just installed this mysterious Linux Stuff and threw the computer back at me when done. Gentoo got my hands dirty with building it up, but didn't make me jump through hoops to do it.
The benefit was teaching me what my computer was doing when I used it.
*THAT* is how I wanted my computer to run. And it does. Thanks, Gentoo team!
GMFTatsujin
Enough Already... (Score:5, Insightful)
Re:right now (Score:5, Funny)
So are Debian, RedHat, SuSE and Slackware, according to Debian, RedHat, SuSE and Slackware users (respectively). I take it you're a Gentoo fan?
Re:right now (Score:5, Insightful)
Hence, the distro wars.
Re:right now (Score:4, Insightful)
I use Gentoo on my two main boxes, simply because I toyed with it and haven't found a good reason to switch away yet (two just so I have the same environment on my two main machines). That said, my router runs Debian-testing. I maintain Mandrake machines at work, know my way around a RedHat machine... etc. My 486 ran Slack 8 while it was up. My DECStation runs NetBSD (though that's a different issue entirely).
I catch flack for using Gentoo, RedHat, Mandrake... my point is, it doesn't matter at all. Use the right tool for the job - that's what open source, and moreso just diversity in the computing environment, is good for! As long as everything speaks TCP+UDP/IP, who cares? ^^
--Knots;
Re:Bleeding Edge (Score:2)
Then I take it you were running a stable release? Popular software in Mandrake is updated very quickly in cooker (unless there is a good reason not to, such as OpenOffice.org is a point-point release behind because the maintainers working on 1.1).
The Things that Really Matter in a distro (Score:5, Insightful)
Here's what I'd consider, since this is where the biggest differences lie:
* How frequently are new releases announced? Frequent new releases may be better for hobbyists, but a pain in the ass for servers sitting in a back room somewhere. (It's the reason RH can see an enterprise edition that's simply not released as frequently).
* How do you like the packaging system? Try out apt, emerge, up2date (actually, don't -- up2date truly sucks. Everyone using RH who cares about automatic updating has long since started using apt or (IMHO, better) yum).
* How do you like the config system? Most vendors have their own interface to let you configure the system. RH used to use linuxconf, and is now using Redhat-config. SuSE uses yast.
* How much do you care about commercial support? A few widely used distros tend to get the only commercial support. Mandrake gets a little, but if you're going to be running packages that require support (especially binary-only), you're probably best off with Red Hat.
* Which desktop environment do you want to use? Mandrake puts more work into KDE on their system, Red Hat into GNOME.
Arguments about speed or features is really pretty meaningless -- common software is generally packaged for most of these, and rare software for none (use checkinstall to *make* packages -- you'll be much happier). It's still Linux with the GNU suite present.
People that switch from distro to distro (or maintain *multiple* distros on their machine) are nuts, IMHO. It's a fair amount of work to relearn the quirks of each