Brilliant. Also typical Microsoft. Tell the rest of the world to accomidate their stupidity.
The reason motherboards are specifically forbidden (PCsomeyear or other) from allowing users to switch between APM and ACAPI is because Windows has a piss-poor architecture WRT ACAPI that has totally different sets of code that run in an ACAPI and non-ACAPI environment.
As a result, everyone's stuck with buying a motherboard that only supports one or the other.
You have no *idea* the amount of third-party poor engineering that hits the computer world that Microsoft has caused.
You know, I like everything about Ocaml. Except for the fact that it's a *functional* language. If there were an imperative language with the same capabilities, I'd be in heaven (and so would masses upon masses of other developers).
Last I looked, aside from avoiding the JVM startup time, gcj produced code that ran more slowly than in the IBM JDK (*non-native code*).
Five years from now, when gcj has sped up and can take advantage of the Java 1.5 typed container classes and disable bounds checking, Java may actually become usable, if still slower than C/C++ programs.
Because of the size and footprint issues, you can't do embedded with Java
Well...no. I believe that embedded environments are a rather stripped down form of Java, but Java isn't all that uncommon in embedded systems. Take a look at Javacard -- you'd use it in environments where you typically have less than 64KB of memory.
That being said, I *still* think Java is a terrible language for most people to be using. There's something to the argument that there's "not much better out there".
Problem: C sucks for general application development. A lot of people know it really well, but the whole point of C is that you get a lot of control over exactly what's going on [Disclaimer: I like C, and use it for my application development.:-)]. Problem: C++ is a *huge* language. I thought I knew it once, after a while using it, and then bought Stroustrop's book, and discovered all sorts of things, like autopointers, that I'd never heard of. C++ has a lot of syntactic overhead. Problem: C# is made by Microsoft. Problem: Pascal has vanished into obscurity. Problem: Perl/Python/Ruby aren't as fast as their traditionally compiled equivalents. Problem: Nobody uses eiffel. Problem: Nobody wants to use functional languages, so ocaml and friends are out of the question.
So Java gets used.
I'm firmly of the opinion that Java has a good use -- distributed development.
The problem is that Java was built to make Sun (a hardware company whose primary claim to fame is easy "scalability" by buying higher end machines or more machines) money. Sun's big problem is that most people don't use their SPARC architecture. Java works for Sun by doing two very simple things. It's hideously resource-intensive, from a CPU and memory standpoint. It also is an easy language to easily speed up by throwing more machines into the mix. It doesn't make life a pain if you're using x86 clients with a SPARC server, like rpc can.
Oh, and finally, it has a lot of sexy features to draw people in. It's also a bit easier to learn and work with than C++.
So despite the fact that Java is incredibly slow and RAM-hungry, people bill it as the next big language, the replacement for C++. Frankly, I think Java should stay precisely where its strengths are -- it makes a hella nice language for doing distributed work (especially if you have a client with a front end), and lightweight networking. It's a lousy general purpose language, though.
[This is coming from someone who owns three old releases of Codewarrior for the Mac, and learned C on CodeWarrior]
I now can't stand working without xemacs, and haven't really seen the point of an IDE for years (though I use one at work, just because that's what everyone else is using).
CodeWarrior for the Mac has been a wonderful IDE, if you like IDEs, for years upon years. However, you claimed that it worked on Windows. From what I've seen, the Windows version of CodeWarrior (keep in mind that my experience is about two years out of date) is really, really awful. The professional looking interface that blended in with the Mac's look in the OS 8 days doesn't do so well in Windows. I ran into a number of cosmetic problems, including things not redrawing properly. I also had the IDE crash on me a fair number of times.
So, while I can give my wholehearted support to Codewarrior on the Mac (if you want an IDE), Codewarrior on Windows probably isn't a great idea, unless you already started doing your work on Codewarrior for the Mac and now need cross-platform capabilities.
Also, I don't recomend Gentoo for most users- I am not a fanatic, I just like configuring things myself so when something messes up, there's only one person to blame (go slackware!).
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 ideological difference or liking the distro's packaging policy -- you don't see a bunch of claims that Debian is much faster or more stable than other distros. It hurts all Linux folks to have a lot of false information floating around, and it really doesn't do Gentoo any more good than it does to have Linux folks making outrageous claims about Linux's capabilities.
What you should note is that there ARE performance gains, though slight.
[shrug] That's probably true. -fomit-frame-pointer, at the least is pretty sure not to hurt you aside from the inability to debug.
I didn't know there were this many gentoo-haters out there, but I definitely see only good things from this distribution. No need to bash it nor me. That's getting a little childish.
I don't think I was bashing Gentoo -- I specifically said that it was a "worthy distro". I may have been slightly harsh towards you, simply because of my frusteration with the behavior of a large number of Gentoo users on various forums, but I don't think it was particularly out of line, and I pointed out that I've been in the same boat WRT compile flags.
What I was saying was Gentoo is definitely a distribution to try for new and intermediate users to get to know how their system works and what can be done (e.x.- what services are unneeded) to speed it up.
[shrug] I'm not saying it's *bad* for them, though every distribution I know of (well, I don't know precisely how Debian deals with source, so perhaps not Debian) provides a pretty good learning system. On rpm based systems, you can just create ~/.rpmrc, modify buildarchtranslate, fill in an OPTFLAGS field, and then use rpm --rebuild on a SRPM to do the same rebuilds that you'd do on Gentoo.
My other real irritation is the number of (a long time ago, mostly Slackware, now mostly Gentoo) users that run around telling would-be Linux gurus that any advanced users *clearly* use a system in which they build their own packages. This tends to put these people in a position of feeling that they need to use a particular distro to prove their tech balls. It's not a particularly friendly environment for any new users. (They ignore, of course, the fact that Linus uses KDE on SuSE, and Alan Cox GNOME on Red Hat -- and both of them seem comfortable).
Does that make Gentoo bad at all? No. Of course not. I'd just like to keep the twin nastinesses of "Bob sucks, because he only uses distro X" and "Distro Y beats the shit out of other distros when it comes to performance/stability/other inflated claim" to a minimum.
This is why most serious RH users (anyone who sanely wants to use freshrpms, fedora, etc) use apt or yum. up2date is really atrocious. But while RH doesn't package apt/yum, these third party folks *do* do so, for each new RH release.
They need a hardcore gentoo optimizer in there for the gentoo box, someone that knows what they're doing....Hence, I say the person doing the gentoo install is NOT informed on optimizing gentoo and thus renders this test invalid.
[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.
Well, I haven't poked at it recently, since yum really wowed me.
I've seen it crash an uncomfortable number of times. Last I remember, I had to register the darn thing, giving Red Hat a sellable (forced confirmation) email address. The GUI on the thing (admittedly, not the only way to use the thing, but its CLI is much less comprehensive than apt or yum) is terribly unresponsive -- it blocks when there's an operation going on in the background. Up2date requires a custom server for doing what yum and apt can do with regular ftp and http servers. There are many third-party repositories of software for RH which are only supported with apt and yum (come to think of it, I'm not entirely sure that up2date can even handle multiple sources).
up2date runs slowly (yum is also written in python, but it's much peppier). Yum has pretty intelligent fallback downloading. up2date requires an additional flag to run in console mode. up2date can't display package headers.
IIRC, up2date doesn't cache, as apt and yum did, and just doesn't provide all the functions that apt and yum do.
I've always felt that up2date is RH's biggest out-of-box weakness. There's a good reason that the third party RH providers (freshrpms, fedora linux, newrpms, planet ccrma, atrpms, jpackage, macromedia) all use a different distribution system than up2date.
[shrug] I'm open to new ideas. Convince us. Compile a couple pieces of software with and without your favorite extra flags versus just plain old -O3 and post your times. My experimentation in the past hasn't turned up any significant improvements, but you're welcome to try on more pieces of software and see if you can find major improvements. Avoid gzip, as this is a well-known exception that many people *do* custom-build with an arch setting regardless of distro.
Normally, I'd agree with the "support for whatever you want" argument, but I've spent phenomonal amounts of time in the past trying exactly that -- shaving down binaries, etc. It just plain doesn't make a difference. My favorite example is rxvt. Rxvt is a beautiful, svelte piece of software, and the fastest xterm clone out there. You can comple out almost everything in the package. But, you know what? Linux's loader and VM system are pretty smart -- they only store one copy of the binary in memory. The speed savings you get are pretty small. Most things these days have runtime-settable featuresets. It just really doesn't make sense to try to poke and prod at your system for the extra 1% of speed, because it's just a waste of your time. If you want to make a much more significant difference, try rewriting a chunk of mozilla or something to use a more intelligent algorithm in one place or another. You'll see much more appreciable improvements. I've rewritten core code in gtk-gnutella and dillo for significant performance improvements -- far, far greater than I'd see recompiling software with different options, actually taking less time, and benefitting all Linux users instead of just myself.
Look, Squinky86. I'm not simply pulling this out of my ass. I've had to cover this back in university. I'm not a gcc developer, but I have sat down and gone through generated assembly from the compiler, and have spent many hours tweaking software in every way possible to make it run at a reasonable rate on my old P2/266. There are a very few pieces of software for which arch flags make a measurable difference (as a later poster noted, gzip is one). As for individually specifying flags, I'd be facinated to know what you're trying to use above -O3. You can use -ffast-math. It's unlikely to provide particularly useful results. Approaches like this have been done for a long time (see libmotosh on the PowerPC) -- they can cause the rare, PITA to find problem, and any libs or programs that really need the speed increase have probably done custom work that's even faster than anything you're going to pull with ffast-math (libfftw, for instance). You *might* get some performance gains on povray...but most folks I know compile povray themselves anyway, since it isn't packaged by, say, Red Hat. -fstrict-aliasing is a *very* balsy flag to use if you haven't actually written the software yourself. It's a pretty safe bet that building a lot of unknown software with -fstrict-aliasing will break it. There's a good reason strict aliasing is off by default -- valid C programs (easy ones to write, too) will die with this option, occasionally and in odd ways. You're a damned fool if you use this on *any code* that you did not write or explicitly says that it was written to allow this optimization. I just finished talking to an optimizing compiler designer Thursday who reinforced my feelings about aliasing-dependant optimizations -- they're almost always a bad idea, since the small speedup isn't worth the random problems that you can very very easily induce. -fomit-frame-pointer can produce a small benefit, but surprisingly small, and makes tracking down any crashing bugs or requesting help with a crashing bug infeasible.
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.
If you invest a lot of time in learning a distro, you're terrified that it might not be the best, and will spend ridiculous amounts of time insulting the others.
It's not worth it. Moving from distro to distro for performance is pretty ridiculous.
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
Yeah...my PII/266 definitely takes less than 24 hrs to build X.
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. I have a friend that uses SuSE and Mandrake, and another that uses Gentoo and Debian. All of us write software pretty happily -- all the tools we need are packaged or easy to build for whatever system we want to use. Most folks that I've seen that dislike a particular distro just plain don't know how to use the tools on that distro. I've liked just about every one I've tried, though they all have little things that one does better than the others -- RH shouldn't have shipped gcc 2.96, SuSE should put version numbers in their RPM names (actually, I believe they do these days), SuperRescue should be updated more often.
Heck, the vast majority of Linux users, not so long ago, *were* developers. By that metric, SuSE, Debian, and RH would be the most favored developer distros, though I doubt that contains one iota of useful information.:-)
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.
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.
Huh. That's actually a good point -- I think that a lot of editor infighting comes from the fact that people have made a serious time investment in really learning one editor, definitely do not want to do the same for another editor, and can't stand the thought of having to learn another. So folks start out with one and then argue in favor of it.
I happened to start with emacs, mostly because a professor of mine happened to recommend it, and I've generally preferred it to vi ever since, but I also have about five years of heavy use sunk into it, and I'm comfortable writing my own functions and extensions to the editor. Once you do that, the idea of learning another editor just isn't really appealing.
Console RPGs have a much broader scope than a movie. A novel might be a more fair comparison, but those don't have the audiovisual or interactive elements. A TV miniseries is probably the closest other medium. The experience is still pretty different, though.
I don't agree. The story is mostly advanced during cutscenes/story bits...and there isn't more than two hours of cutscenes in any game that I can think of. The overland exploration mode and combat mode generally contain very little story advancement.
In return for meaningless characters and a boring plot, sure. (Granted, a lot of console-style RPGs have these problems too, but a computer-style RPG has them almost by definition.)
Meaningless? You develop them! They mean a lot more to me than some random scriptwriter's opinion of what a character should be like.
There's absolutely no reason you can't write a {Western,console-style} RPG for the PC, and little reason it can't go the other way, although computer-style RPGs do tend to use features of the PC such as hard disks and network access that until recently haven't been available on consoles, and still aren't standard equipment.
Sure, but I think that's my point. It's a cultural reason, not primarily a technological one. You really don't need *that* many of the extra things (though a keyboard might be nice) to make an open-ended game.
Save games for a Western RPG certainly aren't anywhere near 8MB, so hard drives shouldn't be a limiting factor.
Most people I've seen that prefer vi do so because it has a fast startup time (so they can open one instance per document), or because they got used to it on BSD (which has a strong vi tradition).
I use vi only for editing of large files, since AFAIK emacs cannot do out-of-memory editing.
Slashdot Mirror
Brilliant. Also typical Microsoft. Tell the rest of the world to accomidate their stupidity.
The reason motherboards are specifically forbidden (PCsomeyear or other) from allowing users to switch between APM and ACAPI is because Windows has a piss-poor architecture WRT ACAPI that has totally different sets of code that run in an ACAPI and non-ACAPI environment.
As a result, everyone's stuck with buying a motherboard that only supports one or the other.
You have no *idea* the amount of third-party poor engineering that hits the computer world that Microsoft has caused.
Wow, are you actually TheRealMike, or do all the autopackage developers include a link in their signature?
Google already does this to a certain degree
Shocking. To think that the innovative Microsoft would consider swiping someone else's ideas. What has the world come to?
It is extremely important that *all* developers read the parent post. This IDE may have the most groundshaking features *ever*!
:-)
Let's take a look:
Automatic generation of body files
Hot *damn*! It writes my code for me!
Source code reformatting
Then it reformats it to fit whatever standard I need!
Automatic code fixing
Then it *debugs* the code!
Application builder
Finally, it *builds* the program I'm working on!
All this, from a piece of software that the ignorant layman might consider no more than a wrapper for an editor and a compiler.
Truly, a groundbreaking achievement.
You know, I like everything about Ocaml. Except for the fact that it's a *functional* language. If there were an imperative language with the same capabilities, I'd be in heaven (and so would masses upon masses of other developers).
1) Lead developer has a cool name, like "Anders Heljborg".
Dammit, Anders, aren't you supposed to be coding instead of posting to Slashdot?
Last I looked, aside from avoiding the JVM startup time, gcj produced code that ran more slowly than in the IBM JDK (*non-native code*).
Five years from now, when gcj has sped up and can take advantage of the Java 1.5 typed container classes and disable bounds checking, Java may actually become usable, if still slower than C/C++ programs.
Because of the size and footprint issues, you can't do embedded with Java
:-)].
Well...no. I believe that embedded environments are a rather stripped down form of Java, but Java isn't all that uncommon in embedded systems. Take a look at Javacard -- you'd use it in environments where you typically have less than 64KB of memory.
That being said, I *still* think Java is a terrible language for most people to be using. There's something to the argument that there's "not much better out there".
Problem: C sucks for general application development. A lot of people know it really well, but the whole point of C is that you get a lot of control over exactly what's going on [Disclaimer: I like C, and use it for my application development.
Problem: C++ is a *huge* language. I thought I knew it once, after a while using it, and then bought Stroustrop's book, and discovered all sorts of things, like autopointers, that I'd never heard of. C++ has a lot of syntactic overhead.
Problem: C# is made by Microsoft.
Problem: Pascal has vanished into obscurity.
Problem: Perl/Python/Ruby aren't as fast as their traditionally compiled equivalents.
Problem: Nobody uses eiffel.
Problem: Nobody wants to use functional languages, so ocaml and friends are out of the question.
So Java gets used.
I'm firmly of the opinion that Java has a good use -- distributed development.
The problem is that Java was built to make Sun (a hardware company whose primary claim to fame is easy "scalability" by buying higher end machines or more machines) money. Sun's big problem is that most people don't use their SPARC architecture. Java works for Sun by doing two very simple things. It's hideously resource-intensive, from a CPU and memory standpoint. It also is an easy language to easily speed up by throwing more machines into the mix. It doesn't make life a pain if you're using x86 clients with a SPARC server, like rpc can.
Oh, and finally, it has a lot of sexy features to draw people in. It's also a bit easier to learn and work with than C++.
So despite the fact that Java is incredibly slow and RAM-hungry, people bill it as the next big language, the replacement for C++. Frankly, I think Java should stay precisely where its strengths are -- it makes a hella nice language for doing distributed work (especially if you have a client with a front end), and lightweight networking. It's a lousy general purpose language, though.
[This is coming from someone who owns three old releases of Codewarrior for the Mac, and learned C on CodeWarrior]
I now can't stand working without xemacs, and haven't really seen the point of an IDE for years (though I use one at work, just because that's what everyone else is using).
CodeWarrior for the Mac has been a wonderful IDE, if you like IDEs, for years upon years. However, you claimed that it worked on Windows. From what I've seen, the Windows version of CodeWarrior (keep in mind that my experience is about two years out of date) is really, really awful. The professional looking interface that blended in with the Mac's look in the OS 8 days doesn't do so well in Windows. I ran into a number of cosmetic problems, including things not redrawing properly. I also had the IDE crash on me a fair number of times.
So, while I can give my wholehearted support to Codewarrior on the Mac (if you want an IDE), Codewarrior on Windows probably isn't a great idea, unless you already started doing your work on Codewarrior for the Mac and now need cross-platform capabilities.
Also, I don't recomend Gentoo for most users- I am not a fanatic, I just like configuring things myself so when something messes up, there's only one person to blame (go slackware!).
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 ideological difference or liking the distro's packaging policy -- you don't see a bunch of claims that Debian is much faster or more stable than other distros. It hurts all Linux folks to have a lot of false information floating around, and it really doesn't do Gentoo any more good than it does to have Linux folks making outrageous claims about Linux's capabilities.
What you should note is that there ARE performance gains, though slight.
[shrug] That's probably true. -fomit-frame-pointer, at the least is pretty sure not to hurt you aside from the inability to debug.
I didn't know there were this many gentoo-haters out there, but I definitely see only good things from this distribution. No need to bash it nor me. That's getting a little childish.
I don't think I was bashing Gentoo -- I specifically said that it was a "worthy distro". I may have been slightly harsh towards you, simply because of my frusteration with the behavior of a large number of Gentoo users on various forums, but I don't think it was particularly out of line, and I pointed out that I've been in the same boat WRT compile flags.
What I was saying was Gentoo is definitely a distribution to try for new and intermediate users to get to know how their system works and what can be done (e.x.- what services are unneeded) to speed it up.
[shrug] I'm not saying it's *bad* for them, though every distribution I know of (well, I don't know precisely how Debian deals with source, so perhaps not Debian) provides a pretty good learning system. On rpm based systems, you can just create ~/.rpmrc, modify buildarchtranslate, fill in an OPTFLAGS field, and then use rpm --rebuild on a SRPM to do the same rebuilds that you'd do on Gentoo.
My other real irritation is the number of (a long time ago, mostly Slackware, now mostly Gentoo) users that run around telling would-be Linux gurus that any advanced users *clearly* use a system in which they build their own packages. This tends to put these people in a position of feeling that they need to use a particular distro to prove their tech balls. It's not a particularly friendly environment for any new users. (They ignore, of course, the fact that Linus uses KDE on SuSE, and Alan Cox GNOME on Red Hat -- and both of them seem comfortable).
Does that make Gentoo bad at all? No. Of course not. I'd just like to keep the twin nastinesses of "Bob sucks, because he only uses distro X" and "Distro Y beats the shit out of other distros when it comes to performance/stability/other inflated claim" to a minimum.
This is why most serious RH users (anyone who sanely wants to use freshrpms, fedora, etc) use apt or yum. up2date is really atrocious. But while RH doesn't package apt/yum, these third party folks *do* do so, for each new RH release.
Heh...that should be "never see more than a 10%" not "never see less than a 10%". :-)
They need a hardcore gentoo optimizer in there for the gentoo box, someone that knows what they're doing....Hence, I say the person doing the gentoo install is NOT informed on optimizing gentoo and thus renders this test invalid.
[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.
Well, I haven't poked at it recently, since yum really wowed me.
I've seen it crash an uncomfortable number of times. Last I remember, I had to register the darn thing, giving Red Hat a sellable (forced confirmation) email address. The GUI on the thing (admittedly, not the only way to use the thing, but its CLI is much less comprehensive than apt or yum) is terribly unresponsive -- it blocks when there's an operation going on in the background. Up2date requires a custom server for doing what yum and apt can do with regular ftp and http servers. There are many third-party repositories of software for RH which are only supported with apt and yum (come to think of it, I'm not entirely sure that up2date can even handle multiple sources).
up2date runs slowly (yum is also written in python, but it's much peppier). Yum has pretty intelligent fallback downloading. up2date requires an additional flag to run in console mode. up2date can't display package headers.
IIRC, up2date doesn't cache, as apt and yum did, and just doesn't provide all the functions that apt and yum do.
I've always felt that up2date is RH's biggest out-of-box weakness. There's a good reason that the third party RH providers (freshrpms, fedora linux, newrpms, planet ccrma, atrpms, jpackage, macromedia) all use a different distribution system than up2date.
[shrug] I'm open to new ideas. Convince us. Compile a couple pieces of software with and without your favorite extra flags versus just plain old -O3 and post your times. My experimentation in the past hasn't turned up any significant improvements, but you're welcome to try on more pieces of software and see if you can find major improvements. Avoid gzip, as this is a well-known exception that many people *do* custom-build with an arch setting regardless of distro.
Normally, I'd agree with the "support for whatever you want" argument, but I've spent phenomonal amounts of time in the past trying exactly that -- shaving down binaries, etc. It just plain doesn't make a difference. My favorite example is rxvt. Rxvt is a beautiful, svelte piece of software, and the fastest xterm clone out there. You can comple out almost everything in the package. But, you know what? Linux's loader and VM system are pretty smart -- they only store one copy of the binary in memory. The speed savings you get are pretty small. Most things these days have runtime-settable featuresets. It just really doesn't make sense to try to poke and prod at your system for the extra 1% of speed, because it's just a waste of your time. If you want to make a much more significant difference, try rewriting a chunk of mozilla or something to use a more intelligent algorithm in one place or another. You'll see much more appreciable improvements. I've rewritten core code in gtk-gnutella and dillo for significant performance improvements -- far, far greater than I'd see recompiling software with different options, actually taking less time, and benefitting all Linux users instead of just myself.
Look, Squinky86. I'm not simply pulling this out of my ass. I've had to cover this back in university. I'm not a gcc developer, but I have sat down and gone through generated assembly from the compiler, and have spent many hours tweaking software in every way possible to make it run at a reasonable rate on my old P2/266. There are a very few pieces of software for which arch flags make a measurable difference (as a later poster noted, gzip is one). As for individually specifying flags, I'd be facinated to know what you're trying to use above -O3. You can use -ffast-math. It's unlikely to provide particularly useful results. Approaches like this have been done for a long time (see libmotosh on the PowerPC) -- they can cause the rare, PITA to find problem, and any libs or programs that really need the speed increase have probably done custom work that's even faster than anything you're going to pull with ffast-math (libfftw, for instance). You *might* get some performance gains on povray...but most folks I know compile povray themselves anyway, since it isn't packaged by, say, Red Hat. -fstrict-aliasing is a *very* balsy flag to use if you haven't actually written the software yourself. It's a pretty safe bet that building a lot of unknown software with -fstrict-aliasing will break it. There's a good reason strict aliasing is off by default -- valid C programs (easy ones to write, too) will die with this option, occasionally and in odd ways. You're a damned fool if you use this on *any code* that you did not write or explicitly says that it was written to allow this optimization. I just finished talking to an optimizing compiler designer Thursday who reinforced my feelings about aliasing-dependant optimizations -- they're almost always a bad idea, since the small speedup isn't worth the random problems that you can very very easily induce. -fomit-frame-pointer can produce a small benefit, but surprisingly small, and makes tracking down any crashing bugs or requesting help with a crashing bug infeasible.
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.
If you invest a lot of time in learning a distro, you're terrified that it might not be the best, and will spend ridiculous amounts of time insulting the others.
Hence, the distro wars.
It's not worth it. Moving from distro to distro for performance is pretty ridiculous.
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
Yeah...my PII/266 definitely takes less than 24 hrs to build X.
:-)
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. I have a friend that uses SuSE and Mandrake, and another that uses Gentoo and Debian. All of us write software pretty happily -- all the tools we need are packaged or easy to build for whatever system we want to use. Most folks that I've seen that dislike a particular distro just plain don't know how to use the tools on that distro. I've liked just about every one I've tried, though they all have little things that one does better than the others -- RH shouldn't have shipped gcc 2.96, SuSE should put version numbers in their RPM names (actually, I believe they do these days), SuperRescue should be updated more often.
Heck, the vast majority of Linux users, not so long ago, *were* developers. By that metric, SuSE, Debian, and RH would be the most favored developer distros, though I doubt that contains one iota of useful information.
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.
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.
Huh. That's actually a good point -- I think that a lot of editor infighting comes from the fact that people have made a serious time investment in really learning one editor, definitely do not want to do the same for another editor, and can't stand the thought of having to learn another. So folks start out with one and then argue in favor of it.
I happened to start with emacs, mostly because a professor of mine happened to recommend it, and I've generally preferred it to vi ever since, but I also have about five years of heavy use sunk into it, and I'm comfortable writing my own functions and extensions to the editor. Once you do that, the idea of learning another editor just isn't really appealing.
Console RPGs have a much broader scope than a movie. A novel might be a more fair comparison, but those don't have the audiovisual or interactive elements. A TV miniseries is probably the closest other medium. The experience is still pretty different, though.
I don't agree. The story is mostly advanced during cutscenes/story bits...and there isn't more than two hours of cutscenes in any game that I can think of. The overland exploration mode and combat mode generally contain very little story advancement.
In return for meaningless characters and a boring plot, sure. (Granted, a lot of console-style RPGs have these problems too, but a computer-style RPG has them almost by definition.)
Meaningless? You develop them! They mean a lot more to me than some random scriptwriter's opinion of what a character should be like.
There's absolutely no reason you can't write a {Western,console-style} RPG for the PC, and little reason it can't go the other way, although computer-style RPGs do tend to use features of the PC such as hard disks and network access that until recently haven't been available on consoles, and still aren't standard equipment.
Sure, but I think that's my point. It's a cultural reason, not primarily a technological one. You really don't need *that* many of the extra things (though a keyboard might be nice) to make an open-ended game.
Save games for a Western RPG certainly aren't anywhere near 8MB, so hard drives shouldn't be a limiting factor.
Mmmff..I'd say that Legend of Mana leans seriously towards the Eastern side. It does have a few Western elements in it, but so did, say, FF5.
I'm curious -- why do you like vi more?
Most people I've seen that prefer vi do so because it has a fast startup time (so they can open one instance per document), or because they got used to it on BSD (which has a strong vi tradition).
I use vi only for editing of large files, since AFAIK emacs cannot do out-of-memory editing.
I've found that western RPGs tend to have more of a high-level strategy element, but a lot less glitz in the battle environment.