Originally posted by Pesho
View Post
Announcement
Collapse
No announcement yet.
Mac OS X 10.5 vs. Ubuntu 8.10 Benchmarks
Collapse
X
-
Michael Larabel
https://www.michaellarabel.com/
-
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.
Comment
-
Originally posted by hdas View Post(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.
Comment
-
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.
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.
Comment
-
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.
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.
Comment
-
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.
Comment
Comment