document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-25 00:50:15 +08:00
Code Issues Packages Projects Releases Wiki Activity

20140624-1 选题

Browse Source
This commit is contained in:
DeadFire 2014-06-24 16:19:51 +08:00
parent b4f34be467
commit eb843774f5
4 changed files with 236 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
sources/talk/20140624 Performance benchmarks--KVM vs. Xen.md Normal file
View File

@ -0,0 +1,94 @@
Performance benchmarks: KVM vs. Xen
================================================================================
After having some interesting discussions last week around KVM and Xen performance improvements over the past years, I decided to do a little research on my own. The last complete set of benchmarks I could find were from the [Phoronix Haswell tests in 2013][1]. There were [some other benchmarks from 2011][2] but those were hotly debated due to the Xen patches headed into kernel 3.0.
The 2011 tests had a [good list of benchmarks][3] and I’ve done my best to replicate that list here three years later. I’ve removed two or three of the benchmark tests because they didn’t run well without extra configuration or they took an extremely long time to run.
### Testing environment ###
My testing setup consists of two identical SuperMicro servers. Both have a single [Intel Xeon E3-1220][4] (four cores, 3.10GHz), 24GB Kingston DDR3 RAM, and four Western Digital RE-3 160GB drives in a RAID 10 array. BIOS versions are identical.
All of the tests were run in Fedora 20 (with SELinux enabled) for the hosts and the virtual machines. Very few services were left running during the tests. Here are the relevant software versions:
- Kernel: 3.14.8
- For KVM: qemu-kvm 1.6.2
- For Xen: xen 4.3.2
All root filesystems are XFS with the default configuration. Virtual machines were created using virt-manager using the default configuration available for KVM and Xen. Virtual disks used raw images and were allotted 8GB RAM with 4 virtual CPU’s. Xen guests used [PVHVM][5].
### Caveats ###
One might argue that Fedora’s parent owner, Red Hat, puts a significant amount of effort into maintaining and improving KVM within their distribution. Red Hat hasn’t made significant contributions to Xen in years and they [made the switch to KVM back in 2009][6]. I’ve left this out of scope for these tests, but it’s still something worth considering.
Also, contention was tightly controlled and minimized. On most virtualized servers, you’re going to have multiple virtual machines fighting for CPU time, disk I/O, and access to the network. These tests didn’t take that type of activity into consideration. One hypervisor might have poor performance at low contention but then perform much better than its competitors when contention for resources is high.
These tests were performed only on Intel CPU’s. Results may vary on AMD and ARM.
### Results ###
The tests against the bare metal servers served as a baseline for the virtual machine tests. The deviation in performance between the two servers without virtualization was at 0.51% or less.
KVM’s performance fell within 1.5% of bare metal in almost all tests. Only two tests fell outside that variance. One of those tests was the 7-Zip test where KVM was 2.79% slower than bare metal. Oddly enough, KVM was 4.11% faster than bare metal with the PostMark test (which simulates a really busy mail server). I re-ran the PostMark tests again on both servers and those results fell within 1% of my original test results. I’ll be digging into this a bit more as my knowledge of virtio’s internals isn’t terribly deep.
Xen’s performance varied more from bare metal than KVM. Three tests came within 2.5% of bare metal speeds but the remainder were anywhere from 2-4x slower than KVM. The PostMark test was 14.41% slower in KVM than bare metal and I found that result surprising. I re-ran the test and the results during the second run were within 2% of my original results. KVM’s best performing CPU test, the MAFFT alignment, was Xen’s second worst.
I’ve provided a short summary table here with the final results:
<table id="tablepress-3" class="tablepress tablepress-id-3 dataTable">
<thead>
<tr class="row-1 odd" role="row"><th class="column-1 sorting" role="columnheader" tabindex="0" aria-controls="tablepress-3" rowspan="1" colspan="1" aria-label="&amp;nbsp;: activate to sort column ascending" style="width: 261px;"><div>&nbsp;</div></th><th class="column-2 sorting" role="columnheader" tabindex="0" aria-controls="tablepress-3" rowspan="1" colspan="1" aria-label="Best Value: activate to sort column ascending" style="width: 124px;"><div>Best Value</div></th><th class="column-3 sorting" role="columnheader" tabindex="0" aria-controls="tablepress-3" rowspan="1" colspan="1" aria-label="Bare Metal: activate to sort column ascending" style="width: 124px;"><div>Bare Metal</div></th><th class="column-4 sorting" role="columnheader" tabindex="0" aria-controls="tablepress-3" rowspan="1" colspan="1" aria-label="KVM: activate to sort column ascending" style="width: 85px;"><div>KVM</div></th><th class="column-5 sorting" role="columnheader" tabindex="0" aria-controls="tablepress-3" rowspan="1" colspan="1" aria-label="Xen: activate to sort column ascending" style="width: 66px;"><div>Xen</div></th></tr>
</thead>
<tbody class="row-hover" role="alert" aria-live="polite" aria-relevant="all"><tr class="row-2 even">
<td class="column-1 ">C-Ray</td><td class="column-2 ">lower</td><td class="column-3 ">35.35</td><td class="column-4 ">35.66</td><td class="column-5 ">36.13</td>
</tr><tr class="row-3 odd">
<td class="column-1 ">POV-Ray</td><td class="column-2 ">lower</td><td class="column-3 ">230.02</td><td class="column-4 ">232.44</td><td class="column-5 ">235.89</td>
</tr><tr class="row-4 even">
<td class="column-1 ">Smallpt</td><td class="column-2 ">lower</td><td class="column-3 ">160</td><td class="column-4 ">162</td><td class="column-5 ">167.5</td>
</tr><tr class="row-5 odd">
<td class="column-1 ">John the Ripper (Blowfish)</td><td class="column-2 ">higher</td><td class="column-3 ">3026</td><td class="column-4 ">2991.5</td><td class="column-5 ">2856</td>
</tr><tr class="row-6 even">
<td class="column-1 ">John the Ripper (DES)</td><td class="column-2 ">higher</td><td class="column-3 ">7374833.5</td><td class="column-4 ">7271833.5</td><td class="column-5 ">6911167</td>
</tr><tr class="row-7 odd">
<td class="column-1 ">John the Ripper (MD5)</td><td class="column-2 ">higher</td><td class="column-3 ">49548</td><td class="column-4 ">48899.5</td><td class="column-5 ">46653.5</td>
</tr><tr class="row-8 even">
<td class="column-1 ">OpenSSL</td><td class="column-2 ">higher</td><td class="column-3 ">397.68</td><td class="column-4 ">393.95</td><td class="column-5 ">388.25</td>
</tr><tr class="row-9 odd">
<td class="column-1 ">7-Zip</td><td class="column-2 ">higher</td><td class="column-3 ">12467.5</td><td class="column-4 ">12129.5</td><td class="column-5 ">11879</td>
</tr><tr class="row-10 even">
<td class="column-1 ">Timed MAFFT Alignment</td><td class="column-2 ">lower</td><td class="column-3 ">7.78</td><td class="column-4 ">7.795</td><td class="column-5 ">8.42</td>
</tr><tr class="row-11 odd">
<td class="column-1 ">CLOMP</td><td class="column-2 ">higher</td><td class="column-3 ">3.3</td><td class="column-4 ">3.285</td><td class="column-5 ">3.125</td>
</tr><tr class="row-12 even">
<td class="column-1 ">PostMark</td><td class="column-2 ">higher</td><td class="column-3 ">3667</td><td class="column-4 ">3824</td><td class="column-5 ">3205</td>
</tr></tbody></table>
If you’d like to see the full data, feel free to review the [spreadsheet on Google Docs][7].
### Conclusion ###
Based on this testing environment, KVM is almost always within 2% of bare metal performance. Xen fell within 2.5% of bare metal performance in three out of ten tests but often had a variance of up to 5-7%. Although KVM performed much better with the PostMark test, there was only one I/O test run in this group of tests and more testing is required before a clear winner in disk I/O could be found.
As for me, I’d like to look deeper into how KVM and Xen handle disk I/O and why their results were so different. I may also run some tests under contention to see if one hypervisor can deal with that stress with better performance.
I’d encourage readers to review the list of benchmark tests available in the [Phoronix test suite][8] and find some that emulate portions of their normal workloads. If your workloads are low CPU and high I/O in nature, look for some of the I/O stress tests in the suite. On the other hand, if you do a lot of audio/video transcoding, try some of the x264 or mp3 tests within the suite.
UPDATE: [Chris Behrens pointed out][9] that I neglected to mention the type of virtual machine I tested with Xen. I used PVHVM for the tests as it’s the fastest performing option for Linux guests on Xen 4.3. Keep in mind that PVH is available in Xen 4.4 but that version of Xen isn’t available in Fedora 20 at this time.
--------------------------------------------------------------------------------
via: http://major.io/2014/06/22/performance-benchmarks-kvm-vs-xen/
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
[1]:http://www.phoronix.com/scan.php?page=article&item=intel_haswell_virtualization&num=1
[2]:http://blog.xen.org/index.php/2011/11/29/baremetal-vs-xen-vs-kvm-redux/
[3]:http://blog.xen.org/wp-content/uploads/2011/11/overview.png
[4]:http://ark.intel.com/products/52269/Intel-Xeon-Processor-E3-1220-8M-Cache-3_10-GHz?q=e3-1220
[5]:http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers
[6]:http://www.infoworld.com/d/virtualization/red-hat-releases-first-kvm-support-rhel-54-376
[7]:https://docs.google.com/spreadsheets/d/1kmudbOjCDUgfw76b8qP2GqNqF1ddlTOKyOjc0GmNOIE/edit?usp=sharing
[8]:http://www.phoronix-test-suite.com/
[9]:https://twitter.com/comstud/status/480785742730252288

37
sources/talk/20140624 Staying free--should GCC allow non-free plug ins.md Normal file
View File

@ -0,0 +1,37 @@
Staying free – should GCC allow non-free plug ins?
================================================================================
> Arguments in favour of the use of non-free plug-ins in GCC have again been raised on GCC mailing-lists, but are trumped by the arguments for GCC as a vehicle for free software development
Once again, Gcc and its lack of modularity has been raised as an issue and contrasted with LLVm, the new compiler on the block. GCC is huge and venerable: 5 million lines, 30 years, and growing. LLVM, in contrast, is relatively youthful and modular and allows free and proprietary languages to be added as modules.
The core of LLVM is ‘open source’. GCC is copyleft and unreservedly free software and doesn’t allow plug-ins or other means to add proprietary extensions to the GCC code. The argument, as delivered by Eric Raymond, is that “FSF can no longer prevent proprietary vendors from plugging into a free compiler to improve their tools. That horse has left the barn; the strategic goal of the anti-plug-in policy has been definitively busted.”
LLVM has been sponsored by Apple as a replacement for GCC on OS X and Apple hardware and has grown in popularity, especially among users of the BSDs. Advocates of LLVM see it as a putative replacement for GCC in the wider market for applications developers and mobile devices. The argument against GCC is that its complexity, and the commitment of its developers to copyleft licensing, constrains the possibilities for proprietary developers, who do not want to release their language or architectural specifications under a copyleft licence. Apple, of course, has a long history of antipathy to free software, and doesn’t allow applications licensed under copyleft licences to be distributed through its App Store.
To this extent, the argument between LLVM and GCC is a retread of the historic differences between GNU/Linux and the BSDs, between ‘open source’ and free software. Open source developers allow the code to be reused in any context, free or proprietary. Free software is restrictive in that it insists that the code, and any modifications to the code, must remain free in perpetuity. Advocates of free software would argue that the integrity of copyleft licensing has been instrumental in the spread of GCC, and has taken Linux and free software into places it would not otherwise have reached, and that free software cannot be bought or corrupted by commercial or corporate interests. Open source advocates argue that open source is more free because the user has no restrictions and can do what he or she likes, including developing closed source versions of the code.
Since the beginning, the GNU Compiler Collection (GCC) was vital to the spread of free software. Compilers were a rare and expensive commodity and the compilers of the proprietary software companies were rife with ‘features’ that were non-compliant with ANSI programming standards. Porting software between different machines and operating systems was an unnecessarily complicated task. GCC, the first truly free cross-platform compiler, commoditised this process.
GCC was a breakthrough product for applications developers and mobile device developers – not just those who were committed to the idea of free software. Not only was GCC free and portable, its ubiquity and commonality across different architectures made it easier to port software between machines and to expect robust and consistent results – as the likes of John Gilmore, Michael Tiemann and David Henkel- Wallace were to discover when they made GCC and its development the key selling point of Cygnus Solutions, the first company to make money by selling free software.
The primary technical difference between LLVM and GCC emerges in the separation between the modules that form the ‘front ends’, ‘middle end’ and ‘back ends’ of both GCC and LLVM. ‘Front ends’ are used to interpret the code specific to the translation of a particular language. The ‘middle end’ optimises the translated code. The ‘back ends’ take the optimised code and apply the results to a specific target architecture. LLVM separates these modules into distinct entities, but for semantic and historical reasons, GCC obfuscates the separation between the modules.
Perhaps untypically for a free software project, it is a difficult process to add a new language or architecture to GCC and the adding of proprietary plug-ins is not allowed. There is little clear separation between the modules, and the path of least resistance is to add any feature under a free software licence. The early ports of C++ and Objective C (via Apple) are cited as examples where the original developers might have preferred to keep the code in-house and proprietary, and instead released the code as free software.
In contrast, LLVM has allowed, or perhaps even encouraged, the addition and development of proprietary languages and architectures – one example being Nvidia’s NVCC for GPU computing, based on Clang and LLVM. The source code of NVCC is inaccessible to free software or ‘open source’ developers.
Richard Stallman’s [take on this][1] is characteristically resolute: “In the free software movement, we campaign for the freedom of the users of computing. The values of free software are fundamentally different from the values of open source, which make‘bettercode’theultimategoal. IfGCCwere to change from a free compiler into a platform for non-free compilers, it would no longer serve the goal of freedom very well.
“The Clang and LLVM developers reach different conclusions from ours because they do not share our values and goals. They object to the measures we have taken to defend freedom because they see the inconvenience of them and do not recognise (or don’t care about) the need for them. I would guess they describe their work as ‘open source’ and do not talk about freedom.”
The GCC developers are unlikely to compromise on the licensing terms. While LLVM is fashionable among certain sectors of industry, because it is young and new and has been quicker to jump on developing trands in programming languages, the prevailing wind is towards greater openness, and GCC’s resolve to be incorruptible and free from commercial interests, may be the greater asset in the long term. The Unix companies learnt something from the Unix wars of the Eighties and Nineties. Languages and operating systems are tools, and are better open and shared. GCC is free software and belongs to nobody.
--------------------------------------------------------------------------------
via: http://www.linuxuser.co.uk/features/staying-free-should-gcc-allow-non-free-plug-ins
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
[1]:http://lwn.net/articles/582241

35
sources/talk/20140624 Top500 Supercomputer Remains Stuck at 33.86 Petaflops Each s.md Normal file
View File

@ -0,0 +1,35 @@
Top500 Supercomputer Remains Stuck at 33.86 Petaflops/s
================================================================================
The Tianhe-2 first jumped onto the world's supercomputing stage a year ago, taking the crown of world's most powerful computer. At the time, the Tianhe-2 was rated with a performance of 33.86 petaflops per second.
One full year later and Tianhe-2's performance numbers are unchanged and it still holds down the top spot as the world's most powerful supercomputer.
![](http://www.serverwatch.com/imagesvr_ce/7184/icon-titan-r.jpg)
Back in June of 2013 the number two supercomputer in the world was the Cray Titan, at the U.S. Department of Energy's Oak Ridge National Lab. A year ago, Titan clocked in at 17.59 petaflops per second. Titan's performance, like that of Tianhe-2, remains unchanced for June 2014 and it still holds down the number two spot.
In fact, over the course of the last year, very little has changed among the performance rankings for the top 10 supercomputers in the world, as ranked by the Top500 list.
Looking at the list from the bottom up, the number 500 system on the list, a Cray XC30 at Deutcher Wetterdienst in Germany, clocked in at 133.7 teraflops per second.
"The last system on the newest list was listed at position 384 in the previous TOP500," the TOP500 site stated. "This represents the lowest turnover rate in the list in two decades."
Once again, Intel chips dominate the list with 85.4 percent of the supercomputers, and IBM Power processors hold an 8 percent share. AMD's share now stands at 6 percent.
In terms of chip architectures, 53.6 percent of all systems had 8 or more cores per socket, and 13.4 percent had 10 or more cores.
Looking at the networking interconnects, Infiniband and Ethernet continue to split the field. On the June 2014 list, Infiniband holds a 44.4 percent share of systems.
In contrast, Gigabit Ethernet was reported to have a 25.4 percent share and 10 Gigabit Ethernet had 15 percent, for a combined Ethernet share of 40.4 percent.
HP and IBM once again dominate the list of supercomputing vendors. HP now holds a 36.4 percent share, while IBM holds 35.2 percent. Cray holds down the third spot with a 10.2 percent share.
While there are competing vendors, chip architectures, core counts and networking fabrics at play in the list of the worlds top 500 supercomputers, when it comes to the operating system of choice, there is no debate. Linux dominates the list with a 97 percent share, being installed on 485 systems on the top 500 list.
--------------------------------------------------------------------------------
via: http://www.serverwatch.com/server-news/top500-supercomputer-remains-stuck-at-33.86-petaflops.html
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出

70
sources/tech/20140624 Super Pi Brothers.md Normal file
View File

@ -0,0 +1,70 @@
Super Pi Brothers
================================================================================
I don't game as much as I used to. Although I've certainly spent countless hours of my life in front of a Nintendo, SNES, or after that, playing a first-person shooter on my computer (Linux only, thank you), these days, my free time tends to go toward one of the many nongaming hobbies I've accumulated. Recently though, I found myself dusting off my Wii console just so I could play an NES and SNES game I re-purchased for it. The thing is, those games require using a somewhat strange controller, and I already have a modified SNES controller that can connect over USB. That was enough to encourage me to search for a better solution. Of course, I simply could connect three or four consoles and stack up games in my living room, but I've grown accustomed to ripping my CDs and DVDs and picking what I want to listen to or watch from a central media center. It would be nice if I didn't have to get up and find a cartridge every time I wanted to switch games. This, of course, means going with emulation, but although in the past I'd had success with a modified classic Xbox, I didn't have that hardware anymore. I figured someone must have gotten this set up on the Raspberry Pi, and sure enough, after a brief search and a few commands, I had a perfect retro-gaming arcade set up on a spare Raspberry Pi.
One nice thing about the Raspberry Pi project is the large number of people out there with identical hardware. For me, that meant instead of having to go through someone else's instructions, knowing I'd likely have to tweak it to suit my setup, I basically could follow someone else's guide verbatim. In my case, I found the RetroPie project, which wrapped up all of the commands you would need to install everything on a Raspberry Pi into a single large script. At the end, you have the RetroArch project fully installed and configured, which includes all of the major emulators you'd want and a centralized method to configure them, plus an EmulationStation graphical front end the Pi can boot directly into that makes it simple to navigate to the game you want, all from a gamepad.
### Install RetroPie ###
Before you install RetroPie, you will want to make sure your Raspbian distribution (the default Linux distribution for a Raspberry Pi, and the one this project assumes you will use) is completely up to date, including any new firmware images. This just means a few common `apt` commands. Although you certainly could connect a keyboard to your Raspberry Pi for this step, I've found it more convenient to `ssh` in to the device so I could copy and paste commands:
$ sudo apt-get update
$ sudo apt-get -y upgrade
Now that the Raspberry Pi is up to date, make sure the git and dialog packages are installed, and then use git to download RetroPie:
$ sudo apt-get -y install git dialog
$ cd
$ git clone --depth=0
↪git://github.com/petrockblog/RetroPie-Setup.git
This will create a RetroPie-Setup directory containing the main setup script. Now you just need to go inside that directory and execute it:
$ cd RetroPie-Setup
$ chmod +x retropie_setup.sh
$ sudo ./retropie_setup.sh
This script presents you with an in-terminal menu (Figure 1) where you can choose to perform a binary installation or source installation, set up RetroPie, or perform a series of updates for the RetroPie setup script and binaries. Choose either the binary or source installation. The binary installation won't take as much time, but you may risk running older versions of some of the software. The source installation requires you to compile software, so it takes longer, but at the end, you will have the latest possible versions of everything. Personally, I opted for the binary install, knowing I always could re-run the script and go with the source install if I found any problems.
![](http://www.linuxjournal.com/files/linuxjournal.com/ufiles/imagecache/medium-350px-centered/u1002061/11576f1.png)
#### Figure 1. RetroPie Setup Menu ####
This part of the process will take quite some time on a vanilla Raspbian image, as there are a lot of different packages to download and install. Once the installation completes, go back to the main RetroPie setup screen and select SETUP from the main menu. In this submenu, you can tweak settings, such as whether to start EmulationStation from boot (recommended) and whether to enable a splash screen. In my case, I enabled both settings as I intended my device to be a standalone emulation machine. Note that if you do allow EmulationStation to start up from boot, you still can always ssh in to the machine and run the original RetroPie configuration script to change the settings.
### Adding ROMs ###
You also can add ROMs within the RetroPie setup screen. If you choose the Samba method in the menu, you then can locate a local Samba mountpoint on your network, and you can copy ROMs from that. With the USB stick method, RetroPie will generate a directory structure on a USB stick that you plug in to your Raspberry Pi that represents the different emulators it supports. After this point, you can take that USB stick to another computer and copy ROMs over to the appropriate directory, and the next time you plug it in to the Raspberry Pi, it automatically will sync the files over. Finally (and this is what I did), you just can use scp or rsync to copy over ROMs to the appropriate directory under ~/RetroPie/roms/. So for instance, NES games would be copied to ~/RetroPie/roms/nes/.
Once you are done with the configuration and exit out of the RetroPie setup script, you will want to reboot back into EmulationStation, but before you do, you should reconfigure the memory split on the Raspberry Pi so that it is set to 192 or 128, so run:
$ sudo raspi-config
and go to the Advanced Settings to change the memory split setting. Now you can reboot safely.
### EmulationStation ###
Once you reboot, you should be greeted with the initial EmulationStation screen, which will prompt you to set up your joystick, gamepad or keyboard buttons so it can work with the EmulationStation menu. Note that this doesn't affect how your controllers work within games, just within the EmulationStation menu. After your controller or controllers are set up, you should be able to press right and left on your controller to switch between the different emulator menus. In my case, all of the buttons on my gamepad were going to be used within games, so I made a point to bind a key on a separate keyboard to the menu function so I could exit out of games when I was done without having to reboot the Raspberry Pi.
EmulationStation will show you only menus that represent emulators for which it has detected ROMs, so if you haven't copied ROMs for a particular emulator yet, you will want to do that and potentially restart your Raspberry Pi before you can see them. Also, by default, your controller will not be configured for any games, but if you press the right arrow enough times within EmulationStation, you will get to an input configuration screen that allows you to map keys on your controller to keys inside a game. The nice thing about this setup is that after you configure the keys, it will apply appropriately within each emulator.
That's it. From this point, you can browse through your collection of games and press whatever button you bound to Accept to start playing. At first I was concerned the Raspberry Pi wouldn't have the horsepower to play my games, but so far, it has been able to play any games I tried without a problem.
### Resources ###
The RetroPie Project: [http://blog.petrockblock.com/retropie][1]
RetroPie Installation Docs: [https://github.com/petrockblog/RetroPie-Setup][2]
--------------------------------------------------------------------------------
via: http://www.linuxjournal.com/content/super-pi-brothers
译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
[1]:http://blog.petrockblock.com/retropie
[2]:https://github.com/petrockblog/RetroPie-Setup