Last month we reported on the 200 line Linux kernel patch that does wonders for improving the desktop responsiveness of the system. There was certainly much interest (over 100,000 views to both of our YouTube videos demonstrating the change) but this patch really didn't speed up the system per se but rather improved the desktop interactivity and reduced latency by creating task-groups per TTY so that the processes had more equal access to the CPU. There is though an entirely different patch-set now beginning to generate interest among early adopters that does improve the kernel performance itself in compute and memory intensive applications and it's the Transparent Hugepage Support patch-set. Here are our initial tests of the latest kernel patches that will hopefully be finding their way into the mainline Linux kernel soon.
Earlier this week I noted there's new Apple hardware in our labs being used to tighten up our Mac OS X support within the Phoronix Test Suite, OpenBenchmarking.org, Phoromatic, etc. However, in the middle of working on Iveland, I have been carrying out a few Mac OS X benchmarks comparing its performance under the 2010 Apple Mac Book Pro to other operating systems. With the Core i5 notebook being much faster than the past Apple Mac Minis used in comparisons like looking at their enhanced OpenGL stack and benchmarking Mac OS X against Linux and Windows 7, the results are more interesting and there's also a greater variety of testing possibilities now with the recent Phoronix Test Suite advancements. Next week there are some very interesting Apple-related benchmarks to be published, but before the weekend here are a few tests from this Apple Mac Book Pro looking at its power consumption under Mac OS X 10.6.5 and Ubuntu 10.10.
There is the first beta release of the Adobe 10.2 Flash Player now available for Microsoft Windows, Apple Mac OS X, and Linux platforms that brings a variety of improvements since the Flash Player 10.1 release from earlier this year. For Linux users this Adobe Flash update is quite important since it finally delivers GPU-based video acceleration support via their new Stage Video technology that is now supported on all platforms. Adobe's Stage Video offloads the entire video process to the GPU and in this article are some initial tests illustrating the benefits of this Flash update for Linux users.
A few weeks ago there were benchmarks of GCC, LLVM-GCC, DragonEgg, and Clang. In this compiler performance comparison the releases of GCC 4.2, 4.3, 4.4, 4.5, and a 4.6 development snapshot were benchmarked. On the LLVM side there was LLVM-GCC 4.2, DragonEgg with GCC 4.5 and LLVM 2.8, and then Clang with LLVM 2.8. This combination of eight open-source compilers were tested on three distinct Intel and AMD systems (even a 12-thread Core i7 Gulftown), but all of which were 64-bit capable and contained relatively high-end processors from their respective series. To complement this earlier article, available now are some new GCC/LLVM benchmarks but this time an older Intel Atom CPU was used to look at the 32-bit compiler performance on a slower, low-power netbook.
When Wayland started out in 2008 it was very difficult to build and run this lightweight, next-generation display server. Wayland leverages the very latest Linux graphics technologies and at that time all of Wayland's dependencies had to be patched or built from branched sources and Wayland even had its own EGL implementation at the time (Eagle) rather than Mesa and overall it was just a high barrier to entry. Wayland at that time also worked with only the open-source Intel driver, while now it can work with most any KMS / GEM / Mesa driver. It was not until recently that it became possible to build Wayland from mainline components beginning to ship in new Linux distributions, thereby making it much easier to experiment with the open-source display server. Now it's to a point where you can just run a simple script and be up and running with a Wayland Display Server in just minutes.
When publishing ATI Gallium3D benchmarks this week that compared the performance of the Radeon HD 4870 and Radeon HD 5770 graphics cards with this next-generation driver architecture to the classic open-source Mesa driver and AMD's high-performance proprietary Catalyst driver, the results were what one would mostly expect. The Gallium3D driver was faster than the classic Mesa driver in most tests, but both drivers seriously lagged behind the proprietary driver. Even on older generation ATI Radeon graphics cards this is the case. This though has led many to effectively ask, "what's keeping the open-source drivers from performing like the proprietary driver?" It all comes down to low-level optimizations as is discussed in this Phoronix Forums thread. There are very large development teams for the different Catalyst driver components within AMD and much of this work is shared across all platforms, but on the open-source Linux side there's very few paid full-time developers and just a number of part-time, community developers to cover the entire driver stack.
In August we delivered the news that Linux was soon to receive a native ZFS Linux kernel module. The Sun (now Oracle) ZFS file-system has long been sought after for Linux, though less now since Btrfs has emerged, but incompatibilities between the CDDL and GPL licenses have barred such support from entering the mainline Linux kernel. There has been ZFS-FUSE to run the ZFS file-system in user-space, but it comes with slow performance. There has also been work by the Lawrence Livermore National Laboratories in porting ZFS to Linux as a native Linux kernel module. This LLNL ZFS work though is incomplete but still progressing due to a US Department of Energy contract. It is though via this work that developers in India at KQ Infotech have made working a Linux kernel module for ZFS. In this article are some new details on KQ Infotech's ZFS kernel module and our results from testing out the ZFS file-system on Linux.
Last month I said what OpenBenchmarking.org is and how it should change the benchmarking / automated testing landscape once it's released in conjunction with Phoronix test Suite 3.0 "Iveland" early next year. I have also showed off the new graphing capabilities for this software and provided another update at the end of last month. Here now is another update with some more exciting details.
In recent weeks and months there has been quite a bit of work towards improving the responsiveness of the Linux desktop with some very significant milestones building up recently and new patches continuing to come. This work is greatly improving the experience of the Linux desktop when the computer is withstanding a great deal of CPU load and memory strain. Fortunately, the exciting improvements are far from over. There is a new patch that has not yet been merged but has undergone a few revisions over the past several weeks and it is quite small -- just over 200 lines of code -- but it does wonders for the Linux desktop.
Now that the Linux 2.6.37 kernel merge window is closed and this next major release is in the middle of its development cycle, we have new benchmarks to publish looking at the file-system performance of Btrfs and EXT4 compared to earlier releases. The Linux file-system performance is under constant evolution as shown by our five years of Linux kernel benchmarks and more recent file-system-focused articles such as looking at EXT4 and Btrfs regressions in Linux 2.6.36, solid-state drive Linux benchmarks, and even ZFS-FUSE benchmarks, among other similar articles.
LLVM 2.8 was released last month with the Clang compiler having feature-complete C++ support, enhancements to the DragonEgg GCC plug-in, a near feature-complete alternative to libstdc++, a drop-in system assembler, ARM code-generation improvements, and many other changes. With there being great interest in the Low-Level Virtual Machine, we have conducted a large LLVM-focused compiler comparison at Phoronix of GCC with versions 4.2.1 through 4.6-20101030, GCC 4.5.1 using the DragonEgg 2.8 plug-in, LLVM-GCC with LLVM 2.8 and GCC 4.2, and lastly with Clang on LLVM 2.8.
While we have conducted studies related to the Linux kernel performance in the past such as benchmarking up to twelve kernel releases, going out the door this morning are the results from the largest-ever Linux kernel comparison conducted at Phoronix, and very likely the largest ever of its kind regardless of source. Every major Linux kernel release from Linux 2.6.12, which was released in mid-2005, up through the latest Linux 2.6.37 development code was tested. This represents the past five years of the Linux kernel and shows how the performance has evolved over the past 25 stable kernel releases and the most recent 2.6.37 development kernel.
Phoronix Test Suite 3.0 (codenamed "Iveland") has been under heavy development for more than a month and there is still at least three more months left of work before this major release will be christened. Today though it is time to publicly share the first details (aside from those that learned about it in the Augustiner tent at Oktoberfest) for one of the new components to be making up a critical piece of the Phoronix Test Suite 3.0 platform: OpenBenchmarking.org.
With three laptops representing different generations of mobile hardware, we loaded up the past four stable releases of Fedora Linux plus the most recent Fedora 14 Alpha release and then carried out an arsenal of tests looking at how the battery power consumption rate has changed since 2008. If you are concerned at all about running Linux on your battery-powered mobile devices, this article is worth reading.
It's a pity Luca Barbieri or any Mesa / Gallium3D developers are not at Oktoberfest as they are deserving of more than a few Maß of Augustiner. In fact, today a new Gallium3D state tracker was pushed into Mesa and it's perhaps the most interesting state tracker for this open-source graphics driver architecture yet. It's a state tracker that exposes Microsoft's DirectX 10/11 API on Linux! And it's already working and can be hooked into Wine!
Earlier this month we started once again our annual Linux Graphics Survey in which we poll our readers about their choices and opinions concerning graphics cards, display drivers, and other graphics / X.Org related features of the Linux desktop. While this survey is still going on through the end of September -- so you still have time to participate -- here are the results from the first 6,300 people to submit their responses. We are publishing the results so far since there is the X Developers' Summit this week in Toulouse and some of these findings may prove to be useful during those discussions.
Recently when benchmarking the Btrfs and EXT4 file-systems we were left surprised that the performance of the next-generation Btrfs file-system had regressed against EXT4 to the point where the evolutionary file-system is measurably faster in a greater number of disk benchmarks. In fact, even with solid-state drives and Btrfs offering an SSD optimized mode, it still conceded to EXT4. It turns out that in the Linux 2.6.35 kernel, Btrfs regressed. This regression should have been fixed with the Linux 2.6.36 kernel, but recently when benchmarking EXT4/Btrfs against ZFS-FUSE on a 2.6.36 development snapshot we found its performance to still be poor for Btrfs compared to EXT4. To confirm where these two most prominent Linux file-systems are at right now, we have new EXT4 and Btrfs performance results from the Linux 2.6.34, 2.6.35, and 2.6.36-rc3 kernels.
The Q3'2010 update to the Phoronix Test Suite introduces new test profiles, provides new analytics capabilities, supports testing under a more diverse selection of hardware and software, and provides numerous other features for those looking to deploy this leading automated testing platform within enterprise environments.
Last week we reported that a native ZFS implementation for Linux is soon being released that is based upon the work by Lawrence Livermore National Laboratory to bring Sun's ZFS file-system to Linux as a CDDL-licensed kernel module. As said though in that article, there is already a ZFS module for FUSE (File-system in User-space) that is already available and with it not living in the GPL-land of the Linux kernel, it is legally allowed, but it does not come without some performance overhead. Over the weekend though there's been some discussions in the related forum thread and elsewhere about the dependability of ZFS-FUSE and what the level of impact on using FUSE really amounts to in real-world usage. We have tested the ZFS-FUSE -- both the latest stable and Git snapshots -- and have compared this alternate ZFS Linux implementation to that of the native EXT4 and Btrfs.
Earlier this month we delivered benchmarks comparing the ZFS, EXT4, and Btrfs file-systems from both solid-state drives and hard drives. The EXT4 file-system was the clear winner in terms of the overall disk performance while Btrfs came in second followed by Sun's ZFS in FreeBSD 8.2. It was a surprise that in our most recent testing the EXT4 file-system turned around and did better than the next-generation Btrfs file-system, but it turns out that Btrfs regressed hard in Linux 2.6.35 as to be found in Ubuntu 10.10 and other soon-to-be-released distributions. However, regardless of where Btrfs is performing, its speed can be boosted by enabling its transparent zlib compression support.
Prior to the emergence of Btrfs as a viable next-generation Linux file-system, Sun's ZFS file-system was sought after for Linux due to its advanced feature-set and capabilities compared to EXT3 and other open-source file-systems at the time. While ZFS support has worked its way into OpenSolaris, FreeBSD, NetBSD, and other operating systems, ZFS had not been ported to Linux as its source-code is distributed under the CDDL license, which is incompatible with the GNU GPL barring it from integration into the mainline Linux kernel. Next month, however, a working ZFS module for the Linux kernel without a dependence on FUSE will be publicly released.
While we benchmark the latest Linux kernel code on a daily basis at kernel-tracker.phoromatic.com using our automated testing platform built on the Phoronix Test Suite, now that the Linux 2.6.35 kernel was released, we have run a formalized set of kernel benchmarks on a ThinkPad W510 notebook with an Intel Core i7 CPU to see how the Linux 64-bit kernel is running with this high-end notebook under the Linux 2.6.32, 2.6.33, 2.6.34, and 2.6.35 releases.
ZFS is often looked upon as an advanced, superior file-system and one of the strong points of the Solaris/OpenSolaris platform while most feel that only recently has Linux been able to catch-up on the file-system front with EXT4 and the still-experimental Btrfs. ZFS is copy-on-write, self-healing with 256-bit checksums, supports compression, online pool growth, scales much better than the UFS file-system commonly used on BSD operating systems, supports snapshots, supports deduplication, and the list goes on for the features of this file-system developed by Sun Microsystems. In this article we are seeing how well the performance of the ZFS file-system under PC-BSD/FreeBSD 8.1 stacks up to UFS (including UFS+J and UFS+S) and on the Linux side with EXT4 and Btrfs.
As was mentioned in last Friday's article, Which Is Faster: Debian Linux or FreeBSD, tests of FreeBSD atop the ZFS file-system (rather than UFS2+S) are currently underway and those results are expected to be published in full later this week as the ZFS disk performance is compared directly to UFS2+S, UFS2+J, and also Ubuntu Linux with the EXT4 and Btrfs file-systems. Today though we have a few ZFS performance numbers to share as we look at the performance of the new CAM-ATA sub-system on FreeBSD.
In previous articles I have hinted that at Phoronix we are working to take advantage of the Btrfs file-system within the Phoronix Test Suite and Phoromatic to provide an interesting feature that will further expand our automated testing capabilities, but how does this file-system come into play? Well, here is what's being worked on and it should be of terrific value to many people.
Three years ago Intel had released PowerTop, an open-source utility for Linux that would analyze how well your laptop was conserving power and would allow users to easily tune their system for maximum battery life via simple power optimizations. By simply running this utility, some users were able to significantly extend their battery life. However, is this utility still useful and needed with a modern Linux desktop? The most recent release of PowerTop (v1.11) was a year and a half ago, so we are seeing how well PowerTop is still able to reduce the power consumption of Intel notebooks/netbooks running Linux.
Yesterday we reported that Ubuntu 10.10 gained Btrfs installation support and since then we have been trying out this Btrfs support in Ubuntu "Maverick Meerkat" and have a fresh set of Btrfs benchmarks to serve up.
Last month we looked at the cost of running Compiz by means of looking at how the window manager affected the frame-rate of several different games and whether compositing was used. We also tested out several different drivers and pieces of hardware. When Compiz was running rather than GNOME's Metacity it often caused a measurable drop in the OpenGL performance and then we later found this to be the case too with KDE's KWin. Today we are seeing if and how using Mutter, the window manager for the GNOME 3.0 desktop that uses Clutter-based compositing, will affect the performance of several different open-source games.
With MeeGo using Btrfs by default, Canonical making plans for Btrfs in as soon as Ubuntu 10.10, and Novell now pushing Btrfs in openSUSE, among other milestones for this advanced Linux file-system, we decided to see where the Btrfs performance is now at with the Linux 2.6.35 kernel that's currently in development. We compare the Btrfs performance to EXT4 and see how some of the different mount options are affecting the file-system's performance in different benchmarks.
For the past six months we have been monitoring the performance of the very latest Linux kernel code on a daily basis across multiple systems. We have spotted a few regressions -- both positive and negative -- on occasion using our automated daily testing of the Linux kernel, but nothing like what we have encountered the past few days: the Linux 2.6.35 kernel performance has fallen hard. In fact, the performance has fallen very hard in a number of tests and right now, we would consider it a disaster. While the 2.6.35 code has not even seen its first release candidate yet, there are some massive performance drops in a variety of different tests that have yet to be corrected and nothing like we have encountered with previous kernel release cycles especially for a regression that has lived now for about one week.
537 software articles published on Phoronix.