Sandy bridge, Ivy bridge, Haswell and the mess of Intel processors feature list

Written by Gionatan Danti on . Posted in Hardware analysis

User Rating:  / 36

Current microprocessors are very complex beasts. To develop an high-performance CPU architecture, you not only need many very smart engineers, but much time (3-5 years) and money (in the order of billions $$$). Moreover, bleeding-edge fabrication plants are incredibly expensive, and they must be continuously upgraded to newer process technologies.

So, it is perfectly understandable that both AMD and Intel (the two main x86 players) try to differentiate they offer, selling processors that spans from 50$ to ~1000$, a range of about 20X. While they want to sell you the most high-price (and high-margin) processors, they also realize that, as the market is very cost-sensitive, the bulk of R&D and production costs must be spread over a very large, low-profit product base. On top of that, all their processors must perform at least decently, or user will loudly complain (hello, Atom users!).

Linux I/O schedulers benchmarked - anticipatory vs CFQ vs deadline vs noop

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 22

In this era of multi-core, multi-gigaherz CPUs, traditional platter-based hard disks remain the “weak link” of modern machines. And they are here to stay: while SSDs are rapidly evolving and their prices are dropping, the cost per GB of storage space offered by HDDs is simply unmatched by their flash brothers.

The work of the I/O scheduler, a key component of every operating system, is precisely to extract as much juice as possible from these aging HDDs. Linux has not only one or two, but no less then four I/O schedulers at your disposition. Here is a brief explanation of these schedulers (taken from this Red Hat article):

  • the Anticipatory scheduler introduces a controlled delay before dispatching the I/O to attempt to aggregate and/or re-order requests improving locality and reducing disk seek operations. This algorithm is intended to optimize systems with small or slow disk subsystems;
  • the Completely Fair Queuing (CFQ) scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests;
  • the Deadline scheduler uses a deadline algorithm to minimize I/O latency for a given I/O request;
  • the Noop scheduler is a simple FIFO queue, and it assumes performance of the I/O has been or will be optimized at the block device.

OpenJDK vs OracleJVM: a look at Java performance under RedHat 6.3 with SPECjvm2008

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 16

"Write once, run anywhere" is the "holy grail" and hidden dream of any developer that has to support multiple platforms and operating systems.

While many programming languages and associated virtual machines attempt to solve this problem, Java + JVM is one of the best know (and best performing) multi-platform software stack. It evolved from a sub-performing, very slow interpreter-based solution to a fast JIT-based, reliable and secure system.

As other multi-platform languages, Java first compile itself in an intermediate state know as "bytecode". This bytecode is then executed by the real machine compiler, the Java Virtual Machine (JVM in short). So, it become clear that a good JVM is crucial to obtain high performances from your Java code.

BTRFS, mount options and virtual machines: an in-depth look

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 12

As you known, BTRFS is the new, full-featured filesystem being developed for Linux. While BTRFS  remain marked as “experimental”, it catalyze much attention in the filesystem community due to its impressive feature lists, relentless development and performance promises.

Speaking about performances, however, it seems that BTRFS has some significant problems, especially with database files and virtual machine images. With the latter, BTRFS speed is so low [1] that the official KVM tuning guide advise against using it [2].

Linux software RAID 10 layouts performance: near, far and offset benchmark analysis

Written by Gionatan Danti on . Posted in Linux & Unix

User Rating:  / 29

In common scenarios, storage subsystem speed represents a significant performance bottleneck: classical electromechanical disks are very good at areal density and sequential read/write speed, but they are terribly slow at random and/or mixed read/write operations. Moreover, being  electromechanical devices, normal hard-disks are quite prone to failures and malfunctions.

While SSD (and even more expensive RAM-DRIVE) significantly addresses this problem, the reality is that platter-based disks are currently the dominant storage media, and this situation will hardly change in the following 3-5 years.

In order to increase performances and reliability, many servers/workstations/NAS combine, in differnt fashion, multiple disks into single logical drives. This multi-disk-for-a-volume schema is called RAID – Redundant array of independent (or inexpensive) disks. You can read more on the subject here and here.