Linux 3D Games Run Faster On PC-BSD

koinu writes "Phoronix has published benchmarks comparing 3D game performance on Ubuntu Linux 11.04 with the FreeBSD Linux ABI emulation on the 8.2 release of PC-BSD, which is a desktop variant of FreeBSD. Most results show that the emulated Linux layer on FreeBSD performs better than Linux natively. It's pretty interesting, because most people would expect that an additional abstraction layer would generally slow down the execution of binaries."

Comments

Which illustrates what we already knew

[erroneus]

Linux has lost its way.

It was once lean and fast but now is an industrialized bloated mess. It will take a lot more to get me to stop using Linux but that doesn't mean I can't see when something is wrong.

Lately, we have been seeing a lot of Linux's advantages fade away. Among these are its smallness and compatibility with older hardware.

I think it's just about time to revisit what made Linux great and see if there is a way to get that back while still doing great new things.

Re:Which illustrates what we already knew

[Anonymous Coward]

Kinda disagree with that view. Linux allows you to install things like that, but doesn't force you to do it. It's still compatible with old hardware. You can just not install all the crap that makes it "big". Instead of pressing next next next at the install... There is a possibility to do it, but no requirement.

Re:Which illustrates what we already knew

[Anonymous Coward]

Sorry, but we are talking about Ubuntu here. It is taking one of the slowest Linux distributions and slashing it against FreeBSD distribution what is for speed.

It is like timing 100 meter run by attaching iron ball to other runner leg.

Re:Which illustrates what we already knew

[kombipom]

Don't you think that you might be asking for the impossible? How exactly is Linux supposed to keep up with the latest hardware developments and support legacy hardware and stay small? Linux can be paired down to be tiny and run with very little resources but it can't to that as part of a mainstream distro trying to cater for everyone from your gran to a linux gamer to a developer. I think you might have your rose-tinteds on about the good old days when hardware compatibility was a nightmare and the amount of linux software was a tiny fraction of what we have today.

Re:Which illustrates what we already knew

[ByOhTek]

As a FreeBSD user, I can't necessarily agree with you.

WoW also performs better on FreeBSD/Wine than it does on Windows. The issue here, is the graphics capabilities. If it asks less of the graphics card, it will still run, but run faster. In the case of WoW, it's not trying to do nearly all the fancy GPU stuff that windows would do, so it is faster.

Now, if this were various server/desktop non-multimedia applications, I might start to find the article relevant.

Re:Which illustrates what we already knew

[ByOhTek]

That's just it, adding hardware compatibility will increase disk space, but unless it's poorly done, that's about it. I seriously doubt Linux loads every driver installed, regardless of need.

I think the bigger issue is the interfaces/etc. Unless I am mistaken, Linux has a less stable (as in it change more, not crashes) API than FreeBSD. Having to adapt to this, multiple times, could ad to kludgy patch jobs in applications, making them run less and less efficiently. It may not be the Linux kernel or drivers that are the problem, bur rather, all the Linux applications that are running, and competing for resources.

Re:Which illustrates what we already knew

[poetmatt]

linux hasn't lost it's way. You're conflating linux and ubuntu. Ubuntu is bloated to shit, centos, fedora, other flavors of linux are not at all as stupidly bloated.

Re:Which illustrates what we already knew

[CubicleView]

So lack of graphics support is a feature?

Re:Which illustrates what we already knew

[Anonymous Coward]

The drivers are NOT what is making Linux (Ubuntu in this case) too big. And the GP is completely correct, Linux now lacks drivers for quite recent hardware, it is ridiculous.

But for space, it's basically OpenOffice and it's language packs that hogs half the install, and then the broken dependencies. You can't completely remove Office without removing GNOME. Also, many other packages I seldom use has silly dependencies and wants to uninstall something else that I want to/have to keep. Also, Ubuntu could use some trimming of startup services and daemons. What about an optimized i686 build that utilizes newer CPU extensions? I don't know how the i386 is compiled, but I believe it is a very basic build. Yes yes i know i can compile it myself and yada yada but hey sorry i have a life. And so does the rest of the world.

Re:Which illustrates what we already knew

[bejiitas_wrath]

Concerning the OpenOffice debacle, I always used to uninstall Gnome and OpenOffice and then install a vanilla build of OpenOffice from a rpm pack and then I could run OpenOffice without any of the Gnome dependencies. But that was a while ago... Is Libreoffice the same?

And they really should have used Debian instead of Ubuntu, the 11.04 release is getting very bloated with the Unity / Gnome 3 desktop.

Re:Which illustrates what we already knew

[MrHanky]

Shouldn't matter at all here, as both use the same driver. Difference in desktop environment, though, can mean a lot. Then again, Ubuntu seems to suck at 3d, also when compared to other Linux distros.

Re:Which illustrates what we already knew

[ByOhTek]

But the GP was suggesting this was making it big and slow. It can increase the disk space (not like OOOrg or KDE, for example, though), but I cannot see adding hardware compatibility would slow the OS down like he was suggesting (consider the context of what he was responding to).

Re:Which illustrates what we already knew

[maxwell demon]

I guess it's the graphics-card using 3D compositing window manager Ubuntu uses (or did they switch that off? I didn't read the article). I switched that off on all my computers in part for exactly that reason: It hurts performance of 3D games.

Re:Which illustrates what we already knew

[ByOhTek]

Actually, the graphics support is really good, but in my example, WoW has a *lot* more graphical features turned on in DirectX than OpenGL, so it would run faster in Linux or FreeBSD because it was using OpenGL (you had to run it in OGL mode in wine).

I don't think that is the issue in this test, because the FreeBSD nVidia driver is very close to the Linux nVidia driver. However, I cannot discount it as a possibility either.

No, I wasn't saying it was a feature, I was saying that this test is meaningless.
In the context of statements like this

As a FreeBSD user, I can't necessarily agree with you.

or this

Now, if this were various server/desktop non-multimedia applications, I might start to find the article relevant.

That should have been very obvious.

Re:Which illustrates what we already knew

[ByOhTek]

Yes, I guess my bigger point was, that there are a lot of things that could affect that particular benchmark, and make one option faster without being better, even if, ostensibly, all controllable variables are normalized between the two systems.

Re:Which illustrates what we already knew

[ByOhTek]

Actually reading TFA

Comparisons:
CPU: Same
Mobo: Linux: MSI, BSD: (ASUS?) - In my experience MSI is slightly faster and a bit less stable
Memory: Linux: 4GB, BSD: 3.2GB
HDD: Doesn't say the brand for BSD, but the size appears right for a 2^10th united 250GB drive. Seagates aren't known for their speed though.
GPU: Same
Audio/Network: Different, probably wouldn't provide more than a small variance
Desktop Manager: Linux: Unity, BSD: KDE4 - Neither is resource friend, so I can't make a call on this.
X: Linux's is newer, speed improvements or feature bloat?
Driver: Same.
GCC: Linux is newer so will probably optimise better, or be about the same. But these are probably the system defaults, so I have trouble saying this is inappropriate.
FileSystem: BSD has zfs, which I believe is faster than ext4, but I'm not sure on this. Is this the native for PCBSD? FreeBSD, to my knowledge still defaults to UFS2

"unfair" advantages for Linux: More memory, possibly a faster mobo.
"unfair" advantage to PCBSD: possibly the use of zfs, it depends on if it is the default for PCBSD. PCBSD might have something faster than a slowgate.
Wildcards: Unity vs. KDE4, X versions, audio, network.

Re:Which illustrates what we already knew

[pe1rxq]

I am wondering why the author of the article couldn't be bothered to compare BSD and Linux on the same hardware.

Looking at that list I get the impression that he spent a lot of time making sure he compared apples and oranges.
This benchmark is pretty much worthless

Re:Which illustrates what we already knew

[maxwell demon]

Ubuntu *IS* linux. Those other distributions are completely irrelevant because they have only a tiny fraction of the user base of real linux (Ubuntu).

And hard data to back up that claim?

You Ubuntu zealots

Someone saying Ubuntu is one of the worse Linux distribution is anything but an Ubuntu zealot.

need to just admit that it is a failure of an OS and move on to OSX already like the rest of us with actual brains

So now it is officially allowed to install OS X on my PC? No? Thank you, I won't buy overpriced hardware.

And BTW, isn't OS X completely irrelevant because they have only a tiny fraction of the user base of proprietary OSs (the vast majority using Windows)? :-)

Re:Which illustrates what we already knew

[miquels]

Unless I am mistaken, Linux has a less stable (as in it change more, not crashes) API than FreeBSD. Having to adapt to this, multiple times, could ad to kludgy patch jobs in applications, making them run less and less efficiently

The internal linux kernel API is not set in stone, but the ABI for applications that run on the kernel is. You can start applications from 1998 on a 3.0 linux kernel from this year, and they will run.

Mike.

Re:Which illustrates what we already knew

[L4t3r4lu5]

You should probably point out that there is not a lot of difference to the observer between OpenGL and DX9 rendering in WoW. At least, there wasn't when I was dual booting and running WoW between Windows XP and Lucid Lynx.

Same hardware, different renderer, faster on Linux, didn't look much different. Shame I play more than just WoW, really.

Re:Which illustrates what we already knew

[Anonymous Coward]

Actually, I believe it's the same hardware, just reported by a different name under BSD and Linux. I can find no "7462MS" motherboard, only the MS-7462 by MSI, the model used under Linux. BSD reported 3.2GB of RAM under x86, and 4GB under x86-64. The other differences are the basic software installation under the 2 OSs.

Re:Which illustrates what we already knew

[tibit]

Compatibility with older hardware requires someone who has the hardware and free time to actually maintain the drivers. There's no magic to linux. If there's no one interested in maintaining a driver, then the driver eventually gets dropped. You're free to step in if you have the hardware, instead of just, you know, whining.

Re:Which illustrates what we already knew

[tibit]

Haha. So, you've obviously tried it, with repeated, positive results? The kernel ABI is pretty much irrelevant. Good luck getting an app from 1998 to run without setting everything else up (essentially a chroot environment for it).

Re:Which illustrates what we already knew

[bluefoxlucid]

Ubuntu is known to be particularly slow. There was a long standing bug "Firefox takes 17 seconds to load; Firefox binary downloaded from official site takes 3" but I switched to Chromium last year.

Re:Which illustrates what we already knew

[Doc Ruby]

A lot of that "bloat" is useful to one user or another. Not all of the bloat is useful to any one person, but combine it all for everyone and there's bloat.

Which is exactly what's wrong with other OSes (and apps), especially Windows. The scale economy of billions of users means giving them everything that the largest collection of them wants, even if none of them wants it all.

The difference with Linux is that you do not have to install anything you don't want. You can select what you want, at any level. Hell, you can even edit the kernel and rebuild it without code you don't want. But just configuring which SW is installed is easy enough that anyone concerned with bloat can do it, or have someone else do it. Without relying on OS marketers to decide or do it.

Indeed that kind of configurability, mainly through APT (though yum and other package managers also do the job), is only recently a completely standard part of Linux, and inspired app stores in the other OSes. So Linux has found its way, not lost it, as usual.

Who has lost their way? Sounds like you have. Why don't you use a package manager, or an OS configurer, or pick a different distro, if you think the default is too bloated? And if it's not bloat, but compatibility with older HW, that you're disappointed in, why don't you do something to encourage the support of old HW in new versions, instead of just complaining about it or prophecying the end of Linux? Linux is different because people like you can change it. If you don't do that, you've lost it. Linux still has it, for the people who use it right.

Re:Which illustrates what we already knew

[bluefoxlucid]

If BSD can emulate linux faster than linux can run, something is very, very bad going on.

Why? It just means BSD is faster somewhere than Linux, that's all.

Nothing is "emulated." Wine does not "emulate" windows, either. Wine supplies a dynamic link loader that brings up PE executables. It also supplies a set of libraries for Windows-- Wine is a Windows re-implementation. It comes with an msvcrt that supplies strcpy() and strlen() and open() and such. It comes with kernel32.dll. It comes with everything.

Unix systems that have other Unix system execution layers basically keep an additional syscall table around. BSD loads a Linux ELF executable, recognizes it's for 32-bit Linux, and sets its syscall entry point to the Linux table. All POSIX functions mostly route to BSD's innards, just like the native BSD table. A few tricky things supply a little translation layer--we might see data come by in format [xxx][yyyy][zzz] and we expect it in [xxx][pad][yyyy][zzzz] so it's padded properly, or something equally as banal. Some specialized functions are implemented for Linux, using BSD facilities to approximate.

In the end, you have an operating system that capably loads binaries under a specific API, not an emulator.

Re:Which illustrates what we already knew

[Anonymous Coward]

Seriously, mod this up! Linux is _highly_ configurable and will perform very differently with different sets of options and supporting user-space software. Please remember, Linux is NOT an operating system. It's hardly even fair to call it a kernel. It's a set of sources and build scripts that can be used to make a near-infinite number of different kernels.

Re:Which illustrates what we already knew

[poetmatt]

This is hilarious. How am I an ubuntu zealot when I explicitly state that I blame ubuntu? Try any other distro and the difference is enormous: the interface isn't as stupidly cluttered, and guess what? It doesn't look like OSX.

Some of us geeks don't actually like ubuntu.

Troll harder next time, $trolltype

Re:Which illustrates what we already knew

[xeube]

Have you checked the following: http://www.debian.org/ports/kfreebsd-gnu/ ?

Re:Which illustrates what we already knew

[desertrat_it]

oh, give it a rest already, Stallman. You lost. Get over it.

Re:Which illustrates what we already knew

[rgviza]

Linux hasn't lost it's way. It's kernel is still configurable. You can turn off the stuff you don't want in there and recompile it.

Try using Gentoo, which makes this very easy, compared to redhat, Ubuntu etc. which have dependencies on the bloat in their packages. Ever tried to recompile a red hat kernel? It's not pretty.

Ubuntu is the problem, not linux.

The article (as is often the case) has a misleading title. It should be "Linux 3D Games Run Faster On PC-BSD than they do on the Ubuntu distribution of linux"

I'm sure that it would be a different story on a kernel without the bloat. People need to realize that often linux distros are far less than optimal. They are trying to be like windows and have everything and the kitchen sink in the kernel. Ubuntu is NOT linux. They are a company that simply packages linux in a distro and make it "easy" though for any specialized application, using Ubuntu is anything but easy. It's meant to be a general purpose desktop os that anyone can install.

You'd see much higher gaming performance in Gentoo, which like FreeBSD, is compiled from source for your processor with your options. FBSD uses ports, which is very similar to portage used in Gentoo. It downloads source, looks at your kernel and compiles the code with the right options for your system.

I strongly suggest that if you want to get the most performance out of linux, use a compiled-from-source distro like gentoo. It makes a HUGE difference. It takes a lot longer to set up your system (since you compile the entire thing from source) but the end result is worth it if performance is your #1 goal.

Re:Which illustrates what we already knew

[ArcherB]

You should probably point out that there is not a lot of difference to the observer between OpenGL and DX9 rendering in WoW. At least, there wasn't when I was dual booting and running WoW between Windows XP and Lucid Lynx.

Same hardware, different renderer, faster on Linux, didn't look much different. Shame I play more than just WoW, really.

I don't play WoW, so I can't speak to that. I can tell you, however, that Starcraft 2 is pretty much unplayable on Linux where I can max it out in Windows.

My system:
AMD Phenom II 965 (Quad core at 3.4 Ghz)
AMD/ATI Radeon HD 6000 series video (drivers directly from AMD. The ones that came with Ubuntu didn't seem to work)
4GB RAM

It will run if I turn everything off... and I mean everything. I don't even see the units shoot or attack everything is so minimal. I'm sure I could tweak it a bit more, but, how much better could it possibly get?

I have not tried BSD, of course. Does anyone know if it actually runs "better" than it would on Windows?

Re:Which illustrates what we already knew

[rgviza]

yea but the average FreeBSD distribution is lot more optimized than the average bloated linux distro such as Ubuntu. Ubuntu is made for the masses and I'd be surprised if the number of drivers NOT in the ubuntu kernel is more than the count of fingers on my left hand.

FreeBSD is made by engineers for engineers in most cases. Ubuntu is built so some uneducated guy in Bangladesh can load it on his crap whitebox laptop with random hardware and it JustWorks(tm) and has him up and surfing the internets within 20 minutes. Ditto for windows. That takes a lot of kernel bloat to accomplish.

Ubuntu's mission is admirable and they do a bang up job. However you don't want to use Ubuntu for any task where the best performance possible is required. Squeezing every last ounce of performance out of your hardware and software takes a little more work than "pop the disk in and wait". Install Gentoo, strip the bloat out the kernel and you'll see what I'm talking about.

Re:Which illustrates what we already knew

[laffer1]

The FreeBSD developers did a major overhaul on the Kernel starting at 5.0. They introduced fine grained locking into the kernel. Translation: they made it SMP friendly and ready for all the multicore CPUs we have now.

Some developers didn't agree with the work and eventually moved on and that's why we have Dragonfly BSD.

Personally, I think FreeBSD is great. I forked it because I thought it was good but needed work for desktop use. These results don't surprise me entirely, but I do see issues with the benchmark. It could be benchmarking regressions in the newer X server for instance. FreeBSD and MidnightBSD both ship with older versions of X due to Linux people redesigning thinks every minute. We can't keep up. What this benchmark says to me is that the older stuff is good with older video cards.

As far as the linux "emulation" goes, it's not emulation in the same way people think of game emulators or something. It's mostly mapping linux system calls to freebsd system calls and making sure the differences in behavior are handled. (return values and things) There are also many system calls not implemented in FreeBSD that Linux has like epoll or fstat64. You'll notice this right away if you try to run Firefox 6 for linux on FreeBSD. It will work, but depending on the freebsd version, you'll see warnings in the console about the missing system calls. Part of the speed increase might be that some system calls are never run :)

As far as drivers go, if you want them, help with the effort to write them. Linux people can use our code, but we can't use theirs. They're nice enough to write the DRM/DRI code in MIT licensed form so we can use it, but most of the linux kernel is off limits due to the GPLv2.

Re:Which illustrates what we already knew

[hedwards]

Historically that would be because of kernels that included a bunch of stuff in them that wasn't necessary. I haven't looked recently so I don't know what the case is presently. Even FreeBSD gets a lot faster when you recompile the kernel to remove support for things like SCSI and parallel ports which chances are you're not using. Anything in the kernel is going to have to be loaded every time and can't be unloaded. Also while you're at it, enabling features that were added with more recent processor revisions.

It shouldn't be as big of a deal as it used to be as both Linux and FreeBSD have moved to provide more hardware compatibility via loadable modules. But, there's certain things which can't be loaded via module and those are the ones that are going to hurt performance.

It's been ages since I tried, but I was never able to get a Linux kernel to actually compile, the process was always a pain, so those unnecessary bits remain in any Linux install I use. At the end of the day, having a 30mb kernel like in the past when I'd look at Linux is bloated no matter how you look at it.

Re:Which illustrates what we already knew

[armanox]

Personally I miss the days of simpler Linux.

Also, I have been compiling custom kernels on Red Hat since Red Hat Linux 6.1 (both from RH's source and the vanilla kernel). Not had the issues that most people have.

Re:Which illustrates what we already knew

[LordLimecat]

WoW also runs faster in OpenGL on Linux than in OpenGL on Vista, last time I compared them (about 2.5 years ago).

Then again, IIRC Vistas OpenGL support is nothing less than "stellar" (for certain values of stellar).

Re:Which illustrates what we already knew

[ByOhTek]

No. You have an ATI card. 3D ATI drivers for anything less than 4 years old are non existent, and barely work for the older stuff.

Re:Which illustrates what we already knew

[theArtificial]

I feel your pain. Unfortunately the windows drivers have the best performance in my experience.

AMD Phenom II 955
nVidia GTX 260
8GB DDR2
FreeBSD 8.2 AMD64, nVidia 275.28 drivers

Re:Which illustrates what we already knew

[glassware]

I agree. Since I hate reading six page articles in tiny chunks I forwarded to the end and missed this. I will remember to be more skeptical of Phoronix in the future. Comparisons of operating systems without identical hardware just aren't appropriate.

Next time, find the greatest common denominator hardware and do a real test.

Re:Which illustrates what we already knew

[ArcherB]

No. You have an ATI card. 3D ATI drivers for anything less than 4 years old are non existent, and barely work for the older stuff.

I certainly agree that drivers are a problem, but 3D works great in native Linux apps. Or, should I say, it works great with the stuff I've run. I don't think I've taxed it too hard or done any benchmarks.

Re:Which illustrates what we already knew

[Creepy]

They say they used the latest nVidia driver, so I'd assume they are using the actual hardware driver. Compositing can still cause a hit to performance, but if the game is run in full screen mode it should not be doing any compositing (it is hard to tell if they were in full screen or not).

And yes, they were using an nVidia card, and nVidia with Ubuntu always makes me cringe (and I am a huge fan of nVidia) because most people don't know they need to install the hardware driver and that it won't install on its own for political* reasons.

*Ubuntu subscribes to the Richard M Stallman school of thought - if it doesn't have free source, it can't be included in the distro, and nVidia only releases binary drivers. However, they at least make it easy to find in their package manager, provided you know you need it. I have helped several Ubuntu (and Debian) Linux noobs with this, the most recent was my best friend's wife. She was having performance issues with Boxee - and yes, she is a techie, far geekier than my friend (she plays in an all girl D&D group, plays MMOs, actually tries different OS's like Linux [my friend wouldn't], etc) - so now she has a re-purposed retired game machine, mainly for their kid to watch internet TV on.

Re:Which illustrates what we already knew

[X0563511]

It sucks, but you should learn to wrangle 'equivs' (for Debian based distros).

Make a package that 'provides' something, and you can remove the other.

Note though that you really have to know what you're doing. It's easy to break stuff by tricking the package system into thinking something is there when it's not.

Re:Which illustrates what we already knew

[X0563511]

OK then smartass, make that a static binary. That's one of the cons of dymanic loading.

Re:Which illustrates what we already knew

[Galactic Dominator]

You mean like this?

http://people.freebsd.org/~kris/scaling/os-mysql.png

Re:Which illustrates what we already knew

[X0563511]

I don't think that means what you think it means. You just committed a version of the "could care less" mistake.

Re:Which illustrates what we already knew

[LordLimecat]

Nothing less than stellar meaning that it is fully "stellar". In other words, its not partly stellar, 3/4ths stellar, etc.

Its not a mistake, its both grammatically correct and a common usage of the phrase. Quit trying to be pedantic.

Re:Which illustrates what we already knew

[Runaway1956]

Uhhh - that "compatibility with older hardware" is NOT one of the things that made any *nix "great". Back in the day, when Torvalds and others were creating Linux and other *nixes, they were operating on (then) modern hardware, or even bleeding edge hardware.

Face it - Linux wasn't primarily designed to be run on mainframes, 8086 processors, or the myriad of other antiquated gadgets from history. Linux was meant to be cross-platform from the start. The platforms were rather limited, 20 years ago, but the intention was stated very early on. Today's platforms have gigs of memory, and lightning speed, with ultra-complex graphics rendering hardware - why not make use of it?

There are, and always will be, "lightweight", as well as obsoleted Linux distros that will run on the old hardware!

Want a small, bloatfree distro? DSL and Puppy come readily to mind. Go get you some!

Re:Which illustrates what we already knew

[Runaway1956]

I've never installed GNU/Linux. Maybe, possibly, if it ever materializes, I'll install Gnu/HURD, to see how it runs. What I install is Linux, with some stuff borrowed from Gnu and other contributors. True, Linux isn't really a "complete" operating system - but Gnu certainly isn't either. Linux is "more complete" than Gnu is.

Besides - I can't keep a straight face when proselytizing if I use the term "Gnu/Linux". "Linux" is just so much cleaner, faster, and easier to say!

Oh yeah - my computer has Super Cow abilities. Mooo, no Gnu!

Re:Which illustrates what we already knew

[X0563511]

Wait... i'm confused. Yes, that is exactly what you wrote, but why would you mean that? I thought you were saying it wasn't stellar? Am I being stupid in thinking stellar is positive?

Re:Which illustrates what we already knew

[theArtificial]

So your solution is what exactly? That specialized doctors should support everyone (especially those with rare conditions) freely and forever? Perhaps this will enlighten you to the challenge of supporting a constantly moving target known as Linux. nVidia even drops support for their older cards for this very reason! Apparently not everyone is a doctor, and the doctors are focusing their efforts on more current issues which is why the support is fading. If you want to run specific hardware why not stick to distributions released around the time your hardware was released or better yet use an operating system which supports your hardware. If either of these solutions is unacceptable perhaps owning a computer is too expensive for your lifestyle.

Re:Which illustrates what we already knew

[lahvak]

It's not really Linux that has become this bloated mess. It is what they call "modern" desktop environments.

I used to run a fairly minimal setup, with fvwm2, xdm for login manager and rxvt for terminal emulator. I had that same setup on wide array of computers, from an old 486 with 512MB of memory up to a powerful SparcStation, and it ran reasonably fast on all of them. Over many years I developed a configuration that I liked, so it was very easy to use for me.

Several years ago I got a dual core laptop with 4GB of memory at work. Since it was a work laptop, I had to use SUSE Linux, as that was at that time officially supported by our IT staff. I had no experience with SUSE, before I always used Debian, so I just installed the default distro with Gnome, and I was surprised how slow that was. Later I got fed up with SUSE, and was allowed to switch to Ubuntu, which turned out to be even slower. I got fed up with that too, installed Debian, which I know pretty well, and started stripping everything I don't need.

I am now back to my original setup with fvwm2. I use slim for login manager, replaced rxvt by urxvt so I can display Chinese characters in the terminal and can have nicer fonts. I now throw in few things that I never used before, such as stalonetray for system tray, and gkrellm for system monitoring and volume control. I manually purged everything that says gnome or kde that I don't actually use (very little is left). I now have a nice fast system again. The thing that slows me down now is firefox. I tried Chrome, which is faster, but last time I checked, its vi keybinding extensions are nowhere near as capable as vimperator or pentadactyl for firefox.

One thing that drives me nuts though is how the desktop environments took over lot of things that really belong to the core system, and changed the way lot of core functionality is now configured. Lot of things, like networking, mounting of drives, etc, that really should have nothing to do with desktop environments, are now configured in some sort of weird gnomish way, which, in addition, completely changed at least 5 times during the last 4 years, and when you try to find out how to do it, you get at least 10 totally conflicting guides and advices. Most of all classical howtos are hopelessly outdated, and were replaced by number of mutually contradictory posts on Ubuntu forums. The result is that figuring out how to configure something without using some sort of default annoying Windows like clicky Gnome or KDE thingy is a huge pain in the ass.

Re:Which illustrates what we already knew

[skids]

Considering the small machines I can boot Linux on, I think you might be confusing "Linux" with distributions. If you want a leaner distribution, choose one. About the only "bloat" that has made it as far as the kernel is the udev/sysfs, and while that could use a little trimming, it's arguably a better system than the alternatives once you get above a 16M memory profile and want modularity.

Re:Which illustrates what we already knew

[tibit]

:)

Re:Which illustrates what we already knew

[bonch]

And with Android, you get the added bonus of the trojans and other malware you thought you left behind on Windows.

Re:Which illustrates what we already knew

[bonch]

I strongly suggest that if you want to get the most performance out of linux, use a compiled-from-source distro like gentoo. It makes a HUGE difference. It takes a lot longer to set up your system (since you compile the entire thing from source) but the end result is worth it if performance is your #1 goal.

A compile-from-source zealot? What is this, 2003?

Re:Which illustrates what we already knew

[Zancarius]

Actually, the graphics support is really good, but in my example, WoW has a *lot* more graphical features turned on in DirectX than OpenGL, so it would run faster in Linux or FreeBSD because it was using OpenGL (you had to run it in OGL mode in wine).

TBH, when I played WoW under Gentoo, I never did notice the difference between OpenGL and DirectX. In some cases, the OpenGL UI felt crisper. Although, I have no idea what it's like now; it's been about a year since I've played.

Of course, this should all be taken as an anecdote; I confess that I've never been too picky about graphics. Maybe that's why I find Minecraft entertaining!

Aside: I do know that addon management in WoW was infinitely easier under an OS with a real shell. :)

Re:Which illustrates what we already knew

[frehe]

Considering the frankly batshit insane 6 month release schedule Ubuntu has everyone on you're lucky any drivers work at all.

Is your problem with the 6 month release schedule, Ubuntu's implementation of it, or both? I'm curious since OpenBSD has managed to have a perfectly held 6 month release schedule for many years without any of the problems you mention.

Re:Which illustrates what we already knew

[bonch]

It is the same hardware. Did anyone RTFA?

Re:Which illustrates what we already knew

[bonch]

It is identical hardware. Apparently, you didn't read the article either.

Re:Which illustrates what we already knew

[theArtificial]

You'd see much higher gaming performance in Gentoo, which like FreeBSD, is compiled from source for your processor with your options. FBSD uses ports, which is very similar to portage used in Gentoo. It downloads source, looks at your kernel and compiles the code with the right options for your system.

Your Gentoo is showing. All software is compiled from source. FreeBSD installs (much like Linux) get you up and rolling with precompiled software known as packages (FreeBSD: man pkg_add) but you may also install the ports collection and cvsup && makeworld if you've ample free time. It's a time suck to mix and match packages if you're customising your sysinstall with special flags and bleeding edge dependencies. Gaming performance in Linux (and every other OS out there) is mainly a driver support game - specifically graphics drivers. Linux has a lot of churn interally which means lots of support, hardware vendors like nVidia have been dropping support for some chipsets because of this. Gentoo implemented portage based off of FreeBSD's ports collection which was implemented in the early 1990s.

I strongly suggest that if you want to get the most performance out of linux, use a compiled-from-source distro like gentoo. It makes a HUGE difference. It takes a lot longer to set up your system (since you compile the entire thing from source) but the end result is worth it if performance is your #1 goal.

Compiling from source does not mean it's super fast just because. The reality is that you'll now be compiling everything - all the time! Not just during the setup (you know most software spends its life in maintenance Have an updated low level dependancy? Recompile everything built on top of that! Do you know how long it takes to compile KDE or GNOME (or BOTH) plus a suite of software? That's several days of time compared to snagging a package built for your arcitecture. I don't know about you but I like to use my system instead of watching the results of the latest make -j10 scrolling in a terminal. Honestly, most of your speed will come from kernel options which is an order of magnitude faster to modify and deploy than rolling your own system from scratch, and then having to recompile and patch everything.

Additionally one of the strengths of FreeBSD is that it's an operating system, not just a kernel. It has binary compatibility with Linux and in many cases can run those same things faster than Linux can. Does it make it better than Linux? No. They are both tools which may be tailored to specific purposes - some more easily and capable than others.

Re:Which illustrates what we already knew

[theArtificial]

Rose colored glasses much? You can still run the simple Linux on that ancient capable hardware. The days of spending time formatting a boot disk correctly and getting 24bit color working in X and the gnashing of teeth? I miss that too, oh wait, no I don't. Although I feel you with the kernel compliation issues (i.e. if you know what you're doing it's painless).

Seriously though, what are you missing?

Re:Which illustrates what we already knew

[oursland]

Linux is "more complete" than Gnu is.

You're not even wrong.

Re:Which illustrates what we already knew

[Runaway1956]

Thank you, I'm glad you noticed.

Have you ever run a Gnu/Hurd machine? Would you care to run a Linux machine without the vaguest hint of HURD on it? I do. Industrial machines loaded with proprietary software do NOT want to rely on anything that Stallman has licensed. That proprietary software runs comfortable with the Linux kernel, and with whatever drivers may have been licensed for that piece of equipment, but they WILL NOT play the GPL2 and GPL3 games with Gnu. Not in this lifetime, and not in the next ten lifetimes.

Re:Which illustrates what we already knew

[armanox]

Actually, I don't miss the old hardware. I miss the simplicity of the software though. I've usually preferred to run "user-friendly" distros over the years (RH since 6.1, Debian, etc), but I find that the dependencies have gone nuts. Why do I have to have bluetooth installed with GNOME or Evolution (at least w/ 2.x, haven't checked G3)? Same with all kinds of insane font dependencies. Haven't been a fan of network manager. Pulse audio annoyed me when it came out, but has improved since then. Systemctl is my newest pet peeve. I miss having control over my system.

Re:Which illustrates what we already knew

[GeekBoy]

I'm running SC2 on Ubuntu with an NVidia card with all the settings max'd out and it runs just as fast as on windows. There are known issues with the ATI drivers under Linux and SC2. Actually the ATI drivers are not the greatest on Linux to begin with.

Re:Which illustrates what we already knew

[LordLimecat]

I also noted "for certain values of stellar". In this case, the value of "stellar" was "terrible".

It was an attempt at humor / sarcasm.

Re:Which illustrates what we already knew

[GeekBoy]

Differences in the OS's may account for much of the difference. IIRC it was Phoronix that posted a graphics benchmark that showed that 3d games on linux were faster when run under KDE than Unity or GNOME3 (which was the slowest.) Also, differences in X,gcc/glib could also account. Don't assume that newer is faster. Often times it's not.

Re:Which illustrates what we already knew

[sabt-pestnu]

Download the Ubuntu kernel: Free

Download the Gentoo kernel: Still free.

Identify the portions of the kernel that are "bloat": Very expensive (in time, or prior knowledge, or consultation fees).

End up with a lightning fast Linux install that has zero incompatibilities with your hardware and applications: Priceless

Re:Which illustrates what we already knew

[theArtificial]

Thanks for the clarification. In the late 90s I recall one of my friends was installing Redhat (5.1?) and I had no idea what it was about (It doesn't do XYZ, why do you want that!?). Later I saw the light and took the plunge, I decided to cut my teeth on FreeBSD (which I had a hell of a time learning) and after a frustrating while I did my best to forget about it. Later I tried Redhat Linux (8? this was 2002ish) and I was hooked. I did the whole xbox linux thing which reminds me, I've still got a copy which runs on the Dreamcast! I was really impressed with how flexible it was/is. I jumped back on the FreeBSD bandwagon and have been running it to this day. OpenSUSE is my recommendation for people who are curious about Linux. I completely agree with the software side of things.

Re:Which illustrates what we already knew

[X0563511]

Oh. Whoosh. Sorry about that!

Re:Which illustrates what we already knew

[s4nt]

Haha. So, you've obviously tried it, with repeated, positive results? The kernel ABI is pretty much irrelevant. Good luck getting an app from 1998 to run without setting everything else up (essentially a chroot environment for it).

quake 3 is from 1999 and still runs fine on my modern linux distros...

Re:Which illustrates what we already knew

[marcovje]

It's another area where FreeBSD leads the Linux pack :-)

DeGNUification.

FreeBSD 9.0 will have Clang as system compiler

Re:Which illustrates what we already knew

[theArtificial]

You do know that you can carry on working while the system compiles don't you?

Yes, although running a live CD vs an installed system are two separate things performance wise. I'm referring to a workstation, not a fileserver or a router which do not require beefy hardware. It depends what type of work you're doing. If you're doing something like rendering, or graphics work the hits the the CPU, RAM and disk are very noticeable. Yes one could set the nice flag but honestly.... why? I want it done as fast as possible which means using as many resources as I can throw at the compilation job. Also it's not a good idea to update stuff while you're running it. Do you do that with x and dependencies? Sounds like a great way to hang the system - but it's cool since your fileserver (of rainbow tables?) users won't notice. Also, I (much like you) have multiple machines, however I have them for getting specific shit done.

Instaling from nothing on my new file server too a little over a 25 hours to build a complete KDE 4.6 system from a live Knoppix CD

Cool. For a fraction of that time I can have one installed from packages and copy over my seed files (configs) and run an update to make sure I've got the latest and greatest release. Different strokes for different folks though. I bet you like to wait in line when a game comes out too (not my idea of fun) and there is nothing wrong with that.

FYI the system is an AMD64x2 4000 with 4GB RAM, an 80MB SATA drive for the OS and 5.4TB Zpool using fuse-ZFS.

80MB SATA drive, hosting a BBS? ;)

Compiling is a negligable bit of efffort.

But not negligible as far as CPU, RAM and disk to some extent are concerned. If it was I imagine distributions would abandon packages. Also, many people don't want to have to deal with compiling anything...

I can now have 4 instances of RTGEN

DrQueue

Making it deployable is a bit trickier. It involves a script and ensuring the network connection to the new box can be saturated for 4 hours or so. After the fact involves having to rebuild the kernel, but I couldstay with an all encompassing kernel ala regular distros. It may not be as uber as the ricers want it to be, but it amuses the hell out of me.

Making what deployable? If your hardware is the same from machine to machine there is no trickiness involved as far as the kernel is concerned. Keep a vanilla one around for any trickiness...

Re:Which illustrates what we already knew

[F.Ultra]

If you really read the TFA you would have seen that they actually run the tests on borh rigs, that is why there are two separate bars for each system on the results pages... However what probably is the difference is KDE vs Compiz since the BSD (which runs KDE) numbers vs Ubuntu (who runs Compiz) is showing the exact same numers as when Phoronix tested KDE vs Compiz with Nvidia. Imagine that...

Re:Which illustrates what we already knew

[styrotech]

Linux was meant to be cross-platform from the start.

Not so. Linux at first was hard coded for the 386. Its cross platform capability came later.

Re:Which illustrates what we already knew

[WorBlux]

Both PC_BSD and ubuntu use i686 optimizations, and not many programs utilize sse. (mainly just audio/video that i've found). Even so there is room for some optimization, especially with more minimalistic eviroments where you can pull things you don't use our via the use flags, and by cutomizing the kernel, and removing option that generally are only useful for debugging.

Re:Which illustrates what we already knew

[sabt-pestnu]

"stellar" meaning, in this case, "to be thrown into a star at the earliest opportunity".

Re:Which illustrates what we already knew

[Jonner]

Linux has lost its way.

It was once lean and fast but now is an industrialized bloated mess. It will take a lot more to get me to stop using Linux but that doesn't mean I can't see when something is wrong.

Lately, we have been seeing a lot of Linux's advantages fade away. Among these are its smallness and compatibility with older hardware.

I think it's just about time to revisit what made Linux great and see if there is a way to get that back while still doing great new things.

Both the original article and the above are gigantic trolls. There is no attempt to analyze deeply enough to determine which component(s) result in the performance differences. Both the FreeBSD and Linux kernels are mature and optimized enough that such large differences can't be attributed to solely the kernels. It seems the confusion about the difference between Linux and GNU/Linux-based operating systems persists. Since it's all about 3D games, I'm sure the primary differences lie in either the Nvidia driver, which is proprietary and not part of any specific operating system, or X11 components such as window managers. Of course the Nvidia driver is mostly the same between Linux, Windows, and FreeBSD so significant performance differences would have to be in its connection to the rest of the system.

Re:Which illustrates what we already knew

[lordmetroid]

With the popularity of Android, separating the two by using GNU/Linux and Android/Linux seems to be very sensible now. GNU/Linux is truly a free operating system and tools while Android/Linux may share the free kernel, the rest of the system is closed down. For example, I would be glad if I could purchase a tablet PC that I can install GNU/Linux on. However sad as it may be, all tablets are closed down Android/Linux.

Re:Which illustrates what we already knew

[Bengie]

Vista/7 remaps OpenGL calls to DX10/11. Part of the reason why it runs slower.

Re:Which illustrates what we already knew

[dudpixel]

whilst I agree that ubuntu doesn't represent linux for performance, I'd be very surprised if any other distros except the recompile-everything ones perform that much better.

When I hear people complain of bloat, it usually means they dont understand how software works. The ONLY bloat that could possibly slow things down is either more layers of abstraction (which Ubuntu doesn't do) or more things running in the background.

The fact is though, that Ubuntu's software stack is nearly identical to that of fedora, opensuse, and any other mainstream distro.

Maybe they run more services by default, I dont know. But if they're running the same kernel, the same desktop, and the same graphics driver, I cant see how Ubuntu would be that much different to any other distro with respect to performance.

Phoronix probably even has hard numbers to back this up, since they do this kind of stuff - but I haven't looked.

Re:Which illustrates what we already knew

[dudpixel]

actually i forgot about unity - yes that part is different to the others. and it could well be the culprit here.

they should've used kubuntu...

Re:Which illustrates what we already knew

[smash]

Just because the kernel is 30 meg, it doesn't mean that execution is running through all the unused drivers at runtime. an additional 27mb of ram on a machine with 1gb (or more) is such a piss in the ocean (as far as application speed is concerned) it is not worth worrying about. I suspect the vast majority of any speedup you'll be getting with custom kernels is for optimizations related to your CPU type.

Re:Which illustrates what we already knew

[smash]

More importantly for me, freebsd has always (since i started playing with it vs linux in about 1999) been far more resilient under load.

Load a Linux machine up past a load of say 4 on a single cpu machine and things used to get rather unresponsive. Do the same on FreeBSD and you can have loads of 10 or 15 with less appreciable drop in responsiveness. Sure tasks may take longer to run, but the system still responds to user input, sound doesn't click or stutter, etc.

I haven't stress tested a Linux box in a few years, so I'm not sure if the same holds true, but the scheduler shenannigans of a few years back were caused by this exact issue.

Re:Which illustrates what we already knew

[smash]

Pretty much this. I've been burned by shit in linux like NIC drivers swapping load order, and turning my outside interface into my inside and vice versa on a kernel upgrade. This sort of shit just doesn't need to happen.

*BSD has its issues also, however I will make this comment to any Linux users who are considering testing *BSD and scared of learning new stuff.: I started in 1999 and stuff in the FreeBSD handbook that was valid back then mostly holds true today.

There are many changes going on in the OS behind the scenes, but as far as the user is concerned once you DO learn the BSD way, you very rarely need to un-learn and re-learn stuff due to random changes.

Re:Which illustrates what we already knew

[smash]

If you don't have the skills (and even if you do) it is likely cheaper to upgrade your unsupported hardware than pay for the developer to maintain the code. Or spend your own time doing so. To use the example of video cards (recent 3dfx hardware support drop) - you can buy a 3d card that will outperform the voodoo2 these days for about $50 or less. If you value your free time at even a rate as low as $5/hr, you're still going to be far better off just stumping up for new hardware than attempting to carry prehistoric gear into the 21st century.

Re:Which illustrates what we already knew

[smash]

More importantly: if you compile your own stuff from source, random crashes in the OS fall on your shoulders to sort out. Is it flaky hardware? Is it a misconfigured kernel option? Is it some library you linked to incorrectly when compiling the kernel? Is it a wierd compiler bug in your particular version of GCC? Who knows?

Use a generic kernel and if the 100,000 or more other users out there using the same kernel aren't seeing any issues, then you know your hardware may be suspect.

So its a choice - is that extra 10% (or typically LESS) in terms of FPS worth dropping easy ability to verify whether or not issues you may encounter are your own doing with software vs hardware issues?

Re:Which illustrates what we already knew

[oursland]

The Linux kernel is GPL2. Unless you're talking about some other Linux, you're incorrect.

Re:Which illustrates what we already knew

[theArtificial]

Why spend your time doing involved software configurations when hardware upgrades like CPU / RAM / disks (or tuning - memory timings etc.) may be implmented to provide extra horse power with less effort?

More importantly: if you compile your own stuff from source, random crashes in the OS fall on your shoulders to sort out. Is it flaky hardware? Is it a misconfigured kernel option? Is it some library you linked to incorrectly when compiling the kernel? Is it a wierd compiler bug in your particular version of GCC? Who knows?

Or the dependency which fails to compile due to a broken commit or port's failed make configure! When I had more free time to invest into this process it wasn't a big deal exploring and solving (I like to know why something happened to prevent it in the future), however time has a way of becoming a luxury.

Use a generic kernel and if the 100,000 or more other users out there using the same kernel aren't seeing any issues, then you know your hardware may be suspect.

Quite right. If memory footprint instead of only speed is the objective both Linux and FreeBSD support on-the-fly kernel module loading. If it's a matter of adding functionality kernel modules are an easily accessible method providing on demand support. Instead of adding exotic support strip the kernel device probing and chipset support down to your known configuration profile and when the need arises load the appropriate modules at runtime (or via the loader prior to the kernel and disable as needed). This flexibility has one drawback of fragmenting the kernel memory and introducing slight performance penalty.

Re:Which illustrates what we already knew

[gullevek]

Using gentoo as counter example is kind of not-smart. Who in his right mind want to waste days for just compiling everything. Not even FreeBSD does that anymore.

Re:Which illustrates what we already knew

[BitZtream]

Linux has lost its way.

It was once lean and fast but now is an industrialized bloated mess. It will take a lot more to get me to stop using Linux but that doesn't mean I can't see when something is wrong.

FreeBSD's emulation layer has ALWAYS been performing Linux emulation at between 98 and 102% of that on Linux.

Its not that Linux is slower, its that its different. The tests run here take advantage of things FreeBSD does faster, but there are things that Linux runs faster, which is why sometimes its a tad slower, and othertimes its a tad faster

The emulation layer is more or less a syscall mutator and some patched up libraries, its not really DOING anything that would cause it to be slower, its just a small shim that basically reorders some syscall arguments and reorders them to match up with how FBSD does it. We're talking about very very tiny wrappers making this all work.

I'm a huge FreeBSD fan, and particularly hate Linux fanboys/zealots, but this is one area where there is only room for debate if you're too ignorant to realize the way the FreeBSD emulation layer performs is right on target for good solid code. Both being open source, Linux and FBSD SHOULDN'T PERFORM THAT MUCH DIFFERENTLY as they are both general purpose OSes.

Want fast networking, you use FreeBSD, you want wider support for fringe hardware, use Linux. Last I looked, Linux had the SMP side pretty much locked down away as the winner too.

There is nothing wrong with Linux based on this study that wasn't wrong in 1996, because the emulation layer performance hasn't really changed overall since then (which is when I had my first experience with it). Considering how long the performance has been more or less the same, and I know FreeBSD isn't 'bloated' considering it powers some of the fastest packet analazysis machines on the planet, I'd say that its unlikely Linux could be called bloated.

I could easily change this benchmark in a few subtle ways and throw it the complete other direction. I don't know exactly what they did (they didn't say) but my experience tells me that they just happen to hit the upper side of the emulation layer and not the bottom side.

What you should take away from this however is that you can emulate most things in FreeBSD that will run in Linux and you won't notice a speed difference, should you need to migrate away from Linux for some reason, like faster packet switching or something along those lines.

Re:Which illustrates what we already knew

[ByOhTek]

That was in response to asking if he should try FreeBSD. Unless you are using a 9800 or lower, an ATI card probably won't work well. You might pass woth an X1k or an X2k, but I'm not so sure on that. Anything from the X lines and up is going to be better under Linux.

Re:Which illustrates what we already knew

[ByOhTek]

I've tried with a 7300(SE?) in FreeBSD6.x, 8600(GT[x]?) in 7.x and 470GTX in 8.x and some integrated thing for a Phenom II in bot 7.x and 8.x - the drivers have work splendidly even on high resoultions. I was running wow on the 7300 in a 1280x1024 window on a 1080p screen, maxed out with the rendering distance increased in the config.wtf increased to about 1.5x the max I could set it in the GUI. outside of Dalaran, it gave me 40FPS or better.

FreeBSD has no troubles with nvidia cards, as far as I can tell.

Re:Which illustrates what we already knew

[ByOhTek]

I'm running SC2 on Ubuntu with an NVidia card with all the settings max'd out and it runs just as fast as on windows. There are known issues with the ATI drivers under Linux and SC2. Actually the ATI drivers are not the greatest on any platform to begin with.

FTFY

Re:Which illustrates what we already knew

[tibit]

That was a reasonably rare example of a mostly self-contained app -- by necessity. Otherwise it wouldn't run on many systems even when it was released. Most linux distros really push the model where you either take all the dependencies with you, or you compile for their libraries. Zimbra, for example, includes its own java, postfix, clamav, openldap, and so on. Otherwise they'd have to compile and test with a bunch of different distros. Of course the downside is that if a distro pushes a security update to some library before Zimbra releases the same, you're on your own. So yes, if you take very deliberate steps to make it run on many systems, it will run. For Quake 3 the bloat isn't as important, I guess, and security fixes are of no issue either.

Re:Which illustrates what we already knew

[swalve]

The point still stands that if one OS can run a foreign executable on the same hardware faster than the native OS, then something is the matter with the original OS.

Re:Which illustrates what we already knew

[Runaway1956]

That's kind of my point - Gnu is moving to GPL3 - Linux is not. Perhaps I didn't make it clear enough - many proprietary vendors are happy with Linux, but they are not so happy with Gnu. GPL2 is good, GPL3 is not - at least from their point of view. :^)

Re:Which illustrates what we already knew

[TangoMargarine]

yea but the average FreeBSD distribution is lot more optimized than the average bloated linux distro such as Ubuntu.

As stated above, this is PC-BSD, which is a desktop variant, not one of the ones optimized for speed, security, etc., etc., so the comparison is relatively fair.

Re:Which illustrates what we already knew

[bluefoxlucid]

If your statement is true, then it is also true that if the OS can run a native executable built for itself faster than another OS running that same executable (this time foreign), something is wrong with the OS running the foreign executable. It really shouldn't be slower.

Re:Which illustrates what we already knew

[qxcv]

Days is a bit of an exaggeration. Doing a fresh Gentoo install on commodity hardware (including configuration time) shouldn't take more than 4-5 hours to get from stage3 tarball to running Xorg. And that's assuming that you don't automate the process to make it faster for yourself. On older hardware - and particularly laptops - it will take a lot longer, but most Linux users I know have a neat binary distro on the lappies like Arch.

Re:Which illustrates what we already knew

[gullevek]

And on any other distro I can do that in a fraction of time. Gentoo makes really no sense in real production environments.

Interesting benchmarks, but not an article

[drinkypoo]

It's just a bunch of benchmarks with commentary and no conclusion.

Could we possibly get ANY information on WHY?

Re:Interesting benchmarks, but not an article

[kestasjk]

Something to do with the benchmarks comparing OSes on two different systems?

Re:Interesting benchmarks, but not an article

[drinkypoo]

More likely this benchmarks measure performance between closed source Nvidia drivers on Linux and variants for PCBSD.

I don't disagree with you, but it seems like if they were going to go to all the trouble to run all these benchmarks, they could have gone to a little more trouble to figure out how to see whether the system was spending more time in the game, the graphics driver, or the kernel. This ought to be fairly easy to measure on both systems. We haven't learned anything useful, and someone is going to have to go do all this over again while gathering the data they should have gathered.

Re:Interesting benchmarks, but not an article

[macshit]

It's just a bunch of benchmarks with commentary and no conclusion.

Could we possibly get ANY information on WHY?

Phoronix has a lonnnnng history of really crappy benchmarking...

Re:Interesting benchmarks, but not an article

[ByOhTek]

Which is nice, if you are used to reading sites where the conclusion didn't match the benchmarks (I noticed this with Toms Hardware a few years ago, before I stopped reading them, dunno if this has been remedied).

Re:Interesting benchmarks, but not an article

[ByOhTek]

Actually, from what I've read, the closed source NV driver for FreeBSD (and hence, PCBSD) is not much modified from the Linux driver, just a few modifications to the kernel interface to make it work.

Re:Interesting benchmarks, but not an article

[ByOhTek]

Addendum, in fact, one of the reasons they took so long to get it out on AMD64/FreeBSD is because they wanted FreeBSD to support some memory mapping functions that were in Linux, to make porting it easier.

Re:Interesting benchmarks, but not an article

[maxwell demon]

It's just a bunch of benchmarks with commentary and no conclusion.

Could we possibly get ANY information on WHY?

Because it would have been more work to do this, but probably wouldn't have significantly changed the number of readers, especially not of the type of readers who are likely to click on ads. And if there happens to be enough demand, they can still make a followup with more detailed analysis, and get extra ad revenue for that.

Re:Interesting benchmarks, but not an article

[Galactic Dominator]

Read the article, it was the same system. OS's identify things differently and there was no attempt at standardization.

Re:Interesting benchmarks, but not an article

[bonch]

You need to RTFA. It was the same system.

Re:Interesting benchmarks, but not an article

[bonch]

Why the hell should KDE or Unity affect the performance of the 3D game you're running? That's pretty embarrassing for OSS desktop projects if so, and it also doesn't affect the conclusion--that a user running PC-BSD will get better performance than if they run Ubuntu.

Phoronix "benchmarks"

[Anonymous Coward]

I don't see why anyone would treat these guys seriously.

He just produces any content he can think of that's controversial and will get him page hits.

Re:Phoronix "benchmarks"

[bonch]

I can't help but suspect you believe that because you don't like the conclusion, not because of any opposing evidence or criticism of the methodology--otherwise, you would have posted it.

Re:Phoronix "benchmarks"

[Ant P.]

How about it's invalid because they used A DIFFERENT COMPUTER FOR EACH OS.

Re:Phoronix "benchmarks"

[rjstanford]

That would be a very good point... if it were true. Its not, unfortunately for your declaration, but it most certainly would have been.

Re:Phoronix "benchmarks"

[Ant P.]

Okay, disregarding the fact that Phoronix's customarily-misleading data makes it look like two separate sets of motherboards, sound cards and hard disks were used, how is this in any way a valid comparison when every single piece of userspace software between the apps and kernel they're supposed to be benchmarking is different?

Re:Phoronix "benchmarks"

[0ld_d0g]

Oh cmon.. they are benchmarking different operating systems. Whats so weird? Just like Linux vs OSX vs Windows vs BSD. The point is just to see how a default install (aka the majority of installs) holds up against another default install.

Ubuntu the best choice?

[unixisc]

Is Ubuntu the fastest of Linuxes for this to have been done using them as a comparison? Also, were the PC-BSD and Ubuntu using the same DEs? What were the other variables?

Re:Ubuntu the best choice?

[woodsbury]

Though the table has what I assume is the section detailing the x86_64 machines cut off, the two systems are running two different DEs. And two different versions of X. Also have different amounts of RAM, different sized HDDs, different motherboards, and are using different file systems. Not that those last things will have as much of an effect on the benchmark I don't imagine, but it desperately raises the question why they didn't just dual boot Ubuntu and PC-BSD on the same machine...

Re:Ubuntu the best choice?

[ByOhTek]

Different sized HDD can have a bit of an effect (larger does tend to have higher throughput). Motherboards can also have a decent effect depending on how they are tweaked by the manufacturer. The file system is irrelevant because availability general varies between OSes, for each, pick either the standard or the fastest available, that the OS can support, rather than focusing on the same.

Compiz

[jonsmirl]

This is likely caused by Compiz interacting with the game engine on Ubuntu. Turn Compiz off and re-run the benchmarks.

Re:Compiz

[Mysticalfruit]

I'm not saying that these benchmarks are bunk, I'd just like to see these same benchmarks with Gentoo/Fedora/etc.
It's been my experience that while the user experience of Ubuntu is generally good, they turn on every bell/whistle.

Give me a cut down box running xfce any day.

Re:Compiz

[Anonymous Coward]

Upmod this. Compare Kubuntu to Debian/kFreeBSD with KDE to PC-BSD, not apples to oranges.

Re:Compiz

[DrXym]

Unless Ubuntu uses some screwy scheduler, or has some nasty process in the background stealing CPU, it's likely that any performance issues are nothing with the kernel in the first place. It seems more likely that it would be display related, especially window manager / X11 related. That would be especially true if the window manager is compositing surfaces and therefore taking chunks of the GPU's memory, or other resources.

Re:Compiz

[renoX]

> This is likely caused by Compiz interacting with the game engine on Ubuntu. Turn Compiz off and re-run the benchmarks.

True, but if you do this, you couldn't have the outrageous tittle, which would mean fewer ads served and less money: cannot have this on Phoronix!

Re:Compiz

[bonch]

How is that "likely" at all?

Re:Compiz

[bonch]

With all due respect, it's only an "outrageous" title to Linux fanboys. What is outrageous about BSD outperforming Linux in something? Is Linux infallible?

Whenever a benchmark or study is posted that Slashdotters don't like, the comments section is basically a bunch of people looking for reasons to dismiss it until they hit something that gets +5. First it was "the hardware is different," but people pointed out that it's the same hardware. Now, it's the fault of Compiz. There's always something.

Re:Compiz

[jonsmirl]

Because there are two 3D app contending for the hardware on Ubuntu and only one on the BSD system. Two apps cause locking and task swapping delays.

Re:Compiz

[rjstanford]

Outrageous because the setup is too different, if you really want to compare the performance of the kernel using the same desktop would be a good start, no?

If however you really want to compare the performance of the distribution, however, especially as used by "normal" users (who are playing 3D games, not running warehouses, on their l33t b0x3n), then this approach makes perfect sense.

Re:Compiz

[dudpixel]

If you have to modify either system to get it to work better, then what's the point of the benchmark?

Re:Compiz

[renoX]

The approach make sense, ok, but then the tittle should be '3D games run faster on PC-BSD than on Ubuntu'.
It *could be* a Linux kernel issue sure, but it's much more probably linked to Gnome/Compiz/Ubuntu than to the Linux kernel itself..

Re:Compiz

[BitZtream]

So you're arguing over which part of Linux is the problem and saying that its not a Linux problem because its not one particular bit of the system?

Heres a hint, the Linux kernel, alone, is worthless. It requires a system to go alone with it to be useful, so stop trying to pretend that Linux can be narrowed down to JUST THE KERNEL. If you want to go that route then you have to stop claiming Linux capable of doing anything, as I said, on its own, its worthless. Can't even boot without help on a PC.

But you don't want to look at the Linux kernel that way, you want to say its awesome when it is winning BECAUSE ITS THE KERNEL!!!! but its not bad when its losing because ... its something OTHER THAN THE KERNEL!!!!

You don't get to keep your cake and eat it too.

Re:Compiz

[BitZtream]

That would be a flaw with the system.

That flaw makes it slower.

You don't get to optionally pretend such flaws don't exist in order to not be the loser.

For instance:

If FreeBSD didn't have to deal with managing the VM, swap, disk IO can memory bandwidth, it would outperform every other OS on the planet!$!@.

Which is true ... except it wouldn't be very useful, and so probably not actually true in any meaningful way.

Of course, my other response is ... WTF is wrong with your system if applications which aren't being displayed and are running in the background are consuming 3d hardware rather than being idled? The proper thing to happen would be that the background 3d application gets little to no resources and doesn't cause a problem, does the Linux scheduler not deal with this problem or are you guys still running around arguing over which one of the 3 that perform almost identically should be the default.

Even Windows deals with the situation gracefully for fucks sake.

Re:Compiz

[renoX]

> So you're arguing over which part of Linux is the problem

No, Linux is the kernel, so there is no 'part of Linux'.

Yet, the Phoronix tittle talks about 'Linux 3D applications' implying that this is true for every Linux distribution but with another Linux distribution in the same desktop configuration as PC-BSD, it is likely that the 3D applications would have the same performance.

So, it is not a Linux kernel problem, it is a distribution-related problem, a very different type of issue..

Would want to see something other then Ubuntu

[Maquis196]

I find Ubuntu weighed down compared to others. Obviously purely anecdotal, but Debian seems much quicker and Gentoo (what I use) feels quicker even more so. BSD vs Gentoo would be a fairer fight.

Yes yes, I know after youve been compiling Gentoo for days it would be slower, but you cant argue against a cut to the bone system that Gentoo can provide. (which Ubuntu is anything but)

Re:Would want to see something other then Ubuntu

[Zancarius]

I find Ubuntu weighed down compared to others. Obviously purely anecdotal, but Debian seems much quicker and Gentoo (what I use) feels quicker even more so. BSD vs Gentoo would be a fairer fight.

Yes yes, I know after youve been compiling Gentoo for days it would be slower, but you cant argue against a cut to the bone system that Gentoo can provide. (which Ubuntu is anything but)

I have to agree. I played WoW on Gentoo for years, and in some cases the load times were noticeably reduced. Of course, it may have been due to the hardware I was using at the time, the lack of RAM, and Linux's generally faster behavior with swap compared to (at the time) WinXP. After I built a new box, I shifted more toward playing under Windows, although I do admit that the experience under Gentoo was either the same or somewhat superior to WinXP for games that would work well under Wine (or natively). I can't say for sure what it's like now; I rarely play games, and when I do, it's usually casual one-off games that I can kill a half hour with, or maybe trash the occasional evening (with frequent pauses!).

I do love Gentoo, but I've found myself becoming increasingly more fond of Arch once I figured my way around its eccentricities. In some ways, it's much more bare bones than Gentoo for better or for worse, and I think it would also be a pretty fair competitor with the *BSDs. Consequently, I find Arch to be much more BSD-like, particularly since it does even less for you than Gentoo does, and the init scripts are so basic that most obnoxious issues can be fixed pretty quickly since there's fewer layers of indirection.

That said, Gentoo's net configuration is by far the best I've encountered.

Re:Would want to see something other then Ubuntu

[bonch]

If you have to compile your entire operating system to get performance that's competitive with a pre-built package-based distribution, there's a problem.

Re:Interesting ways of benchmarking

[ludwigf]

So it's a benchmark on different hardware that happen to use the same nvidia card (but different motherboard and CPU), and different versions of the compiler, which are known to have performance differences. Way to go.

Looking at the posted specs its looks like the same cpu (AMD Phenom II X3 710) for all tests - on a different motherboard though - wonder why...

History, apparently, repeats

[gbr]

Didn't this happen when Linux started emulating Windows?

"Games run faster in Linux/Wine(Cedega) than in Windows"

http://www.phoronix.com/scan.php?page=article&item=681&num=2

Why is everyone so shocked that an emulation layer can be faster now, when before it was "look at us, we're great?"

Re:History, apparently, repeats

[maxwell demon]

So to get maximal performance, one should run Windows games over Wine on the Linux emulation of BSD. :-)

Re:History, apparently, repeats

[bonch]

Why is everyone so shocked that an emulation layer can be faster now, when before it was "look at us, we're great?"

Because, unlike the benchmark you linked, Linux is on the losing end of this one, so it simply must be wrong or inaccurate according to Slashdot.

BSD vs Linux

[unixisc]

Doesn't OpenBSD/NetBSD have the portability mechanism whereby it supports all Linux drivers under an abstraction layer? Or is that only in theory, but doesn't actually work?

I have a different question - slightly off-topic: is the TCP/IP stack on BSD faster than Linux? If so, what makes it faster?

Re:BSD vs Linux

[ByOhTek]

There is something similar to that in FreeBSD also, I believe.

And if you expect that to work reliably for a large number of drivers, I have a bridge between two mountains in Kansas, with a nice ocean view, that I'd love to sell you, cheap!

That being said, outside of the latest soundcards (occasionally), ATI graphics cards, and video cameras and wireless, the driver support isn't too bad. The wireless driver support may be ok, I've just never managed to figure out how to set it up...

How about Debian: Linux vs kFreeBSD

[unixisc]

How about running this test on a distro that does both Linux and BSD, and then compare? Take Debian, take their latest releases of Linux and kFreeBSD, use the same DE from Debian's sources and the same software for both. Then run the whole thing - either on the same machine, or on 2 identical machines.

Then tell us about it

Re:How about Debian: Linux vs kFreeBSD

[laffer1]

That would fairly test kernels, but not user land. As long as it was taken into account some GNU utilities are tuned for Linux, I think it would be OK to do this. You couldn't say anything but here's a comparison of kernel performance. it would not be a benchmark of FreeBSD as FreeBSD is the kernel + user land.

Re:How about Debian: Linux vs kFreeBSD

[BitZtream]

Because FreeBSD is NOT A KERNEL, its a system.

FreeBSD is an entire system, as is PC-BSD. It is not JUST a kernel.

When you use Debian's kFreeBSD, you are not using FreeBSD, you are using Debian, with a FreeBSD kernel. You can't call it FreeBSD any more than you can call it Ubuntu.

Keep in mind, Linux is the only 'OS' on the planet, where people like to pretend that the kernel is the OS and the OS is the kernel. No one else says 'we run the Solaris kernel', or 'We run ntkern.dll'. Its only Linux where you seem to think the kernel is the OS and that the userland isn't part of theOS.

Kernel tests are pointless, as the kernel is worthless on its own. You test the SYSTEM since thats what you'll actually have to use. No one uses the kernel in a void, which means benchmarking just the kernel is useful to no one.

Re:How about Debian: Linux vs kFreeBSD

[unixisc]

I was talking about comparing the kFreeBSD kernel w/ the Linux kernel, and putting the same Debian utilities on top of them for it to be an apples to apples benchmark. I'm not talking about comparing BSD userland to Debian userland - I wanted to verify the original point of the post about the Linux kernel actually being slower than the BSD one. Besides, if I run something like KDE over a FreeBSD kernel, how does that make the combination anything other than FreeBSD?

Apples to pineapples comparison

[unixisc]

Unless PC BSD was there on the system w/ less RAM, less HDD, slower file system, and despite that, beat the more richly favored Linux box. I'd excuse not having a dual boot, but how difficult was it to obtain 2 identically configured systems, running one w/ BSD and the other w/ Linux.

But as I note in another sub-thread below, it could have been an absolutely even playing field w/ Debian Linux vs kFreeBSD.

Not a good test.

[Junta]

The test was insufficient to actually conclude anything of value. They used two *different* systems instead of reinstalling (specs looked *close*, but they weren't the same). They used KDE vs. Unity (this by itself explains the discrepancy, it's widely been shown unity degrades full screen 3d performance). It compared only one version of one distribution to one version of one variant of BSD. It only compared the nVidia driver, though there is no choice on that front.

"Unity slower than KDE" is a more likely conclusion, but again, you'd need a more controlled test to say anything. Phoronix should be ashamed...

Re:Not a good test.

[complete loony]

Phoronix should be ashamed...

That goes without saying though.

Re:Not a good test.

[mcover]

Amen. Mod parent up. Though on the other hand, it's perfect propaganda for PC-BSD/FreeBSD; so well done to that.

Re:Not a good test.

[Formorian]

As soon as I read it's by Phoronix I disregarded it.

Re:Not a good test.

[Galactic Dominator]

Read the article it's the same system.

Re:Not a good test.

[F.Ultra]

And interestingly enough, KDE vs Unity on Nvidia shows the same numbers as BSD vs Ubuntu did: http://phoronix.com/forums/showthread.php?60243-FreeBSD-A-Faster-Platform-For-Linux-Gaming-Than-Linux&p=226522#post226522
So this is simply Nvidia having regressions on Unity/Gnome but not with KDE.

Re:Not a good test.

[dudpixel]

More like "ubuntu is slower than PC-BSD ". Pretty close to what you suggested but I'm sure you could compare unity to KDE on a completely different system with different linux distros and get different results.

Re:Not a good test.

[Galactic Dominator]

And came to post on it.

Re:Surprising?

[unixisc]

How?

Emulation, Really??

[Wattos]

Since when is Wine doing any emulation? Since when is linux emulating? Did you forget what Wine stands for? "Wine is not an emulator.

It is simply implementing the Window Api calls.

Re:Emulation, Really??

[TeknoHog]

Did you forget what Wine stands for? "Wine is not an emulator.

I've never understood why Wine is singled out as the non-emulator. For example, Dosemu is not really an emulator, it simply implements the particular programming interface.

At some point, code will run natively on the machine. IMHO, the more layers of abstraction and/or translation you need to traverse, the more it makes sense to say "emulation", but there is no clearly defined line. Abstractions are used with "native" applications all the time.

Sometimes I'm told that emulation involves translation between machine architectures. Well, there is hardware for running Java, so why don't we call Java runtime an emulator? Even architectures like x86 are not strictly hardware or software. Current CPUs have some funky RISC at heart, and they merely provide an x86 programming interface. Or do they emulate it? Same difference.

This has been my pet peeve for years, but recently I have given it a little more thought, since starting FPGA development. FPGA hackers like to say that they do not emulate old hardware, they actually implement the real thing. But it is still emulation in the strictest non-computing sense. Of course, having actual parallel circuits instead of running it on one CPU is much closer to the real thing.

Re:Emulation, Really??

[angel'o'sphere]

Emulator: a hard and/or software that "simulates" another hardware. Like an Apple ][ emulator on a PC or a Mac. In other words, before there was an emulator there once existed "the real thing".
Emulating often involves ersatz devices for parts of the original machine, like 40x24 text window as display for the Apple ][ and artificial 5.25" floppy disk drives which are mapped to files on the real machine.

It is also called emulation when only a differen processor architecture is emulated, like when Apple shifted from 68kXX processors to PowerPC and again later to Intel x86. In both cases old software was kept running by having a an emulation layer in Mac OS (X).

Virtual Machine as in the sense of the UCSD System, Smalltalk or Java: a simulated artificial machine. In other words there is no preexisting hardware/OS after which it is moddeled. That does not exclude the existance of UCSD bytecode processors or JVM bytecode processors (but usually they came after the VM ... and keep in mind, a processor is not a "System")

Wine on the other hand is a set of orginal MS windows libraries glued together by "Wine" to allow a windows program to run on top of those libraries "believeing" it is on Windows. So: obviously here is nothing emulated at all.

Re:Emulation, Really??

[Anonymous Coward]

For example, Dosemu is not really an emulator, it simply implements the particular programming interface.

No it doesn't. DOS is a 16bit environment, you can host a 16bit session on a 32bit OS using the Virtual86 (Windows natively runs DOS apps in this mode) but a 64bit OS can only host 32bit sessions, not 16bit (this is a hardware limitation, AMD was sick of supporting V86 so they broke it). If you want to run 16bit apps on 64bit then you need to interpret the instruction codes manually in software on a software CPU [Microsoft never bothered to write a software emulator for 16bit x86 which is why AMD64 versions of Windows can't run dos apps natively any more, you need to use Dosbox (Disclaimer: They may or may not have written one for Itanium but if they did, I think it was in assembler so it was it never ported to the AMD64 architecture)]

At some point, code will run natively on the machine. IMHO, the more layers of abstraction and/or translation you need to traverse, the more it makes sense to say "emulation", but there is no clearly defined line. Abstractions are used with "native" applications all the time.

I take it that you have never tried to code an emulator, a few hours experience, even with just the design stage, would show how wrong this line of thought is.

Emulation is when code is executed on a software CPU instead of a hardware CPU (when you are executing native code on a sandbox inside the hardware CPU, that is virtualization). Emulation software consists of a program that does something like:
for (;;) {
Instruction *insn = myVirtualCpu.fetchNextInstruction();
insn->executeAndUpdateState(myVirtualCpu);
if (myVirtualCpu.isFrozen())
exit(0);
myScreen.updateDisplayedState(myIoPorts);
myVirtualKeyboard.pollRealKeyboardForUpdates();
}
If you're familiar with CPU literature, you'll recognise this as a fetch-decode-execute loop. Notice specifically that it is a PULL system, the software being run is being pulled by the emulator. Native abstraction layers are PUSH systems, the running program calls into functions provided by the abstraction layer directly.

Sometimes I'm told that emulation involves translation between machine architectures. Well, there is hardware for running Java, so why don't we call Java runtime an emulator?

Java is a Virtual Machine, so yes, the Java Runtime Environment is a software emulator for the imaginary JavaCPU. This explains why it has always been slow, it exists in the same category of software as Project64, Dolphin, etc.

Even architectures like x86 are not strictly hardware or software. Current CPUs have some funky RISC at heart, and they merely provide an x86 programming interface. Or do they emulate it? Same difference.

x86 is weird this way, that is indeed a form of (very shallow) hardware emulation, it translates the x86 ops into native super-wide RISC operations for the pipeline to perform. If you ignore x86 and look at PowerPC or ARM on the other hand, these CPUs don't translate, they perform the operations directly. In any case, hardware emulation is generally not too much of a problem, whilst it does add latency to the pipeline, that merely caps the maximum clock and execution speeds lower than a natively executing CPU could achieve. Software emulators, OTOH, are resource pigs; whilst the x86->RISC hardware can translate any instruction to native instructions in around 1-5 clock cycles, a software emulator will often take hundreds of cycles. You don't need to be a genius to see that 1 emulated instruction to 100 native instructions means that the native CPU is running the emulated CPU at 1% of the native CPU's speed (i.e. 99% of the native CPU's performance is lost to emulation overhead).

What the x86 does natively, as well as most newer Virtual Machines

Re:Emulation, Really??

[TeknoHog]

Thanks for the elaborate reply, the explanation on push vs. pull systems was particularly enlightening. I guess my problem is, in part, the way words like emulate/simulate are used in computing, as opposed to the general meanings.

I also wanted to clarify what I said about FPGAs. I'm a relative newbie to them, but I have a wide experience in electronics, and I think in terms of circuit diagrams (often using them to check how my Verilog turns out). I think I know the basic idea how they work, this is what I was trying to say with "actual parallel circuits". To be pedantic, I wouldn't call programming one "building real silicon" because the actual silicon is not altered, although you do end up with new designs at the circuit level.

I said that the FPGA NES "emulates" a NES, because it works like one, but is not actually one. It is probably not the same even at the circuit level, as some bits are probably reverse engineered, or improved/simplified otherwise. In general language, this can be called emulation, even though it is not performed by running something on a different kind of CPU.

Re:Emulation, Really??

[hedwards]

No, it's correct. Java isn't an emulator, the virtual machine runs byte code using native instructions and from time to time you get problems with that. But, ultimately, the Java VM is more similar to Wine or the Linux ABI than it is virtual box.

Emulation goes beyond just wrapping instructions for use by the kernel, it typically has to create virtual devices or emulate instructions which are not available on the host machine, rather than just wrapping them up in the preferred format.

Re:Emulation, Really??

[TeknoHog]

Emulation goes beyond just wrapping instructions for use by the kernel, it typically has to create virtual devices or emulate instructions which are not available on the host machine, rather than just wrapping them up in the preferred format.

Thanks, this is probably the most compact explanation I've heard so far :)

Re:Emulation, Really??

[TeknoHog]

BTW, I probably wouldn't be developing FPGA accelerators for certain algorithms, if I thought they were being emulated on CPUs. I certainly wouldn't be getting the donations I now get for this project. I appreciate your feedback on emulators, which is not one of my specialities, but seeing such broad assumptions about other things was a bit annoying.

Re:Emulation, Really??

[BitZtream]

You could have just looked it up on dictionary.com rather than taking an arbitrary meaning from some random person on slashdot, whom is wrong, btw.

Interesting.

[DiSKiLLeR]

FreeBSD had always ran Linux binaries faster than Linux. Interesting that this may still be the case.

Point, though, that the 'Linux Emulator' in FreeBSD isn't really an Emulator. FreeBSD runs Linux binaries natively. The so called 'Linux Emulator' just provides Linux syscall capabilities to the FreeBSD kernel.

And of course, Linux libc and other libraries need to be provided (which the linux binary was linked against), and probably linux's /proc is also needed to satisfy various linux binaries. But its by no means an 'emulator', is just provides the services a Linux executable expects.

Re:Interesting.

[zixxt]

FreeBSD had always ran Linux binaries faster than Linux.

Maybe 10 years ago, but not today unless you have some recent benchmarks that say otherwise.

Re:Interesting.

[bonch]

Maybe 10 years ago, but not today unless you have some recent benchmarks that say otherwise.

Psst. You're posting to one.

Re:Interesting.

[Jonner]

FreeBSD had always ran Linux binaries faster than Linux. Interesting that this may still be the case.

Care to back that up with anything?

Re:Interesting.

[BitZtream]

Google it.

But ... by Always, he means sometimes.

FreeBSDs syscall emulation layer for running Linux binaries performs at between 98% and 102% of that on Linux. Its been that way since I switched to FreeBSD from Linux (1996? 7? 2.2, whenever that was). Some apps will run faster, some will run slower. In reality, they'll run in a way that you're just not likely to notice the difference at all.

Who mentioned wine?

[robbak]

Since when was wine used to run linux binaries on BSD?

Still, your point stands. Linux binary compatibility is no more emulation than wine is.

Re:Who mentioned wine?

[BitZtream]

You need to look up the definition of emulation.

And heres a hint, the WINE guys don't actually get to define emulator, as much as they'd like to.

Its a fucking emulator, get over yourselves and your retarded naming schemes.

Now is the time for Hurd

[h2k1]

And 2012 will be the year that the Hurd will reach the Desktop!

Re:Now is the time for Hurd

[maxwell demon]

And 2012 will be the year that the Hurd will reach the Desktop!

December 21, I guess?

Re:Phoronix benchmarks are so frustrating

[Lennie]

And it was different hardware. The CPU and GPU are pretty much the only parts that are the same.

I still don't understand why they didn't run it on the same machine and not dual boot.

Just have a seperate HDD and swap that.

Re:Surprising?

[jellomizer]

FreeBSD is better designed for a particular subset.
Linux has forces trying to make it the OS that does everything. Mobile OS, Desktop OS, Server OS, Mainframe OS, Runs on the Newest Hardware, Runs on the Oldest 32 bit computer that you can find.

FreeBSD has mostly been focused on Workstation/Server usage. Allowing it to use more optimal algorithms then Linux does, for its particular usage. So if a particular algorithm improves performance of a particular common kernel call 4 times faster, and when you are emulating Linux the capture and switch of kernel call request take twice the effort, you are still gaining in performance.

Now Linux may have perfectly good reasons not to implement those calls that FreeBSD does. (gain some extra flexibility, easier to read code, backwards compatibility, found that it is actually works better on different platform, uses less memory...), But for a standard modern desktop/workstation FreeBSD is probably a bit snappier then Linux is. It doesn't mean FreeBSD is always faster then Linux.

I wonder....

[Dcnjoe60]

I wonder what the results would have been on something like debian or arch or fedora? It is well known that Canonical's implementation of linux in Ubuntu is one of the slowest commercial distributions out there. They trade speed for features (or bloat depending on your perspective).

While Ubuntu is probably the most popular distro, which would make it valid to test, that doesn't mean it is representative of linux in general and therefore, the article should be about how 3D gaming is faster on BSD than on Ubuntu, not on Linux -- at least not until there is actual data to support that conclusion.

Re:I wonder....

[JasterBobaMereel]

So comparing the same game running natively on two differently speced systems one running the slowest version of Linux, the other running a fast version of BSD one runs faster than the other ...What a surprise!

Re:I wonder....

[dudpixel]

I wonder what the results would have been on something like debian or arch or fedora? It is well known that Canonical's implementation of linux in Ubuntu is one of the slowest commercial distributions out there. They trade speed for features (or bloat depending on your perspective).

I suspect Unity could be the culprit - they really should've used kubuntu for a more even playing field.

but in any case, the headline should've read "ubuntu" and not "linux"

Useless compalaints, guys!

[aglider]

There's a point here: at the kernel level FreeBSD outperforms Linux.
At least with Linux kernel 2.6.38 (Ubuntu 11.04) and FreeBSD's.
During gaming there's little in use from the distributions themselves. I'd say it's 99.999% kernel stuff (with drivers).

Misleading title

[ilguido]

It should be "Linux 3D Games Run Faster On PC-BSD with KDE than on Ubuntu Linux with Unity, on NVidia hardware". It's worth to note that KDE outperforms every gtk based desktop environment (gnome, unity, lxde...) when running on NVidia hardware.

Control Groups [cgroups]

[wirelesslayers]

Those tests was made using default kernel specs. It would be nice, for comparison, to customize the kernel , and using the awesomeness of CGROUPS: 1 - allocate process into groups with specific memory usage, I/O usage, swapness levels; 2 - exclusive cores for the 3D processes. 3 - higher cpu shares for the 3D processes. All the nice stuff you can do with CGROUPS. One thing is testing the default spec of ubuntu, other is tuning and testing again. Tuning both of the systems to make another benchmark. Not a single mention to cgroups in that benchmark article.

turn EVERYTHING off...

[C0vardeAn0nim0]

some 10 years ago, when even the slightest hiccup could make a game running in linux slow to a crawl (not linux's fault. more like greedy games on average hardware), i ran several tests to find the best settings for performance. here's what i found:

- even a lightwheight window manager like windowmaker, fluxbox or xfce impacts negatively (specially if you're short on RAM)
- any cute widget, dockapp or systray app can take a hit. a simple opengl cpu meter, displaynig a spinning cube, running inside a 64x64 dockapp had a 10% hit on glxgears' frame rate
- daemons started from init.d scripts steal memory, and if they trigger a backgroud process, bye-bye performance. so make sure anything than trigger lots of disk I/O operations are off. specially if they run from cron
- get used to the command line. shut down GDM/KDM/XDM or any other graphical login. log on the console, quickly create an .Xsession file with nothing more than "xterm" on it. as soon as X starts with a windowless xterm, run the game from the CLI.

now, optimize BOTh PC-BSD and linux this way, THEN run a benchmark. otherwise, is the same as trying to compare a default ubuntu with openBSD on which one is more secure. or the other way on which is more usefull as a desktop. it's not right to ebnchmark different OSes by leaving the defaults just like that.

Re:turn EVERYTHING off...

[C0vardeAn0nim0]

yes i am.

and i'll do it better. i'm back to college, on a digital games major. this kind of benchmarks yould make for a great paper to show at college. thanks for the idea man.

maybe i'll pitch it showing how much OS optimizations affect older and newer hardware in diferent ways.

Re:turn EVERYTHING off...

[Rysc]

This isn't what Linux users are expected to do, this is what *benchmarkers* should be doing in order to correctly benchmark the kernel.

Even on Windows it's perfectly common to close background tasks, web browsers, etc.. to eke out better gaming performance for when it really matters. You can just go a lot further, and be a lot more specific, under Linux.

If you want to claim "BSD faster than Linux" then it makes sense to turn off all the things which are not "BSD" and are not "Linux" and could impact the results. The title should be "PC-BSD's default install has fewer background processes eating your CPU, RAM and disk throughput than Ubuntu does!" aka "No shit, Sherlock."

Re:turn EVERYTHING off...

[C0vardeAn0nim0]

then try this in your windows box, shutdown all redundant services, including themes, netbios (seriously, this is 20 year old shit, why it's still there ?), server, computer browser, indexing service, etc. then compare the gaming performance to what it was before.

getting performance out of a machine by tweaking the system is not just for linux.

i'm just glad linux gives me more and better options to tune my machine.

Re:Also, the ocean was found to contain water

[swalve]

If doing more stuff, which emulation and disk encryption is, goes faster, the flaw is in the original version somewhere. Doing more stuff should always be slower.

Re:And maybe also because nvidia-linux kernel wrap

[RobbieThe1st]

Interesting. Do you have a patch-set with all of these improvements handy or something? I'd be interested to see if they make any difference on my quad-core box...

"more" is more important than faster

[sl4shd0rk]

What's needed is more games on linux, not faster ones.

Unity Vs KDE, not BSD Vs Linux....

[Beelzebud]

All this article proves is that KDE is better at turning its OpenGL compositing off before entering a 3D app. This seems like a fairly inflammatory conclusion, based on comparing apples and oranges. Set Linux and BSD up with a lightweight openbox setup, and then benchmark it.... At least have them both using the same DE...

Re:Also, the ocean was found to contain water

[Beelzebud]

I've seen many anecdotes about having games run faster in wine than Windows, but my own personal anecdotes say otherwise. My experience with Wine has been something like this: Game looks like its supposed to, but performance is crap. Game has glitches, but performance is acceptable. At the end of the day it's always way more fiddling than I want to spend with my gaming time. When I want to play games these days, I don't want to be bullshitting around with OS settings for a majority of the time.

Re:Additional layer - not strictly needed

[laffer1]

The linuxolator in FreeBSD is located here:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/

You can actually see how it's implemented.

What games?

[Hognoxious]

I'd like to know which games were in the experiment. Did they use both of them?

Testing the right things here?

[Svartalf]

The big question would be, "Does FreeBSD's environment have Compiz or similar running?"

If you've got that running there's performance concerns, etc. that you have to deal with that make overall performance slower. My guess would be that it's not there- which means you're not making apples to apples comparisons between the OSes. If so, it's not that it's faster...it's that Phoronix didn't do the testing right.

Heh...I was right...

[Svartalf]

He tested this with Ubuntu 11.04 under Unity and FreeBSD with KDE. It's a known that the configuration in Ubuntu there is a fairly massive performance sink on top of the already bad one Compiz can introduce with OpenGL stuff. As some pointed out in Phoronix' forums...all they did was benchmark Compiz/Unity versus KDE for all intents and purposes.

All things being equal, the results should be very similar if you're doing apples-to-apples comparisons since the OSes in question are similar in nature in this specific regard.

Re:Interesting ways of benchmarking

[Galactic Dominator]

It's the same hardware, Linux and BSD identify hardware differently and the author didn't standardize it.

Re:Phoronix benchmarks are so frustrating

[Galactic Dominator]

No it was not different hardware. For some reason the author thought it was a good idea to include per OS identifier string in table format leading to this frequent and grossly mistaken assumption.

Re:Interesting ways of benchmarking

[bonch]

It's the same hardware. Can fanboys not read?

Re:Now try it on Gentoo

[bonch]

People keep bringing up Gentoo. If you have to compile your entire distro from source to get competitive performance, there's a serious problem. Why is it so hard for people to accept that one UNIX flavor might be a little faster at something than another? Are people really that fanboyish about Linux around here?

Phoronix and bias

[bonch]

What's funny is that people are finding any reason they can to dismiss the benchmarks (my favorite is claiming the hardware is different, when it's not).

Meanwhile, nobody seemed to have a problem with Phoronix's previous benchmark showing Wine/Cedega games running faster on Linux than on Windows. The difference now is that Linux is on the losing end of the benchmark, so it simply must be incorrect in some way.

OS bias is a funny and bizarre thing.

Re:Phoronix and bias

[erroneus]

I'm not actually rendering an opinion other than the possibility that this could be used to raise awareness of the problems with general Linux performance.

It is simply not all it could be. It has just become a very large project and I keep hearing about dropping support for processor architectures and specific hardware at every turn and it just makes me a little sad to see one of Linux's advantages erode. Supporting more hardware than any given version of Windows was quite a feather in Linux's cap. While it may still be the case, some things are being dropped and it feels like a tiny amount of betrayal even though I understand the various reasons for that. (such as can't be supported because no one who is developing and supporting code has the hardware to test against any longer.)

IT'S THE SAME HARDWARE

[bonch]

This claim keeps getting repeated, over and over by people who didn't RTFA. IT IS THE SAME HARDWARE. The operating systems report it differently.

As for Phoronix, nobody here seemed to have a problem with their previous benchmark showing Windows games running better on Linux Cedega. Now that Linux is shown to be losing in a benchmark, suddenly there are all these "problems" with the benchmark. This community is so biased.

Re:Phoronix benchmarks are so frustrating

[bonch]

It was not different hardware. For god's sake, would people stop claiming that and just RTFA?

Re:don't even bother with these "benchmarks"

[bonch]

don't waste your time reading that pathetic article. the "benchmarks" were conducted on completely different systems, with different hardware

No, they weren't. Looks like you didn't spend any time reading the article either.

Question...

[MobileTatsu-NJG]

I apologize in advance if this is a dumb question...

Is it possible that the 3D acceleration is running slower because more protections are in place to prevent the system from going kablooey in the event of a driver failure?

I ask (and worry that this is a dumb question) because I've noticed Windows 7 doesn't seem to be as fast with 3D as XP was, but it has proven to be a lot more fault-tolerant. Was just wondering of the discrepancy exists because something similar is going on.

lies, damn lies, and benchmarking in vitro

[epine]

Once upon a time, long long ago, it was perhaps possible to satisfice on the simplifying notion that for the tiny, compact Linux kernel, in vitro benchmarks were an excellent proxy for in vivo performance.

Phoronix did a little bit of work to conduct an in vivo benchmark comparison (as opposed to benchmark analysis, which for in vivo benchmarks is a mountain of work for not necessarily much return).

The sad fact is that for the vast majority of Linux users these days, the crappy in vivo benchmark protocol comes closer to the reality that people experience.

You can almost say that the gold-standard in vitro benchmarks are a better guideline to tweakability than anything else.

The only known cure to what ails any system catering to the multitudes is to ditch the multitudes. That said, not every case of catering to the multitudes is equally bad, witness Windows Ebola with the daily retrovirus cocktail and plenty of bed rest (er, system reboots).

A small group of people banded together thinking we were immune. Sad, really, but entirely viable if you hold every Linux benchmark effort to higher standards than the Surgeon General.

Re:And maybe also because nvidia-linux kernel wrap

[rjstanford]

that might be a noop, or the reason why suspend fails for me.

Ah, Linux.

Well, DUH it's faster

[Khyber]

"most people would expect that an additional abstraction layer would generally slow down the execution of binaries"

Learn how to code better than everyone else and this is a typical result.

Fact: Most Linux programmers are shitty programmers. This is why an abstraction layer ends up running better than native.

Re:Phoronix benchmarks are so frustrating

[rjstanford]

Why not create a more concrete experiment. Strip Linux and FreeBSD down to just a window manager, compare the versions of Xorg, do alternate native 3D benchmarks. Give us something to take seriously. Telling me some games run faster on PC-BSD than they do on Ubuntu isn't giving me a lot to work with.

Probably because most people who want to use their machines to game with casually don't do this, and comparing performance of out-of-the-box distros is actually far more useful for people who wouldn't be able (or interested enough) to just run their own benchmarks?

Linux and GNU-UX

[unixisc]

If one installs just Debian Linux, w/ little or no GNU utilities - no GTK+, noGCC, no GIMP, no Gnome, no Emacs, and instead installs KDE and all its packages, and uses those apps, would you still insist on calling it GNU/Linux?

I really wish the Linux guys get a non GNU version of Wayland on them, and then put KDE4.8 on it. Just run w/ it. I do wish the GNU people a complete system as well, and to that end, I hope they can get HURD running (use Minix 3 instead of GNU Mach for your kernel) and on top of it, whatever they want - GNUSTEP, GTK+, GIMP, and anything else that suits them.

Re:Linux and GNU-UX

[Galactic Dominator]

Excuse me but what do you plan to use for basic userland? KDE has dependencies too, and even BSD systems are indebted to GNU. Although at least in the BSD case true progress has been made remedying that issue.

WINE vs WABI

[unixisc]

So how is WINE different from WABI (Windows Application Binary Interface)? In the latter, Windows systems calls would be interrupted, and substituted w/ Unix system calls

Re:Phoronix benchmarks are so frustrating

[smash]

Why? Do you typically install a modern free unix system to strip down to bare bones in general use? I suspect comparing the operating systems in a state that is either out of the box or in a state that most users will have them installed in is far more relevant than some theoretical best case.

Re:And maybe also because nvidia-linux kernel wrap

[BitZtream]

Hahahah, you have no clue what you're doing, and you think you're making it faster ...

Thats priceless, theres a meme in there somewhere I'm missing.

Don't ask what os_raise_smp_barrier

My guess would be that its an op designed to ensure the CPU cache is flushed to RAM and that all out of order instructions are completed and flushed before continuing so that the contents of RAM actually match up with what they are supposed to be rather than being slightly off due to the processor making on the fly optimizations and reordering memory writes.

And this is why you don't listen to same random fuck on slashdot telling you why nVidia's drivers suck. He's clearly never worked in kernel code, yet is telling us how to get massive speedups!

I presume you have a bunch of nuts and bolts left over after you work on your car too.

Re:Also, the ocean was found to contain water

[BitZtream]

I've also seen reports of people running full disk encryption showing higher read/write speeds in certain cases.

Just for reference, this is almost always related to compression being used.

Now days, there is enough spare CPU most of the time to do compression on the data on the fly while waiting for the disk to read/write some block.

In a 32 bit Windows, with Battlefield 2, you would get FAR faster load times by compressing the BF2 installation directory using NTFS compression because the only thing the CPU is doing during that time is frontending for DMA transfers to/from disk, of massive amounts of data. By compressing them, you move some of the load to the CPU (which is basically idled at this point, so we're not slowing anything else down by using it) and cut down on the physical disk IO that is required.

I say 32 bit windows as I haven't tried it with more than 4 gigs of RAM. More may change it due to better disk caching, less swaping and all that.

Choosing isn't easy...

[ResidentSourcerer]

There are several factors that make pruning the bloat difficult for the average user:

1. Spurious dependencies.
I have on occasion installed a command line utility that called in the entire KDE source tree and did a build world.

2. Lack of documentation. Much of the time there is no good documentation outside of the program in terms of how to use it. You have to install it to test it, then uninstalling reveals that 9 billion things will break

3. Proliferation of libraries. I tell you Linux is getting as bad as windows with it's DLLs.

4. Incompatibility across upgrades. This is the flip side. Do an upgrade, and foo-3.2.11.lib changes the syntax for the bar call compared to foo-3.2.10.lib (of which both on install were symlinked to foo.lib...) Come on guys. Minor revisions should not change syntax.

5. Spurious change at the OS level. My computer is a tool. I use it to get work done. Changes for the sake of eye-candy is anathema. The visible part of a distribution should go unchanged for many years at a time.

6. Security fixes and bug fixes should be segregated from feature changes.

Steve Jobs, when running NeXT commented that people won't change for a 10% improvement. Or even 30%. People *will* change for a 500% improvement.

If you want to sell Linux to the masses:

1. It has to stop interfering with how things work.
2. It has to have good, clean, fast applications that are easy to learn to use, and incredibly stable.

Re:Choosing isn't easy...

[Doc Ruby]

All of those things can be changed simply by an interested user contributing documentation, alternative meta packages, or both.

My point is that Linux isn't just an alternative OS. It's an alternative way of computing: community based. Not distantly based, but really community based. That the large majority of changes to the kernel are made by interested corporations doesn't change the community basis. Those people in those corps are part of the community, and there are plenty of others who are really independents. But in Windows or MacOS there is no such thing.

So whining about how "Linux has lost its way" because of some configuration inadequacies, however real, is just that: whining. If 1% of the whining time were spent documenting, organizing and even coding, Linux would be way better. If people aren't going to be constructive, they should at least shut up.

Phoronix doesn't know what they are benchmarking

[Xaeon]

The benchmark shows the difference between Unity and KDE not Linux and PC-BSD.