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

[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

[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

[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.

Compiz

[jonsmirl]

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

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...

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.

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.