Mac OS X 10.5 vs. Ubuntu 8.10 Benchmarks

[phoronix]

Phoronix: Mac OS X 10.5 vs. Ubuntu 8.10 Benchmarks

Last week we published Ubuntu 7.04 to 8.10 benchmarks from a Lenovo ThinkPad T60 and had found Ubuntu's performance degraded peculiarly over the past year and a half. We then published Fedora 7 to 10 benchmarks covering the same time-frame and from the same exact Intel notebook computer, but the newer releases of Fedora were only marginally slower in a few tests. In our performance exploration of Ubuntu we now have additional tests to publish this morning. This time around we're switching out the hardware we're testing on to Intel's newer Core 2 series and we're comparing the performance of the x86 and x86_64 editions of Ubuntu 8.10 against Apple's Mac OS X 10.5.5 operating system.

http://www.phoronix.com/vr.php?view=13080

[MetalheadGautham]

very intresting. this proves without doubt that ubuntu sucks. :|

[MaestroMaus]

very intresting. this proves without doubt that ubuntu sucks. :|

Warning; hater alert!

[ebird]

Warning; hater alert!

I think, he did not read the article. But Ubuntu is getting slower. It becomes slower every release. I am using Ubuntu since feisty and there is a bit desktop responsiveness problem since Gutsy or since kernel version 2.6.22 I think. Fedora is less affected, but the problem exists too. Intrepid is currently unusable for me. My systems freezes for more than 20 seconds, while updating or using a disc intensive application. I switched to Fedora 10. It's not as awful as Intrepid. I hope Jaunty Jackalope will be as fast as Feisty.

[joffe]

I'm switching from 8.04 to something else when I get home, not because it's slow but because it's just so boring (:p)

Given that the six-month 'updates' consist mostly of providing updated packages (wth?) I might as well use a rolling release distro, I can't see what's so special about what Ubuntu offers except the ugliest desktop since Windows 95.. (not Ubuntu's fault, but it is their fault for using default GNOME! so bland, so boring..)

Maybe I'll try it again once they follow up on Shuttleworth's wish to 'top Apple' in the GUI department but they're going to have to do something unique rather than just slapping their logo on the latest GNOME and call it a day..

But it is sad that it's getting slower instead of faster for each release. Especially given the netbook focus as of late, the Atom isn't exactly going to help things.

[blackiwid]

But it is sad that it's getting slower instead of faster for each release. Especially given the netbook focus as of late, the Atom isn't exactly going to help things.

so i am typing this on a samsung nc10 (a atom-based netbook). But i have no problem with the speed, i have 20 tabs openend with epiphany and it works all well.

because fedora is also effekted with this decrease in speed i think linus did something wrong.

if you dont like gnome ( i love it ) feel free to use kubuntu or another distri. but blaming this on ubuntu is a bit unfair i think.

[risbac]

Ubuntu sucks? Did you really check the results for the 64bits version? Personally I find them quite convincing.

I'm quite surprised by the differences between the 32 and 64bits version. It's "only" benchmarks though, is this difference also noticeable in everyday use? I'm only using 32bits version of Ubuntu, would it be interesting to try 64bits version?

[hdas]

i cannot believe this recent rabid ubuntu rant. specifically, two things -
(1) since when did ricers and speed-freaks start using ubuntu. i have been using gentoo for three years and have finally started using ubuntu for last few months - simply to save myself some effort and i finally felt that ubuntu is mature enough since 8.04.1 (no, 8.04 was still raw ;)). i can say that the performance is very very good, and not to mention the stability. i do not see any difference - perhaps only better, with newer versions of software. ubuntu has not only inherited the debian goodness, they have done a lot of hard work too.

(2) sure the default artwork might not suit one's taste, but thanks to the community, there is so much choice and a little effort on luser's part is all that is required. i myself hate the orange brown theme to the core (even though the light brown feisty and the hardy heron bird were pretty cool to my taste). i changed my entire system to all blue (including usplash boot and grub theme!). for the interested, look for 'bluman' theme in ubuntu-art.org. also i picked the nodoka gtk theme and echo icon theme and bluecurve cursors from fedora. (http://137.110.115.18/nodoka-theme-kde/mydesktop.png.)

[hdas]

btw, just to make sure the fairness :p, regarding the benchmarks involving disk speeds, please note that the later (inner) partitions of the hard disk are significantly slower than the first partition (outer part of disk), a difference of about 10 to20 MB/s !.

[Pesho]

In the filesystem and SQLite tests, the Ext3 filesystem gave Ubuntu a huge disadvantage. It's generally slow, and its default journalling mode is seriously buggy (http://bugzilla.kernel.org/show_bug.cgi?id=9546). You should have tested using a better filesystem, for example JFS.

[Michael]

In the filesystem and SQLite tests, the Ext3 filesystem gave Ubuntu a huge disadvantage. It's generally slow, and its default journalling mode is seriously buggy (http://bugzilla.kernel.org/show_bug.cgi?id=9546). You should have tested using a better filesystem, for example JFS.

Each OS was left in their stock mode, which is why JFS or any other FS wasn't used.

[avilella]

My love for Phoronix reports keeps growing and growing! Great job on this extensive comparison between Mac OS X and Ubuntu. Given the results, I have to say that I wouldn't expect Linux to win on a Mac Mini hardware both in the OpenGL and disk benchmarking area, because Apple will always have the upper hand here. That said, the SQLite results are not so good for Linux. BYTE Unix Benchmark, way to go! And looking forward to all the GEM and kernel-based mode setting goodness to kick in.

[numerodix]

I'm glad you're doing these benchmarks. Timing people makes them want to try harder. I haven't noticed any bad regressions in ubuntu yet, but the only way to get performance right is to always be aware of it.

[bulletxt]

I think it's time to make a Windows Vista vs Ubuntu benchmark. of course use NVIDIA as GPU.

[joffe]

(2) sure the default artwork might not suit one's taste, but thanks to the community, there is so much choice and a little effort on luser's part is all that is required. i myself hate the orange brown theme to the core (even though the light brown feisty and the hardy heron bird were pretty cool to my taste). i changed my entire system to all blue (including usplash boot and grub theme!). for the interested, look for 'bluman' theme in ubuntu-art.org. also i picked the nodoka gtk theme and echo icon theme and bluecurve cursors from fedora.


I know, this is what mine looks like (http://www.isarapix.org/pix35/1225188868.png). My point is that if I'm going to customize it extensively I might as well use something like Arch where I get to trim away all the crap I don't need and where I am spared from the Debian package management system - Ubuntu is supposed to be a turnkey distro, and I would just love for it to be turnkey beautiful instead of turnkey 1995. Not just for myself but the image and the adoption rates that would lead to. Lots of people bought Vista purely on the eye candy. Many people who buy Macs buy them because the OS (and the hardware) is pretty. The GUI is the face of the OS, doesn't matter how solid it is, if users are met with grey task bars and some ugly brown splatter they're going to be less positive about it. I'm looking at this from a 'competing with Win/OSX' perspective which Shuttleworth claims is his goal.

[valgonzarp]

In the filesystem and SQLite tests, the Ext3 filesystem gave Ubuntu a huge disadvantage. It's generally slow, and its default journalling mode is seriously buggy (http://bugzilla.kernel.org/show_bug.cgi?id=9546). You should have tested using a better filesystem, for example JFS.

About the SQLite benchmarks - if they used stock SQLite (shipped with Leopard), they may be faster with 10.5 because default SQLite options are "cheating":


On Mac OS X v10.4, there are only two settings to control the way in which data in a SQLite-based store is written to disk. In order to provide finer granularity of control over the tradeoff between performance and reliability, on Mac OS X v10.5 Core Data uses two independent pragmas to control these options.

Note that the default fsync behavior on Tiger was fcntl(F_FULLFSYNC) but on Leopard it is now a standard fsync . (This affects all SQLite databases on Leopard, not just Core Data.) The pragma allows you to toggle this value. See “Configuring a SQLite Store’s Save Behavior” in Persistent Stores for a full discussion.


10.4 behaviour was:

fsync on Mac OS X: Since on Mac OS X the fsync command does not make the guarantee that bytes are written, SQLite sends a F_FULLFSYNC request to the kernel to ensures that the bytes are actually written through to the drive platter. This causes the kernel to flush all buffers to the drives and causes the drives to flush their track caches. Without this, there is a significantly large window of time within which data will reside in volatile memory—and in the event of system failure you risk data corruption.


On 10.5 it's no longer F_FULLFSYNC, which means that SQLite does not do full fsync by default on Leopard, which might be the case on Ubuntu, which might be the reason why it is much slower there.

[valgonzarp]

In the filesystem and SQLite tests, the Ext3 filesystem gave Ubuntu a huge disadvantage. It's generally slow, and its default journalling mode is seriously buggy (http://bugzilla.kernel.org/show_bug.cgi?id=9546). You should have tested using a better filesystem, for example JFS.

About the SQLite benchmarks – if they used stock SQLite (shipped with Leopard), they may be faster because that default Leopard SQLite is "cheating":

On Mac OS X v10.4, there are only two settings to control the way in which data in a SQLite-based store is written to disk. In order to provide finer granularity of control over the tradeoff between performance and reliability, on Mac OS X v10.5 Core Data uses two independent pragmas to control these options.

Note that the default fsync behavior on Tiger was fcntl(F_FULLFSYNC) but on Leopard it is now a standard fsync . (This affects all SQLite databases on Leopard, not just Core Data.) The pragma allows you to toggle this value. See “Configuring a SQLite Store’s Save Behavior” in Persistent Stores for a full discussion.

10.4 behaviour was:

fsync on Mac OS X: Since on Mac OS X the fsync command does not make the guarantee that bytes are written, SQLite sends a F_FULLFSYNC request to the kernel to ensures that the bytes are actually written through to the drive platter. This causes the kernel to flush all buffers to the drives and causes the drives to flush their track caches. Without this, there is a significantly large window of time within which data will reside in volatile memory—and in the event of system failure you risk data corruption.


So maybe it's just faster on OS X because by default SQLite there does not issue full fsync, which may be the case on Ubuntu.

[Pesho]

So maybe it's just faster on OS X because by default SQLite there does not issue full fsync, which may be the case on Ubuntu.


Yes, that's probably the main cause.

[deanjo]

About the SQLite benchmarks – if they used stock SQLite (shipped with Leopard), they may be faster because that default Leopard SQLite is "cheating":

PTS compiles it from scratch.

[SyXbiT]

I'm disappointed for linux :(
still, Ubuntu is one of the slower linux distro's.

I wish there was hype behind some of these benchmarks, like there is on Acid tests for web rendering engines, or javascript stuff.
If there was such hype, I could see some linux people improving these a lot.

I agree with the post about lag since the 2.6.22 kernel in gutsy. I think it had to do with the scheduler. not convinced the CFS is completely fair :)

When i copy big files between HDs, my PC becomes unusable (quad core 4GB ram) seriously, I see no need for this.

[reavertm]

I'm going to test SQLite benchmark on my gentoo. This terribly poor SQLite performance in Ubuntu is shocking, something must be broken - I don't believe ext3 is that slow (I'm using reiserfs so I can't really judge though).

Edit:
sqlite benchmark results on P4 640 Prescott 3.2GHz (HT) on WDC 250GB/reiserfs (with KDE4-live with compositing and some other apps running but rather being idle)
- nearly 68s (12500 inserts)
still slower than Mac OS X, it must be FULL_SYNC related as someone stated before.

[Kano]

ext3 is much slower with small files, you can gain more than 5% when you compile a kernel on reiserfs.

[shredwheat]

Thanks for these comparisons, really interesting to see. I'd love to see more real world timing comparisons also. Main things I'm thinking about are.


Boot speed
Launch Firefox from cold boot
Power consumption (active and idle)
Battery life
Finder vs. Nautilus for large directories and operations

[Thetargos]

I'm disappointed for linux :(
still, Ubuntu is one of the slower linux distro's.

I wish there was hype behind some of these benchmarks, like there is on Acid tests for web rendering engines, or javascript stuff.
If there was such hype, I could see some linux people improving these a lot.

I agree with the post about lag since the 2.6.22 kernel in gutsy. I think it had to do with the scheduler. not convinced the CFS is completely fair :)

When i copy big files between HDs, my PC becomes unusable (quad core 4GB ram) seriously, I see no need for this.

Something must be really, really bad for IO operations in Ubuntu, then... I just bought a new HDD and moved around about 300Gb worth of data, from various sources to various destinations, some times simultaneously. And on my Fedora 8 x86_64 2.6.26.5 the system was just as snappy as always, while these moves were being done (and I use EXT3 as filesystem, mind you) I was doing some other stuff like reading e-mail, browsing the web and using OOo (until I had to move my /home data, which meant I didn't want to disturb the process by adding cache files to FF, new mails to TB, etc).

I don't mean this to be Ubuntu bashing or "mine is better than yours" kind of comment, rather that something has gone seriously wrong somewhere... Are there any bug reports about this? Are there any kind of reports about whether this slow down is with P-ATA/S-ATA drives? Which operations are slower? what's the CPU usage of commands like cp/mv/du/etc? Maybe a regression in a patch from Ubuntu to libata?

[kraftman]

I'd love to see benchmarks of other distros (Arch Linux, Gentoo), because it looks like there's something really bad in the newest Ubuntu. It's strange, but Intrepid seems to be faster than previous versions, so the problem may be in something else. And I'd love to see benchmarks using NVIDIA card.

[MaestroMaus]

I know, this is what mine looks like (http://www.isarapix.org/pix35/1225188868.png). My point is that if I'm going to customize it extensively I might as well use something like Arch where I get to trim away all the crap I don't need and where I am spared from the Debian package management system - Ubuntu is supposed to be a turnkey distro, and I would just love for it to be turnkey beautiful instead of turnkey 1995. Not just for myself but the image and the adoption rates that would lead to. Lots of people bought Vista purely on the eye candy. Many people who buy Macs buy them because the OS (and the hardware) is pretty. The GUI is the face of the OS, doesn't matter how solid it is, if users are met with grey task bars and some ugly brown splatter they're going to be less positive about it. I'm looking at this from a 'competing with Win/OSX' perspective which Shuttleworth claims is his goal.

I'm sorry, but I like Gnome because it's easy on the eye and has a strong layout. Furthermore, I know more people who change the vista/xp default theme to 'classic' then people who actually keep these shiny themes. Maybe the world consists of different people, who knows?

Also, if people want it shiny, they can use KDE4: Shiny by default --> problem solved.

The speed is very fast compared to XP/Vista and I have faith in the teams working on the kernel/distro's.

[d2kx]

...those benchmarks against MS Vista SP1 & OpenSolaris 2008.11 :)

[MaestroMaus]

I know, this is what mine looks like (http://www.isarapix.org/pix35/1225188868.png). My point is that if I'm going to customize it extensively I might as well use something like Arch where I get to trim away all the crap I don't need and where I am spared from the Debian package management system - Ubuntu is supposed to be a turnkey distro, and I would just love for it to be turnkey beautiful instead of turnkey 1995. Not just for myself but the image and the adoption rates that would lead to. Lots of people bought Vista purely on the eye candy. Many people who buy Macs buy them because the OS (and the hardware) is pretty. The GUI is the face of the OS, doesn't matter how solid it is, if users are met with grey task bars and some ugly brown splatter they're going to be less positive about it. I'm looking at this from a 'competing with Win/OSX' perspective which Shuttleworth claims is his goal.

What's wrong with the Debian package manager btw?
I found it to be one of the main reasons to switch to Ubuntu really.

[Prosthetic Head]

Just one point and I don't know how important it is...
OS-X and the mac-mini are spescifically designed for each other where as ubuntu has to support as much hardware as possable out of the box. So any general OS that comes with drivers built in will have to carry a lot of 'dead weight' and avoid over optimisation, where as an OS for very few hardware platforms can be highly optimised and shed all unnecessary components.

[deanjo]

Just one point and I don't know how important it is...
OS-X and the mac-mini are spescifically designed for each other where as ubuntu has to support as much hardware as possable out of the box. So any general OS that comes with drivers built in will have to carry a lot of 'dead weight' and avoid over optimisation, where as an OS for very few hardware platforms can be highly optimised and shed all unnecessary components.


With the modular nature of linux this is of no concern. It loads what it needs to support the hardware found.

[Prosthetic Head]

With the modular nature of linux this is of no concern. It loads what it needs to support the hardware found.

Thanks for clearing that up for me, I take it that appies to all the device drivers, kernal modules and the like.

However, It doesn't apply to design phase and compile time optimisations. For eg, ubuntu is compiled to support many old archetectures back to (i think) the original pentium and therefor does not allow a lot of optimisations that could be applied to a single archetecture system. Even if (like SSE, SSE2, etc optimisations) they can be detected and used at runtime, there is still the dead weight of the legacy support code in there takeing up memory space. Some distros build for i386, i think ubuntu doesn't go that far back, only to the i586.

This is why an well tuned gentoo system SHOULD run faster, load quicker and be lighter on memory usage than a system that is compiled to make sure it will work on every 32bit x86 archetecture you throw at it.

I guess the X86-64 build SHOULD dodge most of this legacy junk, if done properly?

[deanjo]

Thanks for clearing that up for me, I take it that appies to all the device drivers, kernal modules and the like.

However, It doesn't apply to design phase and compile time optimisations. For eg, ubuntu is compiled to support many old archetectures back to (i think) the original pentium and therefor does not allow a lot of optimisations that could be applied to a single archetecture system. Even if (like SSE, SSE2, etc optimisations) they can be detected and used at runtime, there is still the dead weight of the legacy support code in there takeing up memory space. Some distros build for i386, i think ubuntu doesn't go that far back, only to the i586.

This is why an well tuned gentoo system SHOULD run faster, load quicker and be lighter on memory usage than a system that is compiled to make sure it will work on every 32bit x86 archetecture you throw at it.

I guess the X86-64 build SHOULD dodge most of this legacy junk, if done properly?

Typically, GCC will read the capabilities of the processor and apply any features it finds in the host processor to the compilation. Same thing is done on OS X (Xcode is GCC with additional libraries for OS X). PTS does not use the precompiled libraries for it's tests. It compiles them from scratch.

[Prosthetic Head]

ok, the phoronix executive editor said (on page 2 of this thread i think)
Each OS was left in their stock mode, which is why JFS or any other FS wasn't used.
In 'stock mode' ubuntu is compiled for the lowest common denominator (ie i586, the original pentium). Ubuntu is distributed as precompiled binary so it is very much non-stock mode to compile it with different archetecture spescific optimisations.The test programs may have been compiled spescifically on each system, but they rely on librarys, kernel modules and the core of the kernel its self in order to work.

I don't say this makes much difference to the outcome of the tests, just that its something inherently in the advantage of a restriceted OS-Hardware partnership.

[drag]

Whatever.

I have personal experience with HFS+ and it _sucks_.

Really. It's utter shit. You don't want it. Out of OS X, Linux, BSD, Windows, whatever.. hfs+ is the crustiest and most backward file system out there. It is a fat32-generation file system with BSD VFS layered above it to create the illusion of semi-POSIX-compatibility and journalling... both come with a big hit in performance.

I can't really stress this enough. It's a slow, old fashioned FS that is much more likely to corrupt your data then Linux's Ext3.

-------------------------------

What is more likely happening is that MacOS is simply lying about file system operations. For example; With firefox one of the big performance misfeatures for Linux was that the application was called fsync() a hundred times a second. (Firefox folks are stupidly trying to make their sqlite database ACID compliant or some bizzare thing like that)

With most operating systems, like Windows or OS X, the OS just ignores that sort of thing and lies to the application that it has sync'd to the harddrive, in order to improve the perception of performance. With Linux it's taken much more seriously actually does the sync'ng casing the harddrive to thrash around and freezes any application waiting on I/O.

So you have to take any file system benchmark with a huge grain of salt.

For example unless that Bonnie++ benchmark was done correctly it's completely and 100% misleading.

The deal is that in order for it to be accurately determining the performance of the file system you have to drive the files out of cache and make sure that it's actually written to the drive. Otherwise your just judging memory I/O and Bonnie++ is not designed to do that accurately. And sync OS X lies about things like 'sync' (thus making it much likelier your data will be corrupted during any power outage or system crash) you can't trust anything the benchmark says otherwise.


This system has 1GB of RAM. With running benchmarks I expect most of the OS is going to be pushed to cache and you'll have about 700 megs or more of file system cache you have to deal with.

So with bonnie++ you'll have to make sure that the benchmarks are using files that are 1.5x times the amount of memory. Then you'll get a much more accurate response to disk and file system performance.

In other words.. without actually seeing the settings used in the benchmarks the benchmarks are WORTHLESS and MISLEADING. No doubt about it. Disk and file system benchmarks are insanely hard to get right and while it's possible to draw conclusions from bonnie++, it's going to require much more then a simple graph. We need settings and other data output.

-------------------------------------------

Take a look at the Gzip performance benchmark. Your dealing with a 2GB file, so cache performance isn't going to enter into it much. With that Linux trounces OS X. The CPU is more then fast enough, even on these low-end boxes, make Gzip'ng a 2GB a I/O bound operation.. the cpu is capable of compressing much faster then the disk is capable of reading and writing files.

Get it?

--------------------------------

Here is a example of what I am talking about:

I am running Debian Unstable on a Core2Duo laptop. I have 2GB of RAM, 150GB harddrive, and a T7300 2.0ghz dual core CPU. The Gnome environment, with a couple terminals and web browser, actively uses about 256-300 MB of RAM. This leaves 1.7GB of RAM for application and file system cache.

I have a 701MB AVI file that I am compressing using Gzip. AVI is already heavily compressed using media-optimized compression technology (aka mpeg4) so there is no way in hell Gzip is going to be able to improve on that. So it'll just thrash around and is a mostly worst-case scenario for this sort of application using up as much CPU resources as possible.


First run is:
$ time gzip -c Star\ Trek\ 10\ -\ Nemesis.avi > /dev/null

real 1m51.576s
user 0m52.631s
sys 0m0.532s

Second run is:
$ time gzip -c Star\ Trek\ 10\ -\ Nemesis.avi > /dev/null

real 0m52.124s
user 0m51.323s
sys 0m0.332s



A minute of difference. A 100% improvement in performance in just two runs. This is because when reading the file from disk. However the second time the file was loaded into FS cache, so the disk was no longer the bottleneck. So the second time it was a CPU benchmark since it was CPU bound.

--------------------------------


So it's very important to include the settings for the benchmarks. Especially the FS. Because with FS benchmarks the numbers completely change their meanings depending on your settings.

[Prosthetic Head]

Thanks for that explanation, it makes a lot of sense.

[erick.mendes]

Ok, why not try to benchmark ubuntu running on ReiserFS partitions?
I think that would had made a difference on the results...

[kraftman]

Just one point and I don't know how important it is...
OS-X and the mac-mini are spescifically designed for each other where as ubuntu has to support as much hardware as possable out of the box. So any general OS that comes with drivers built in will have to carry a lot of 'dead weight' and avoid over optimisation, where as an OS for very few hardware platforms can be highly optimised and shed all unnecessary components.

Linux kernel itself outperforms others, so it must be something else - kernel configuration, problems with gcc or libraries (like well known performance degradation in MySQL with some library), different application configs and slower Intel drivers.

P.S.

Ubuntu loads tons of unnecessary drivers.

[MetalheadGautham]

Warning; hater alert!
Ubuntu Hater ? Me ? I used to love that distro in early 2007. But since 7.10, its starting to suck a lot. I did read the whole article, and it shows performance below my expectations. Losing to Macintosh is perhaps one of the worst things that can happen to ubuntu IMO. I switched to Archlinux and its 300% faster compared to ubuntu according to my personal experience.

[D0M1N8R]

Looks like Ubuntu got a serious beat down. Very interesting comparison (or not?) But even if it came out on top this still fails to answer the question which is: Has Ubuntu has become slower over time?

[kraftman]

Looks like Ubuntu got a serious beat down. Very interesting comparison (or not?) But even if it came out on top this still fails to answer the question which is: Has Ubuntu has become slower over time?

Just read Drag's post... And no, it's not getting slower.

[drag]

Ya.

Without more information it's hard to tell exactly what is going on with these benchmarks.

It's pretty plain that Linux OSS drivers are getting trounced by OS X. This is not surprising given the immaturity of the platform. (and X.org is a old platform. It's just very retarded, I guess. Lets hope it's a late bloomer)

The way I see it right now the developers for a long time were just trying to get the stupid thing run stable. After all we have no less then 3 graphics drivers operating on a single peice of hardware at any one time... your VGA or framebuffer console drivers. Your 2D DDX drivers and then your DRI/DRM drivers.

No less then 3 different projects with different approaches and ideologies working together. Linux kernel developers (DRM/VGA/Framebuffer), X.org drivers twiddling bits around on the PCI bus (DDX drivers), and then DRI drivers from Mesa and Xorg folks.


Just getting it to run was a challenge.

Hopefully with the modernization of the driver model and improvements to the X server we can start to see them concentrating more and more on performance.

Especially when they get the attention of the Linux kernel developers, which are all about performance, things should start to shape up.

For example:
http://lwn.net/Articles/305919/

It may be locked for now unless your a subscriber, but basically it's talking about taking a memory subsystem designed for allowing high-memory (above 1GB) to be used efficiently in 32bit systems and applying it to graphics memory management.

It lead to a 18x improvement in Quake3 performance and went from 85FPS to 360FPS on Glxgears.

Of course that was with the development memory-managed driver and not the ones anybody is using now (the ones in production are better optimized)

-----------------------


As far as the rest of the benchmarks in this article it's very difficult to make a solid conclusion about them.

With all these things they are using the same code compiled with the same compiler in both OS X and Ubuntu. So while interesting, it would be more interesting to investigate and determine exactly why the benchmarks get the results they get.

So it's important that readers be given settings and details so that they can see for themselves and accurately recreate what is being shown.

I suppose I am missing were this is laid out, so if anybody can help me I would be very greatful.

For example it can be a performance bug in Ubuntu. Maybe a compiler mis-setting or kernel bug is limiting performance. Maybe it's something easy to fix that could lead to a vast improvement in performance.

or it could be that the benchmarks are not being used properly and readers could point out improvements or changes that can help Phoronix improve how it reports things and the benchmark suites it's using.

I donno.

[kraftman]

Some portals are publishing this really unfair benchmark... It's sad that Phoronix didn't anything to stop misleading people. Nothing remains except to inform those portals that Phoronix benchmarks can't be taken seriously.

[Michael]

Some portals are publishing this really unfair benchmark... It's sad that Phoronix didn't anything to stop misleading people. Nothing remains except to inform those portals that Phoronix benchmarks can't be taken seriously.

It's not unfair... It's showing the performance of two operating systems in their stock configurations.

[kraftman]

It's not unfair... It's showing the performance of two operating systems in their stock configurations.

So, it's real stupid benchmark. The systems should use the same settings if possible or at least very similar and you should let us know what settings were used. It looks like you're burying your heads in the sand.

[Michael]

The systems should use the same settings if possible or at least very similar and you should let us know what settings were used.

As aforementioned in the article, the only main change done was with Ubuntu and disabling Compiz. The screensavers in each OS were also disabled. Is there another setting you want to know about?

[kraftman]

As aforementioned in the article, the only main change done was with Ubuntu and disabling Compiz. The screensavers in each OS were also disabled. Is there another setting you want to know about?

Read Drag's post #34... You were benchmarking Mac OS cache performance and Ubuntu disk I/O in some tests.

[Thetargos]

Read Drag's post #34... You were benchmarking Mac OS cache performance and Ubuntu disk I/O in some tests.

Hmmm... Indeed. However, at the user-level and experience, these "cheats" (as you seem to be making them out to be) are actually part of the vendor's advertised experience... So MacOS lies about it syncing to HDD to have a perceived improved performance, that is its default configuration. And as Michael said, that's actually what's being tested. Beyond this perceived impression about the performance delta in I/O (regardless of the fact that OSX may be lying to the application or not), a meta-analysis can yield whatever you like... The actual "performance" (or impression of it) from the tests is a whole other story.

I have a few comments about the delta in performance with the graphics drivers:


As far as I know, Apple make all their drivers in-house and have any number of NDA's signed with the manufacturers to get the specs, documentation, sample-code and what not. Which permits for highly optimized video drivers for Apple Mac products.
The graphics stack in the case of Apple is an actual OpenGL ICD driver stack. Remember that Open Drivers rely on Mesa and while Mesa is an implementation of the OpenGL stack, it is not an official ICD or endorsed by the Khronos group in any way. I do believe that the current Mesa stack is not as optimized as it could be.


I think overall this was a fair comparison. Maybe not all of us agree with it, and it would be very interesting to see results from Macs powered by nVidia graphics using the nVidia proprietary driver on Linux to see how do they perform, since this would level things up a bit: in that the nVidia driver DOES provide a different OpenGL stack not based on Mesa with its drivers, and maybe this stack is more similar to that used on MacOS' drivers. I don't know if AMD's OpenGL stack for fglrx is or is not based on Mesa (I do believe it is not)... There are no Intel Macs with ATi video hardware on them, are there? Or put another way, there are no fglrx drivers for PPC Linux either... And most likely the PPC MacOS drivers for Radeon blow away the OSS Radeon drivers currently available.

[deanjo]

Hmmm... Indeed. However, at the user-level and experience, these "cheats" (as you seem to be making them out to be) are actually part of the vendor's advertised experience... So MacOS lies about it syncing to HDD to have a perceived improved performance, that is its default configuration. And as Michael said, that's actually what's being tested. Beyond this perceived impression about the performance delta in I/O (regardless of the fact that OSX may be lying to the application or not), a meta-analysis can yield whatever you like... The actual "performance" (or impression of it) from the tests is a whole other story.

I have a few comments about the delta in performance with the graphics drivers:


As far as I know, Apple make all their drivers in-house and have any number of NDA's signed with the manufacturers to get the specs, documentation, sample-code and what not. Which permits for highly optimized video drivers for Apple Mac products.
The graphics stack in the case of Apple is an actual OpenGL ICD driver stack. Remember that Open Drivers rely on Mesa and while Mesa is an implementation of the OpenGL stack, it is not an official ICD or endorsed by the Khronos group in any way. I do believe that the current Mesa stack is not as optimized as it could be.


I think overall this was a fair comparison. Maybe not all of us agree with it, and it would be very interesting to see results from Macs powered by nVidia graphics using the nVidia proprietary driver on Linux to see how do they perform, since this would level things up a bit: in that the nVidia driver DOES provide a different OpenGL stack not based on Mesa with its drivers, and maybe this stack is more similar to that used on MacOS' drivers. I don't know if AMD's OpenGL stack for fglrx is or is not based on Mesa (I do believe it is not)... There are no Intel Macs with ATi video hardware on them, are there? Or put another way, there are no fglrx drivers for PPC Linux either... And most likely the PPC MacOS drivers for Radeon blow away the OSS Radeon drivers currently available.

Apple does not do the video drivers "in-house" and there most certainly is intel Macs with ATI graphics as well.

http://support.apple.com/kb/SP11
http://support.apple.com/kb/SP16
http://support.apple.com/kb/SP24

[kraftman]

And as Michael said, that's actually what's being [b]tested

Yeah, but it's so idiotic benchmark that no one can imagine. It's like testing two graphic cards in Quake 3. First card using low quality mode and second using high quality, then say that first card is faster... In objective benchmark people use the same version of applications and the same settings. If not, benchmark is just piece of crap.

[Thetargos]

Yeah, but it's so idiotic benchmark that no one can imagine. It's like testing two graphic cards in Quake 3. First card using low quality mode and second using high quality, then say that first card is faster... In objective benchmark people use the same version of applications and the same settings. If not, benchmark is just piece of crap.

The applications ARE the same, even built from source on both platforms, and the options parsed by the PTS are also the same. The differences in the I/O tests, are not fault of the apps or the benchmarking tool to measure their performance, but rather how the individual systems handle the petitions being made by the applications (case in point, the SQL tests). What you are saying is more like comparing a BMW V8 engine to a Dodge HEMI engine. The HEMI can "shut off" four cylinders when they are not in use, hence being more fuel efficient, and may even have a bit of lag to power those up for when they're needed (acceleration lag, if you will). The BMW engine on the other hand, since all 8 cylinders are all active all the time, will not have said lag when accelerating[1]... Its inherent to the ENGINE, not the fuel used, or the road the cars are used.

Sure, you can tune both cars up and change them a LOT, but in their stock configuration one may have a bit of lag and the other not. Well this is exactly the same! The applications to assess the performance were all run in identical modes, the systems reacted to them in different ways. That seems to be clear now, and (duh!) these tests also served to show this difference between these two systems. Remember that (as much as we may hate it, since Linux appearsto lose) these tests are comparing (in a sort-of-objective manner) apples to oranges (pun intended!). Sure there are a LOT of things that could be modified now that we know how both systems react when faced to one another, and that these aspects could be changed in future tests... However, none of that would have been clear otherwise without testing in their default configuration. This is but the first series of tests, and thus this serves to be the foundation for generating a methodology to accurately and objectively test and compare more than one platform. What is idiotic is your attitude towards these results. They are not definitive, but you have to reckon that without a baseline how in the hell can you generate an objective, reproducible and accurate methodology to test across platforms (and that applies for Linux Vs MacOS; MacOS Vs FreeBSD; FreeBSD Vs OpenSolaris or all compared to one another).

The tools are objective enough, system settings may have to be fiddle with to get more consistent results and get around bottle necks (like MacOS ignoring fsync() calls). However without knowing how things work on their default, and rejecting those facts, is utterly stupid, otherwise how can you know what may be affecting performance? And don't forget that in this particular case, Apple chose to ship MacOS that way, even at the risk of corrupting data (but then again, no File System is ever free of data corruption). Don't forget either that Ext3 (dunno about Ext4) is actually of the fastest journaling systems when operating in full journaled mode, which in default configurations it does not, as do not neither of the other FSes that I know of.

Bottom line: it required the intervention of many people in this thread to determine why MacOS X gets better results with some applications run the same way compared to Ubuntu 8.10, and it turned out to be that the OS "cheats" by not flushing the buffers immediately, if anything, this discussion brought to the light this issue and is a thing to consider in any intensive HDD I/O tests in the future, but without these results and this discussion it may have gone undetected and without any consideration. The applications that were built from source on both platforms also reflect the contrast between GCC versions (yes, versions, as if you wanted to test against a Linux distro with the same GCC version, it'd had to be one of 1-1.5 years ago), and remember that GCC generates optimized code, so that may be one thing worth looking into as well (having both systems match -march -mcpu CCFLAGS and see what happens), but again, that is going out of the default.


I'm not saying that is the exact way these two engines work, is just an exemplification overly simplified, and what not...

[kraftman]

@Thetargos

I've got your point, but those differences what are you talking about should be mentioned in the article. Without them many idiots think that Mac OS is faster. And why not use bigger file in bonnie++ benchmark?

[Thetargos]

Well, I see your point, but keep in mind that none of this was clear until this discussion took place. Maybe a follow up article with further investigation regarding how does MacOS handle fsync() and other things like the state of the drivers, etc, would be worth to clarify this issue.

[zAo_]

I love working with debian based linux, but this proves it: Linux is 5years + behind.

EDIT: nah; X is 7 years behind, Linux isn't.

[kraftman]

@Thetargos,

Yes, you're right. I hope that next benchmark will be a little more "fair". Thanks to Drag's, yours and few other people posts.

@zAo_

Linux is 5years + behind what? It's 2008 now, not 2013 (but, maybe is due to some mistake), so I recommend you to change your date in system settings. And, you just proved what I said in #51. Thanks a lot.

[deanjo]

@zAo_

Linux is 5years + behind what? It's 2008 now, not 2013 (but, maybe is due to some mistake), so I recommend you to change your date in system settings. And, you just proved what I said in #51. Thanks a lot.

As his edited message says, not really linux but X is behind by several years.which is a pretty accurate statement IMHO.

[kraftman]

As his edited message says, not really linux but X is behind by several years.which is a pretty accurate statement IMHO.

That's possible. Luckily, it seems that some people are paying more attention to X now, than some time ago - more frequently updates, they fix bugs faster etc. Maybe in the future Wayland will replace X Server on Linux.

[Thetargos]

As his edited message says, not really linux but X is behind by several years.which is a pretty accurate statement IMHO.

Actually I don't think it is/was... Linux became relevant as a desktop alternative fairly recently, and since focus has been placed on the desktop by various groups (Canonical's Ubuntu, SuSE's OpenSuSE, Red Hat's Fedora, and many, many other projects) Xorg development has been blazing fast with a LOT of new features in the past three-four years, to the point where Linux desktops (and some other Unix systems) have the prettiest and most useful desktop effects around. Sure the API is convoluted, big, messy and has been under several revisions since the switch from XFree86 to Xorg, but all in all, it has come together pretty nice. IIRC MacOS' Quartz was in development for at least four years before they could integrate it into OS X (ever since Jobs rejoined the company with his NextStep ideas and concepts), and Mac's focus has always been the desktop.

X is slowly evolving, yes, no doubt, and most likely the Server will end up being replaced with the possibility of a fall back for old applications, much like the case in MacOS. However, how long for X to become completely obsolete and redundant?, I don't know, it may indeed never become redundant or obsolete, but it may very well cease to be the primary graphics system for Unix systems.

[deanjo]

Actually I don't think it is/was... Linux became relevant as a desktop alternative fairly recently, and since focus has been placed on the desktop by various groups (Canonical's Ubuntu, SuSE's OpenSuSE, Red Hat's Fedora, and many, many other projects) Xorg development has been blazing fast with a LOT of new features in the past three-four years, to the point where Linux desktops (and some other Unix systems) have the prettiest and most useful desktop effects around. Sure the API is convoluted, big, messy and has been under several revisions since the switch from XFree86 to Xorg, but all in all, it has come together pretty nice. IIRC MacOS' Quartz was in development for at least four years before they could integrate it into OS X (ever since Jobs rejoined the company with his NextStep ideas and concepts), and Mac's focus has always been the desktop.

X is slowly evolving, yes, no doubt, and most likely the Server will end up being replaced with the possibility of a fall back for old applications, much like the case in MacOS. However, how long for X to become completely obsolete and redundant?, I don't know, it may indeed never become redundant or obsolete, but it may very well cease to be the primary graphics system for Unix systems.

While NeXT's Display Postscript was a predecessor to quartz it does differ in many ways, it was not a direct port over to OS X. In fact it was developed all in house at Apple and no code from NeXT was used in Quartz (OS X caches bitmaps of the window graphics and does not execute postscript).

Quartz has always been a part of OS X. It debuted in 10.0 (early 2001). Quartz Extreme debuted in 10.2 (early 2003). and Quartz 2D Extreme (Now called QuartzGL in 10.5) debuted in 10.4 (late 2005). It's now close to being 2009 and X still lags behind in many aspects.

[Thetargos]

While NeXT's Display Postscript was a predecessor to quartz it does differ in many ways, it was not a direct port over to OS X. In fact it was developed all in house at Apple and no code from NeXT was used in Quartz (OS X caches bitmaps of the window graphics and does not execute postscript).

Quartz has always been a part of OS X. It debuted in 10.0 (early 2001). Quartz Extreme debuted in 10.2 (early 2003). and Quartz 2D Extreme (Now called QuartzGL in 10.5) debuted in 10.4 (late 2005). It's now close to being 2009 and X still lags behind in many aspects.

Indeed, my point is that Quartz was in development for a long time before OS X debuted in 2001, and it has been extended over the last 7 years, supposedly having a major rework for 10.6 (supposedly, I know it is not a major rewrite or anything, most likely Apple's PR sweet talk). We all agree that X11 has to evolve, as it has in fact been doing. There are going to be some trade-offs that will have to be made, trade-offs that will mean Linux will be able to do some nice new things, but no longer able to do others (tunneling is most likely to disappear, according to some "experts"). For one thing I really hope that there is still some separation between kernel and graphics systems as that is one of the biggest strengths of Linux and Unix-like systems. So while KMS is a neat thing to have, I really hope a sane distance is preserved between the graphics layer and the kernel/console layer.

[deanjo]

Indeed, my point is that Quartz was in development for a long time before OS X debuted in 2001, and it has been extended over the last 7 years, supposedly having a major rework for 10.6 (supposedly, I know it is not a major rewrite or anything, most likely Apple's PR sweet talk).


It's a pretty massive enhancement, not a complete rewrite that's for sure with more focus being put on openCL, Grand Central, and HD video acceleration (at least it wasn't when I left Apple a couple months back and the HD acceleration can be found on the new Macbook line). Still, linux will be playing catch up for a few years after 10.6 comes out.

[drag]

The applications ARE the same, even built from source on both platforms, and the options parsed by the PTS are also the same. The differences in the I/O tests, are not fault of the apps or the benchmarking tool to measure their performance, but rather how the individual systems handle the petitions being made by the applications (case in point, the SQL tests). What you are saying is more like comparing a BMW V8 engine to a Dodge HEMI engine. The HEMI can "shut off" four cylinders when they are not in use, hence being more fuel efficient, and may even have a bit of lag to power those up for when they're needed (acceleration lag, if you will). The BMW engine on the other hand, since all 8 cylinders are all active all the time, will not have said lag when accelerating[1]... Its inherent to the ENGINE, not the fuel used, or the road the cars are used.



Well actually the point of the benchmark is to remove the subjective element of the platform and try to approach it with a more 'scientific' bent.

Bonnie++ is a nice benchmarking tool and comparing file systems is very difficult. Much more difficult then it seems at first blush. Which is why, if your doing FS benchmarks, it's a necessity to see the configuration and full output from the application. It's not like benchmarking a application or a game were you have the same app on both systems.

Our goal here is not to benchmark the benchmarking application, but to measure the performance of the OSes relative to one another.

Lets see a little bit more into this:

So, and I don't know this for absolute certainty, that Mac OS X lies to you about whether or not a 'sync' ended successfully. But lets assume that it does.

The point of 'sync' or similar system calls is that the OS does it's best to make sure that your data is written out to the disk. This is important for a number of reasons, but mostly in case something bad happens to your system. It's a preventative measure that exists to protect your data.

So if the system is lying about what it's doing in order to make you think that it's faster then it really is, then it's putting your data at higher risk of corruption. That is unless there is some miracle of computer science that Apple figured out or whatnot.

That is.. if you didn't think your data was important enough to have a sync done correctly then what is the point of having sync in the first place and why use it at all?

-----------------------

And lets look at Bonnie++ again.


It's designed to do performance analysis of file systems and harddrives....

Most operating systems don't immediately write out data to your harddrive. This is because harddrives are very very slow and memory is fast. So if you can access and write data only to main memory then that's like having a SDRAM-based harddrive to access your data.

Of course if the power goes out, then that's lights out for your data; corrupted and gone forever in a few seconds. (hence the fsync/sync stuff)

So unless your using data sets that your sure are getting written to disk then your not really testing anything but memory access.


-----------------

To put it another way. Bonnie++ has, as one part of it's test, random data access benchmarks. So the idea is that it writes out a bunch of data then immediately begins to read it back in.

In real-world situations that sort of behavior is pretty pathological. It's fairly odd to write out data then immediately read in random bits of it. You may do it for a database or you may need to do it for editing videos or whatnot... but even then the likelihood that the data at some point gets flushed out to disk is very high. So what your really interested in knowing is how well does the file system deal with multi-user or multi-tasking performance, as well as application start up times, and that sort of thing. And most of those things involve reading in stale data from the disk and file systems. Most of those things involve using data sets larger then your main memory.

I mean at some point your going to be reading data randomly from a disk. No matter what. It's why you have a disk. So you want to know actually how well that performs. So unless bonnie++ actually writes out to disk then you have no way of knowing how the system is going to perform under those circumstances.


--------------------------

If that is to long to read.. then look at this way:

It's very easy to tune a system's performance to favor benchmark results. But the end users are going to have their performance sacrificed as a result because real-world usage rarely follows benchmarks, especially FS benchmarks. If you wanted real benchmarks then they would probably involve several weeks of testing per configuration. No fun, too expensive.

So bonnie++ can be useful and can provide useful information, but not when all you see is a couple graphs. That's not enough, unfortunately. Depending on what your actually testing different numbers can be configured.

For example maybe your goal is really testing file system cache performance. That's worthy goal and it may expose bugs or other issues. So you use small datasets and try to keep the benchmarks small enough that nothing gets written.

But for a end user that isn't as interesting as actual performance you'll get when reading or writing data to the drive, unless it's very bad or something.

[drag]

Oh, and I am open to Mac OS actually being faster then Linux in a lot of ways.

But I just need more information before I can really make a judgement call.

If I had Mac OS around right now I'd play with it and try to verify the articles' numbers, but I don't.

[deanjo]

Oh, and I am open to Mac OS actually being faster then Linux in a lot of ways.

But I just need more information before I can really make a judgement call.

If I had Mac OS around right now I'd play with it and try to verify the articles' numbers, but I don't.

Just as a FYI, sqlite does not use fsync for OS X's HFS+. It uses fullfsync. At that point if a write is not complete it's entirely the hd caches fault as it is what is reporting that the write is complete. You can easily verify this by looking at the os_unix.c file in sqlite. Why Apple created f_fullsync is simple, data integrety. Many SCSI/SATA drives do not support fsync (although claim that they do).

Right from OS X man page.

DESCRIPTION
Fsync() causes all modified data and attributes of fd to be moved to a
permanent storage device. This normally results in all in-core modified
copies of buffers for the associated file to be written to a disk.

Note that while fsync() will flush all data from the host to the drive
(i.e. the "permanent storage device"), the drive itself may not physi-
cally write the data to the platters for quite some time and it may be
written in an out-of-order sequence.

Specifically, if the drive loses power or the OS crashes, the application
may find that only some or none of their data was written. The disk
drive may also re-order the data so that later writes may be present
while earlier writes are not.

This is not a theoretical edge case. This scenario is easily reproduced
with real world workloads and drive power failures.

For applications that require tighter guarantess about the integrity of
their data, MacOS X provides the F_FULLFSYNC fcntl. The F_FULLFSYNC
fcntl asks the drive to flush all buffered data to permanent storage.
Applications such as databases that require a strict ordering of writes
should use F_FULLFSYNC to ensure their data is written in the order they
expect. Please see fcntl(2) for more detail.As far as the bonnie++ test goes, concern about the it not completing a write is addressed by using the -b option to force a write after every fsync() and a fsync of the directory after a file has been created or deleted. Not as an ideal solution as using fullsync as if the drive again doesn't support fsync() properly the potential for dataloss is still there.

That being all said, you can guarantee that the sqlite tests are accurate as far as OS X is concerned. If the the Ubuntu using fsync() in sqlite you do not have anywhere close to that assurance.

[glasen]

Hey Michael, will you please rerun the Ubuntu vs. Fedora Benchmark after this benchmark results?

I mean, the Mac Mini has nearly he same CPU (Core2Duo with 1.87Ghz, Mac Mini has more 2nd level cache) and the same amount of memory as your Lenovo T61 in the older tests and magically Ubuntu 8.10 gets results twice as fast as in the old tests. And they are nearly the same as the ones from Ubuntu 7.04 and 7.10.

Does now someone believe that the bad results of the older tests have nothing to do with "Ubuntu is getting slower!".

[Thetargos]

It's a pretty massive enhancement, not a complete rewrite that's for sure with more focus being put on openCL, Grand Central, and HD video acceleration (at least it wasn't when I left Apple a couple months back and the HD acceleration can be found on the new Macbook line). Still, linux will be playing catch up for a few years after 10.6 comes out.

I do think that what is needed in X (not only for Linux, but for any major Unix-like OS that relies on it for graphics [BSD, Irix, Solaris, etc]) is it has to undergo a serious and deep clean up process and optimization of old, convoluted and cumbersome routines that can be accelerated. I know that for the most part focus in this area (especially for the desktop) is in 3D and improved 2D acceleration and whatnot, and that this clean up and optimization of X doesn't necessarily mean to drop support for ancient hardware... Though it won't be an easy process. As far as I know, ever since the departure of pretty much all Linux distributions from XFree86, this clean up has been going on in Xorg, and while things have indeed improved, much more work is needed, and I'm sure that most of it is indeed underway, but it won't happen fast. It has been quite amazing how fast things have moved in the Free software end ever since there has been more focus on Linux on the desktop, maybe things will improve fast enough (then again, maybe not).


There are a number of things that simply won't happen in Linux, not in the traditional way, anyway, like HD video acceleration in the main Xorg tree, simply because 'HD' has implicit the use of DRM technology to "protect" the stream; however that doesn't mean that for example, Theora streams of 1920x1080 couldn't be accelerated on the graphics hardware (decoding, scaling, etc) and still be awesome. The problem with all things 'HD' is the vagueness of the freaking term. What is HD for one person may not be for another... For example, take the studios, for instance... HD would be any video stream of 856x480 and up (to 1920x1080), however for the studios 'HD' also mean that the content should be protected in some way, and hence implies the use of DRM, and the bulk of the consumers and even computer-oriented people, HD also implies certain formats (like BlueRay, AVC1, h264, WMVHD, etc), in short there's general confusion. So what if Xorg did support "HD" in XV and XVMC? Most likely would be in such a way, that not many would expect (like the afore mentioned Theora decoding support and scaling, etc)

Is good to see Apple push the envelope and bring a computer-centric solution to the whole media, HD and entertainment conundrum, after all that's pretty much the focus of their business nowadays. Let us hope that Linux desktops can also be part of a similar solution, or why not? Innovate upon the initiative.

[deanjo]

I do think that what is needed in X (not only for Linux, but for any major Unix-like OS that relies on it for graphics [BSD, Irix, Solaris, etc]) is it has to undergo a serious and deep clean up process and optimization of old, convoluted and cumbersome routines that can be accelerated. I know that for the most part focus in this area (especially for the desktop) is in 3D and improved 2D acceleration and whatnot, and that this clean up and optimization of X doesn't necessarily mean to drop support for ancient hardware... Though it won't be an easy process. As far as I know, ever since the departure of pretty much all Linux distributions from XFree86, this clean up has been going on in Xorg, and while things have indeed improved, much more work is needed, and I'm sure that most of it is indeed underway, but it won't happen fast. It has been quite amazing how fast things have moved in the Free software end ever since there has been more focus on Linux on the desktop, maybe things will improve fast enough (then again, maybe not).


There are a number of things that simply won't happen in Linux, not in the traditional way, anyway, like HD video acceleration in the main Xorg tree, simply because 'HD' has implicit the use of DRM technology to "protect" the stream; however that doesn't mean that for example, Theora streams of 1920x1080 couldn't be accelerated on the graphics hardware (decoding, scaling, etc) and still be awesome. The problem with all things 'HD' is the vagueness of the freaking term. What is HD for one person may not be for another... For example, take the studios, for instance... HD would be any video stream of 856x480 and up (to 1920x1080), however for the studios 'HD' also mean that the content should be protected in some way, and hence implies the use of DRM, and the bulk of the consumers and even computer-oriented people, HD also implies certain formats (like BlueRay, AVC1, h264, WMVHD, etc), in short there's general confusion. So what if Xorg did support "HD" in XV and XVMC? Most likely would be in such a way, that not many would expect (like the afore mentioned Theora decoding support and scaling, etc)

Is good to see Apple push the envelope and bring a computer-centric solution to the whole media, HD and entertainment conundrum, after all that's pretty much the focus of their business nowadays. Let us hope that Linux desktops can also be part of a similar solution, or why not? Innovate upon the initiative.

Your quite right when people often confuse HD playback with playback of DRM HD media. The thing is that there are plenty of other valid reasons for non DRM HD playback such as FTA HD recordings, personal HD camcorders, etc etc. The main concern for linux however is just the plain ability to play such non-DRM HD media with good results.

Accessing the AES engines on the cards should be a "I'm bored and have nothing else too do" after thought project or leave that up to the commercial software crews. (Although using that engine would be kind of cool for hooking into things like openSSL and such). The decryption actually takes very little cpu usage and shouldn't be a concern at all for the X crews. Let DVD Jon worry about that stuff. All X should be concerned about is providing a good standardized API to allow video playback to be offloaded to the GPU where it belongs.

[kraftman]

Still, linux will be playing catch up for a few years after 10.6 comes out.

You meant X, right? In many other things Mac OS just looks lame in comparison to Linux. In my opinion KDE4 just kills Mac OS desktop and that's what simple user sees. He doesn't know if system is using X or Quartz and it's meaningless for him. Can you explain me what's so cool in Quartz?

Many SCSI/SATA drives do not support fsync (although claim that they do).

Maybe drive in the benchmark does not support fsync and Ubuntu tryes to do it other way - by emulation etc. and that's why it's slow (but who knows if that was slow?)? Don't take it really serious it's just my simple thinking :>

Btw. I don't like Macs, but I write Mac OS. When I was younger I wrote mac os, windows and Linux. but it was funny.

@glasen

Ubuntu 8.10 is faster than previous versions in my opinion, so I recommend you to not take those results very seriously and have fun with your favourite system.

[deanjo]

You meant X, right? In many other things Mac OS looks just lame in comparison to Linux. In my opinion KDE4 just kills Mac OS desktop and that's what simple user sees. He doesn't know if system is using X or Quartz and it's meaningless for him. Can you explain me what's so cool in Quartz?

The statement was made in general towards X that is correct but also applies for the upcoming technologies that 10.6 is bringing such as Grand Central, openCL, hd acceleration etc. Things like multihead displays, 10,000 xorg configs are not needed in OS X. Plug and play. Even the video drivers are simply handled through OS updates. It's been like that from the start. Linux is just starting trying to enable such functionality and still has a ways to go. I'm sure the fact that the chipset had to use Mesa in linux did not help performance in the games as well.



Maybe drive in the benchmark does not support fsync and Ubuntu tryes to do it other way - by emulation etc. and that's why it's slow (but who knows if that was slow?)? Don't take it really serious it's just my simple thinking :>

Btw. I don't like Macs, but I write Mac OS. When I was younger I wrote mac os, windows and Linux. but it was funny.


Certain results of those test are extremely slow even when compared to other distro's. Notibly the sqlite and bonnie. Now I don't know if Michael did a clean install on both systems and did not dualboot which can attribute the slower results. Drive speeds are not consistant across platters, one would have to do a solo install of both to get good results. You don't like Mac OS, that's fine. Too many people tend to go into disbelief because of fanboyism and can't give credit where credit is due and rather come up with some other fanatical reason for the results.

[kraftman]

The statement was made in general towards X that is correct but also applies for the upcoming technologies that 10.6 is bringing such as Grand Central, openCL, hd acceleration etc. Things like multihead displays, 10,000 xorg configs are not needed in OS X. Plug and play. Even the video drivers are simply handled through OS updates. It's been like that from the start. Linux is just starting trying to enable such functionality and still has a ways to go. I'm sure the fact that the chipset had to use Mesa in linux did not help performance in the games as well.

Oh, so you're talking mainly about X related things. Xorg is no longer needed in many system configurations (it seems that you're years behind...). Using NVIDIA or AMD/ATI binary drivers Mesa probably has no influence on performance. I wonder if they replace that crap what they call file system or maybe they just give you little more those fine desktop effects?

You don't like Mac OS, that's fine. Too many people tend to go into disbelief because of fanboyism and can't give credit where credit is due and rather come up with some other fanatical reason for the results.

It's seems that you're fanboy, because you write "linux" and "Mac OS". That's one of the symptoms. I didn't saw too many Mac OS benchmarks, because people just benchmark more proffessional systems like Linux, FreeBSD and OpenSolaris. As far as I know Mac OS is just too lame - its crappy file system, security holes (firewall disabled by default - that's very meaningfull) etc. I'd love to find some MySQL and DNS benchmarks... You started talk about - how X is bad etc. This article is about something else, so stop trolling please.

[deanjo]

Oh, so you're talking mainly about X related things. Xorg is no longer needed in many system configurations (it seems that you're years behind...). Using NVIDIA or AMD/ATI binary drivers Mesa probably has no influence on performance. I wonder if they replace that crap what they call file system or maybe they just give you little more those fine desktop effects?

xorg has been needed until just recently. Mesa DOES have a huge factor in performance as well. Why do you think blobs bypass MUCH of X? The drivers that ubuntu DO use mesa for the intel chipset. Mesa is not used for OS X.



It's seems that you're fanboy, because you write "linux" and "Mac OS". That's one of the symptoms.
That is their names. I when I spell darwin in small letter too.

I didn't saw too many Mac OS benchmarks, because people just benchmark more proffessional systems like Linux, FreeBSD and OpenSolaris.As would be expected in a OS that has many years upon a OS that was not marketed for servers until recently


As far as I know Mac OS is just too lame - its crappy file system, security holes (firewall disabled by default - that's very meaningfull) etc. I'd love to find some MySQL and DNS benchmarks... Go right ahead. As far as firewall goes most people have a external firwall anyways whether it's through a router or modem. Glad you keep up with the times.


You started talk about - how X is bad etc. This article is about something else, so stop trolling please.FYI TheArgos brought up X, I commented and corrected him on a few things. So read the bloody thread before you start accusing of trolling. It seems you cannot keep up with the conversation.

Not a fanboy at all, I use pretty much every OS equally on a daily basis, they all have their weaknesses and strengths.

[kraftman]

xorg has been needed until just recently. Mesa DOES have a huge factor in performance as well. Why do you think blobs bypass MUCH of X? The drivers that ubuntu DO use mesa for the intel chipset. Mesa is not used for OS X.

Simply, Enemy Territory runs faster for me under Linux then under XP. It can be due to drivers, but that's why I think that mesa has no big influence to binary blobs (and NVIDIA does many things their way).

That is their names. I when I spell darwin in small letter too.

As would be expected in a OS that has many years upon a OS that was not marketed for servers until recently

So, we can say that Mac OS need years to catch up with Linux. I should add in server area, but you didn't say before what you meant.

Go right ahead. As far as firewall goes most people have a external firwall anyways whether it's through a router or modem. Glad you keep up with the times.

Many people don't. You can say what you want, but firewall disabled by default is little lame. Sorry for little off topic...

FYI TheArgos brought up X, I commented and corrected him on a few things. So read the bloody thread before you start accusing of trolling. It seems you cannot keep up with the conversation.

Not a fanboy at all, I use pretty much every OS equally on a daily basis, they all have their weaknesses and strengths.

I'm sometimes quite lazy, but you said that Linux needs years to catch up and that wasn't just correction. Btw. we can mention many arguments, but it usually leads to flame. I can agree that Quartz is probably much modern way than X to do some things, but as you said every OS has it's own advantages and disadvantages.

[deanjo]

Simply, Enemy Territory runs faster for me under Linux then under XP. It can be due to drivers, but that's why I think that mesa has no big influence to binary blobs (and NVIDIA does many things their way).


You best look at implementations of drivers on the same OS to draw that conclusion say firelgx vs radeonhd vs radeon and then take snapshots of the screens and do a differential comparision of them on the same frame.


So, we can say that Mac OS need years to catch up with Linux. I should add in server area, but you didn't say before what you meant.
Shouldn't have too as the topic has nothing to do with server editions of either OS neither did the tests. If Apple want's to play in the server market then, yes, there are areas they are behind as well. But that isn't a primary concern for them. OS X server is there to manage OS X networks. And it does that EXTREMELY well.


Many people don't. You can say what you want, but firewall disabled by default is little lame.
In YOUR opinion, others view having to disable and make exceptions in firewalls lame just to do simple filesharing


I'm sometimes quite lazy, but you said that Linux needs years to catch up and that wasn't just correction.
Take the bloody comment in context. Read before you type.


It's a pretty massive enhancement, not a complete rewrite that's for sure with more focus being put on openCL, Grand Central, and HD video acceleration (at least it wasn't when I left Apple a couple months back and the HD acceleration can be found on the new Macbook line). Still, linux will be playing catch up for a few years after 10.6 comes out.You started firing guns before you even thought about the comment.
which in the end you eventually agree with:


Btw. we can mention many arguments, but it usually leads to flame. I can agree that Quartz is probably much modern way than X to do some things, but as you said every OS has it's own advantages and disadvantages.

[kraftman]

You started firing guns before you even thought about the comment. which in the end you eventually agree with:

Someone else started. I thought that you won't continue. And even if I agree, I just don't like your way you said that.


Take the bloody comment in context. Read before you type.

It's not this comment that I was talking about...

You best look at implementations of drivers on the same OS to draw that conclusion say firelgx vs radeonhd vs radeon and then take snapshots of the screens and do a differential comparision of them on the same frame.

Why not compare NVIDIA binary driver under Linux and NVIDIA binary driver under Windows XP? It's more objective in my opinion and if I have little better result on Linux mesa doesn't slow down anything in this case as I mentioned before. You can be sure that screenshots using those binary drivers will look the same. It looks like you sometimes don't know what I'm talking about.

OS X server is there to manage OS X networks. And it does that EXTREMELY well.

I'd love to hear more about that and about Quartz, but you didn't said anything special.

[deanjo]

Someone else started. I thought that you won't continue. And even if I agree, I just don't like your way you said that.
Read the whole tread topic what does it say?


It's not this comment that I was talking about...
That is the exact quote you quoted.


Why not compare NVIDIA binary driver under Linux and NVIDIA binary driver under Windows XP? It's more objective in my opinion and if I have little better result on Linux mesa doesn't slow down anything in this case as I mentioned before. You can be sure that screenshots using those binary drivers will look the same. It looks like you sometimes don't know what I'm talking about.And what would that prove by using 2 drivers that do not use mesa?

You might want to read up here:

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



I'd love to hear more about that and about Quartz, but you didn't said anything special.I posted a link on Quartz and it's subsystems. If you can't be bothered to read it there then why bother?

[kraftman]

Read the whole tread topic what does it say?
That is the exact quote you quoted.

I thought about that: "Still, linux will be playing catch up for a few years after 10.6 comes out." I quoted other comment, because I was answering to some part of it.

And what would that prove by using 2 drivers that do not use mesa?

You said before: Mesa DOES have a huge factor in performance as well. Why do you think blobs bypass MUCH of X?

Maybe it will proove that you're wrong?

I posted a link on Quartz and it's subsystems. If you can't be bothered to read it there then why bother?

Sorry, but I don't see it... Btw. I'm not interested in Apple's sweet talk. I'd prefer to see real advantages of Quartz over X.

[deanjo]

I thought about that: "Still, linux will be playing catch up for a few years after 10.6 comes out." I quoted other comment, because I was answering to some part of it.

That is the only area where I even mentioned OS X being better.



Maybe it will proove that you're wrong?
Testing 2 non-Mesa drivers against each other in different OS doesn't prove squat when it comes to finding out if Mesa is the limiting factor or not.


Sorry, but I don't see it... Btw. I'm not interested in Apple's sweet talk. I'd prefer to see real advantages of Quartz over X.Look here:

http://developer.apple.com/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/chapter_2_section_1.html

http://developer.apple.com/documentation/GraphicsImaging/Quartz-date.html#//apple_ref/doc/uid/TP30000440-TP30000424-TP30000559

http://developer.apple.com/documentation/MacOSX/Conceptual/OSX_Technology_Overview/GraphicsTechnologies/chapter_4_section_2.html#//apple_ref/doc/uid/TP40001067-CH273-BBCEADBC

For a reasonable laymans guide although be it is missing some of the 10.5 changes:
http://arstechnica.com/reviews/os/macosx-10-4.ars/14

Keep in mind as well that compositing didn't have to be disabled on the mac. It doesn't effect games as it does on linux where it slows openGL games and such.

[Thetargos]

I think it is pertinent some comments about the graphics library and drivers used on both systems... And maybe illustrate a bit more how do graphics subsystems work on both platforms.

First Mesa Vs Binary Blobs

Mesa (http://www.mesa3d.org/intro.html) is an Open Source implementation (keyword for whatever other concepts exposed here after) of the OpenGL specification, that implicitly means that Mesa is NOT necessarily the same as OpenGL (just as Wine is not Windows, but an implementation of the WinAPI under Unix), and provides some of the functionality OpenGL does. OpenGL is very bureaucratic and is governed by a series of board members (ARB (http://en.wikipedia.org/wiki/OpenGL_Architecture_Review_Board)) who agree on a series of basic set of features and functionality the API and library has to provide. OpenGL is deployed on systems through the use of ICD (http://web.drzeus.cx/opengl/icd.html) (or Installable Client Driver) which usually gives the whole bunch of OpenGL functionality. This functionality by consensus is provided by a system library, the libGL.so library under Unix systems and OpenGL32.dll under Windows ; and a driver (ICD) which makes use of such library. More often than not, the drivers also include their own optimized implementation of the API as part of the ICD (i.e, their own libGL.so or OpenGL32.dll [or similar]) in order to provide optimized OpenGL rendering. What in fact is happening whenever you test the Open Drivers (Intel, ATi, Matrox, 3dfx, etc) under Linux/FreeBSD/OpenSolaris to any of the binary blobs (nVidia/ATi) is that you are actually comparing apples to oranges. These blobs are indeed an ICD, while the Open Drivers use Mesa as their OpenGL implementation. nVidia, ATi/AMD, Intel, SGI, Sun, Apple, Microsoft (they abandoned the ARB before Vista's release [and the OpenGL 2.0 specification release] IIRC, but I believe they're back), etc are actually members of the Architecture Review Board for OpenGL, what does this mean? Well, simply that the degree of performance you can expect to obtain from the implementation of any of these ARB members would be orders of magnitudes above Mesa (which is not an ARB member [though I believe there are special considerations towards Mesa]), then there is the degree of optimization that the driver coders can implement into the driver using Mesa (remember Mesa, even though implementing the whole OpenGL spec, may not be as optimized as an ARB member ICD).

This is why comparing Mesa Vs a proper ICD usually ends up resulting in Mesa being much slower, if not due to features or system optimization, due to the large number of device architectures that make use of it. And this is another differentiator between Mesa and OpenGL ICDs. Mesa does not require by itself (just as OpenGL doesn't either) to be hardware accelerated, for accelerating Mesa (and OpenGL in Linux) the DRI mechanism was devised. As it name implies the Direct Rendering Infrastructure seeks to attain direct hardware access for accelerating OpenGL through Mesa (or a vendor's ICD) and is where X is more involved in the acceleration process, since by itself X does much of its rendering in an indirect manner (which is part of the core of the problems that it now presents for more sophisticated rendering on the desktop, by the way) and so there are two extra components that help accelerate in hardware the rendering through direct access, the userland DRI library, and the kernel-side Direct Rendering Manager kernel module, responsible for direct I/O to the hardware parsing calls from the DRI library above (carrying Mesa GL commands along to the graphics hardware). This is an overly simplified explanation and I'm sure that any DRI/DRM developers will have a heart attack by reading my explanation of how this works [or I think it works]).

At any rate, a much more "fair" comparison would involve putting together a system that would match in hardware configuration and capabilities vis-a-vis comparable to the MacMini, however using another ICD OpenGL backend instead (like nVidia with an nVidia 7050 IGP or fglrx with an ATi HD3200/790G IGP), then the graphics comparison would be much more leveled (simply due to sheer OpenGL support)

The XServer Vs Quartz.

Again, overly simplified, as noted X11 was engineered to do indirect-over-the-network-through-sockets rendering, and it has excelled at that over the last 24 years. However this robustness, is its Achilles heel for fast desktop rendering. In a nutshell, the client-server (http://en.wikipedia.org/wiki/X_Window_System_protocols_and_architecture) architecture of X (which makes it network transparent (http://en.wikipedia.org/wiki/X_Window_System_core_protocol)) has the server running on the local computer, and clients (other machines, programs) connect to it for rendering, using network packets. This is rather convoluted (though it is very convenient for a lot of tasks such as mainframes and centralized rendering, etc), and that's where DRI (http://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure) comes in, it is a system to by pass the XServer and allow applications direct access to the graphics hardware instead. In this model the XServer is still the responsible for the rendering of the desktop, etc. From what I have been able to make out of Quartz (http://en.wikipedia.org/wiki/Quartz_(graphics_layer)) (or rather Core Graphics), in its design the render path is much faster as it indeed has direct access to the hardware through the Quartz compositor (kind of like the XServer) and Quartz Extreme (using OpenGL), and has been very much optimized through the use of SIMD instructions (AltiVec, SSE) and hardware acceleration (OpenGL).

The design and architecture of both rendering systems, though not mutually exclusive, do let you see the difference in applications they were thought for. Quartz was built from the ground-up to be a desktop rendering system, while X allows for more distributed rendering and seems to have been one of its original goals. It is not surprising that Apple decided to depart from X when they created OS X and built from scratch (well based on NextStep) Quartz and its compositor, to better suit the desktop needs. They indeed implemented X11, but instead of having X have its own server, it does render through Quartz as the server, providing the protocol and libraries for X client applications. I think that in Linux in the not so distant future, that is going to become the natural evolution for X, from an inherently indirect rendering nature, to a direct rendering one, and keeping backwards compatibility through support libraries. This transition (IMHO) started with the addition of Composite, Damages and other extensions which will have a more centric role in X... Still a LOT of work. What would be better, allow X to naturally transition, or have another renderer like Wayland provide X11 compatibility through a mechanism similar to Mac OS X's Quartz? I don't know, and most likely both systems will coexist for some time before a decision is made in what direction Linux on the desktop is taken.

PS Sorry for the long post.

[deanjo]

PS Sorry for the long post.

No need to apologize +10 on the post. You hit the key points right on the head.

[kraftman]

That is the only area where I even mentioned OS X being better.

You didn't mentioned in that comment what area you were talking about and that's why I replied (sic!).

Testing 2 non-Mesa drivers against each other in different OS doesn't prove squat when it comes to finding out if Mesa is the limiting factor or not.

So, why you asked: Why do you think blobs bypass MUCH of X? If those drivers aren't using mesa? Man, you're amazing me, but it doesn't matter...


I asked for non Apple's link, but thanks. In this case they're probably objective.

@Thetargos

Thanks for this exhaustive comment :).

[deanjo]

So, why you asked: ? If those drivers aren't using mesa? Man, you're amazing me, but it doesn't matter...


The blobs don't use mesa that's why.

[Thetargos]

So, why you asked: ? If those drivers aren't using mesa? Man, you're amazing me, but it doesn't matter...
No, they don't. They use the ICD approach, providing themselves the GL library, why do you think you have a different libGL with the nVidia and fglrx drivers? ;); and the GL library usually conflicts with the Mesa library included in most systems, and distribution packages manage to keep both libraries, making the proprietary GL library visible to the applications, but not breaking the installed Mesa package.


I asked for non Apple's link, but thanks. In this case they're probably objective.
And I provided those ;) Granted, I know not many give the same credit to the Wikipedia, but stillf or computing topics their articles are usually very well done.


@Thetargos

Thanks for this exhaustive comment :).

You are welcome... It took me some three hours to post (as I wanted to make sure all my info was right ;))

[unlotto]

I'm confused... didn't ubuntu x86_64 win most of the tests?

Why the dissappointment with the ubuntu results, that some of the posts here express?
The Nexuiz tests on intel graphics are not interesting to me.
sqlite test is important. Most sane people would use noatime or relatime, which should have dramatic results.

I would love to see someone with similar/identical hardware post some PTS global links with different configurations/distros for comparison. Also, GNU/Linux is as much about choice as anything else - having the most default setup beat osx is just an added bonus.

[deanjo]

I'm confused... didn't ubuntu x86_64 win most of the tests?

Why the dissappointment with the ubuntu results, that some of the posts here express?
The Nexuiz tests on intel graphics are not interesting to me.
sqlite test is important. Most sane people would use noatime or relatime, which should have dramatic results.

I would love to see someone with similar/identical hardware post some PTS global links with different configurations/distros for comparison. Also, GNU/Linux is as much about choice as anything else - having the most default setup beat osx is just an added bonus.

Some people are just ticked OS X beat ubuntu in i/o limited and graphics tests. Compilation tests don't mean much either as different libraries and options will be different on both systems. One has to compile more the other doesn't.

[kraftman]

Some people are just ticked OS X beat ubuntu in i/o limited and graphics tests. Compilation tests don't mean much either as different libraries and options will be different on both systems. One has to compile more the other doesn't.


I/O limited and graphics tests don't mean much either in Phoronix test. You look like MACOS fanboy to me.


The blobs don't use mesa that's why.

Read 100x times more and maybe you will understand what I meant...

[deanjo]

I/O limited and graphics tests don't mean much either in Phoronix test. You look like MACOS fanboy too me.
I give credit were credit is due with a deep understanding of the issues not based on "brand X sucks" without having a clue about the subject.



Read 100x times more and maybe you will understand what I meant...
Maybe perhaps make your comments in a clear, concise manner that doesn't require filling in of the blanks and you will be more pleased with the answers. As it stands , you don't even seem to understand what uses mesa and what uses a optimized ICD.

[kraftman]

I give credit were credit is due with a deep understanding of the issues not based on "brand X sucks" without having a clue about the subject.

You sound really funny :> You're just Mac OS fanboy (wait, you're dev probably) and you try to defend it. Luckily some people understand those issues and they're objective in their clues. I don't expect that Apple dev will be objective...

Maybe perhaps make your comments in a clear, concise manner that doesn't require filling in of the blanks and you will be more pleased with the answers. As it stands , you don't even seem to understand what uses mesa and what uses a optimized ICD.

It was clear, but due to your misunderstanding it has complicated a little. I was talking about something else... Simple question: do binary blobs use mesa (NVIDIA driver especially)? I want to hear it from you and it will be great if you just say: yes or no.

[kraftman]

Here's a great article about tunning EXT3 file system:

http://www.heise-online.co.uk/open/Tuning-the-Linux-file-system-Ext3--/features/110398/0

[deanjo]

You sound really funny :> You're just Mac OS fanboy (wait, you're dev probably) and you try to defend it. Luckily some people understand those issues and they're objective in their clues. I don't expect that Apple dev will be objective...

I develop for many OS's windows, *nix, osx. Currently coding satellite control systems.



It was clear, but due to your misunderstanding it has complicated a little. I was talking about something else... Simple question: do binary blobs use mesa (NVIDIA driver especially)? I want to hear it from you and it will be great if you just say: yes or no.
No the blobs do not use mesa.

[kraftman]

No the blobs do not use mesa.

So, that's probably why blobs bypass MUCH of X :> You asked me before why I think so.

I wonder what journaling options were used during the tests. It seems that it matters a lot:

http://www-128.ibm.com/developerworks/linux/library/l-fs8.html

Theoretically, data=journal mode is the slowest journaling mode of all, since data gets written to disk twice rather than once. However, it turns out that in certain situations, data=journal mode can be blazingly fast.

Somehow, ext3's data=journal mode is incredibly well-suited to situations where data needs to be read from and written to disk at the same time.

[deanjo]

So, that's probably why blobs bypass MUCH of X :> You asked me before why I think so.

I wonder what journaling options were used during the tests. It seems that it matters a lot:

http://www-128.ibm.com/developerworks/linux/library/l-fs8.html

Heh, did you take a look at the date on that article? Ext3 is not known for it's speed nowdays. Ars technica did a good breakdown of the filesystems out there a while back.

http://arstechnica.com/articles/paedia/past-present-future-file-systems.ars/1

There is also a good debian paper.

http://www.debian-administration.org/articles/388

To quote the ars article:

Despite valiant attempts to establish ReiserFS as a new standard, and the measurable superiority of systems like XFS, most Linux users are still using ext3. ext3 is not new. It's not super fast. It's not sexy. It won't cook your dinner. But it is tried and true, and for many people, that is more important.

[kraftman]

Heh, did you take a look at the date on that article? Ext3 is not known for it's speed nowdays. Ars technica did a good breakdown of the filesystems out there a while back.

http://arstechnica.com/articles/paedia/past-present-future-file-systems.ars/1

There is also a good debian paper.

http://www.debian-administration.org/articles/388

To quote the ars article:

Yes, but maybe that's why those tricks aren't obsolete ;) In some benchmarks EXT3 outperforms XFS. And in comparison to that what Leopard has as its file system EXT3 is superior.

Here are some tests:
http://marc.info/?t=104401945100002&r=1&w=2

EDIT:

Probably that is correct use of bonnie++ benchmark:

http://home.comcast.net/~jpiszcz/benchmark/allfs.html

[deanjo]

Yes, but maybe that's why those tricks aren't obsolete ;) In some benchmarks EXT3 outperforms XFS. And in comparison to that what Leopard has as its file system EXT3 is superior.


Yes, it all depends on alot of factors. A properly tuned XFS filesystem though a majority of the time outperform ext3 quite readily. A good guide to being tuning can be found here:

http://everything2.com/index.pl?node_id=1479435

You keep saying that ext3 is superior to HFS+ but you still have not said why. On what grounds are you basing this? Also without knowing the the environment and switches used for the bonnie++ benchmark, those results have to be taken with a grain of salt. We do not know for example on those results:

Was the partitions on the same area of the area of the drive? Location of the partition can greatly vary results.
What block sizes were used on the partition?
If it was a raid, what type of raid? Chunk size? What stripe size was used? If raid 5 what parity algorithm was used?
Is barriers being used?
etc.
All these items can cause a system's I/O results to vary greatly.

[kraftman]

Yes, it all depends on alot of factors. A properly tuned XFS filesystem though a majority of the time outperform ext3 quite readily. A good guide to being tuning can be found here:

http://everything2.com/index.pl?node_id=1479435


Thanks, I have to try XFS.


You keep saying that ext3 is superior to HFS+ but you still have not said why.

Because EXT3 don't emulate POSIX like HFS+.

EDIT:

And HFS+ is case insensitive. I couldn't believe.

Also without knowing the the environment and switches used for the bonnie++ benchmark, those results have to be taken with a grain of salt.

What matters in link that I posted is only size of used file. You're completely right.

[deanjo]

Because EXT3 don't emulate POSIX like HFS+.

EDIT:

And HFS+ is case insensitive. I couldn't believe.


Because HFS+ supports POSIX and ACL's is a bad thing? You really might want to read http://developer.apple.com/technotes/tn/tn1150.html for detailed information on HFS+ You will see that HFS+ has evolved quite readily over the revisions.

You have the option of using case sensitive if you want. Unfortunately POS companies like Adobe CS3 live in the stone ages and can't install and run on anything but a case insensitive drive.

[kraftman]

Because HFS+ supports POSIX and ACL's is a bad thing? You really might want to read http://developer.apple.com/technotes/tn/tn1150.html for detailed information on HFS+ You will see that HFS+ has evolved quite readily over the revisions.

It's very good thing if it is native. I don't trust Apples talk, because they put marketing bullshit everywhere. They even delete post on their forum - funny Blue Screen of Death incident in Leopard :).

You have the option of using case sensitive if you want. Unfortunately POS companies like Adobe CS3 live in the stone ages and can't install and run on anything but a case insensitive drive.

I heard about problems with CS3, but maybe just insensitive drives are from stone age? ;)

[deanjo]

kraftman, those are developer papers, not marketing papers. If you don't trust those then you shouldn't read 99.9% of technical info out there as they all originate and derived from technical papers from the original documentation. If you would read the article you would see where your error is. OS X 10.5 is 100% SUSv3 and 1003.1 compliant.

And again, HFS+ can do case sensitive, that's not a problem, the 3rd party developers on the other hand is where the issue is. Companies like Adobe are painfully slow to adopt.

[kraftman]

kraftman, those are developer papers, not marketing papers. If you don't trust those then you shouldn't read 99.9% of technical info out there as they all originate and derived from technical papers from the original documentation. If you would read the article you would see where your error is. OS X 10.5 is 100% SUSv3 and 1003.1 compliant.

And again, HFS+ can do case sensitive, that's not a problem, the 3rd party developers on the other hand is where the issue is. Companies like Adobe are painfully slow to adopt.

Alright. Thanks for explanation :)