Linux 3D Games Run Faster On PC-BSD 298
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."
Which illustrates what we already knew (Score:4, Insightful)
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: (Score:2, Insightful)
Re:Which illustrates what we already knew (Score:5, Informative)
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: (Score:3)
Re: (Score:3)
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 t
Re: (Score:3)
Same hardware, different renderer, faster on Linux, didn't look much different. Shame I play more than just WoW, really.
Re: (Score:2)
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 mu
Re: (Score:2)
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: (Score:2)
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: (Score:3)
AMD Phenom II 955
nVidia GTX 260
8GB DDR2
FreeBSD 8.2 AMD64, nVidia 275.28 drivers
Re: (Score:2)
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: (Score:2)
I don't think that means what you think it means. You just committed a version of the "could care less" mistake.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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 tak
Re:Which illustrates what we already knew (Score:4, Informative)
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 [blogspot.com], also when compared to other Linux distros.
Re: (Score:2)
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: (Score:2, Interesting)
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 ne
Re: (Score:3)
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: (Score:2)
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: (Score:3)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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 it
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
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. Hel
Re: (Score:2)
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 linu
Re: (Score:2)
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: (Score:2)
A compile-from-source zealot? [funroll-loops.info] What is this, 2003?
Re: (Score:2)
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
Re:Which illustrates what we already knew (Score:5, Informative)
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: (Score:2)
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.
Phoronix and bias (Score:3)
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 [phoronix.com]. 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: (Score:2)
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
Re: (Score:2)
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: (Score:3)
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: (Score:2)
OK then smartass, make that a static binary. That's one of the cons of dymanic loading.
Re: (Score:2)
:)
Re: (Score:3)
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: (Score:2)
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 revisi
Re: (Score:2)
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: (Score:2)
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 ben
Re: (Score:2)
You mean like this?
http://people.freebsd.org/~kris/scaling/os-mysql.png [freebsd.org]
Re: (Score:2)
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...
Re: (Score:2)
And 2012 will be the year that the Hurd will reach the Desktop!
December 21, I guess?
Re:Which illustrates what we already knew (Score:5, Informative)
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: (Score:3, Insightful)
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
Re: (Score:2)
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 C
Re: (Score:2)
And with Android, you get the added bonus of the trojans and other malware you thought you left behind on Windows.
Interesting benchmarks, but not an article (Score:2)
It's just a bunch of benchmarks with commentary and no conclusion.
Could we possibly get ANY information on WHY?
Re: (Score:3, Insightful)
Re: (Score:3)
Read the article, it was the same system. OS's identify things differently and there was no attempt at standardization.
Re: (Score:2)
You need to RTFA. It was the same system.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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.
Compiz (Score:5, Informative)
This is likely caused by Compiz interacting with the game engine on Ubuntu. Turn Compiz off and re-run the benchmarks.
Re: (Score:2)
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: (Score:2)
Re: (Score:3)
> 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!
Not a good test. (Score:5, Informative)
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: (Score:2)
Phoronix should be ashamed...
That goes without saying though.
Re: (Score:3)
Read the article it's the same system.
IT'S THE SAME HARDWARE (Score:3)
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 [phoronix.com]. 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.
Interesting. (Score:5, Informative)
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.
I wonder.... (Score:2)
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 U
Re: (Score:2)
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!
turn EVERYTHING off... (Score:5, Insightful)
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) .Xsession file with nothing more than "xterm" on it. as soon as X starts with a windowless xterm, run the game from the CLI.
- 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
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: (Score:2)
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.
"more" is more important than faster (Score:3)
What's needed is more games on linux, not faster ones.
Unity Vs KDE, not BSD Vs Linux.... (Score:2)
What games? (Score:2)
I'd like to know which games were in the experiment. Did they use both of them?
Testing the right things here? (Score:2)
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... (Score:3)
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 s
Re: (Score:2)
Re: (Score:2)
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.
Who mentioned wine? (Score:2)
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: (Score:2)
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 betw
Re: (Score:2)
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 shifte
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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 em
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
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...
Re: (Score:2)
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: (Score:2)
The linuxolator in FreeBSD is located here:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/ [freebsd.org]
You can actually see how it's implemented.
Re: (Score:2)
It's the same hardware. Can fanboys not read?
Re: (Score:2)
It's the same hardware, Linux and BSD identify hardware differently and the author didn't standardize it.
Re: (Score:2)
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
Re: (Score:3)
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: (Score:2)
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.