Comments on: 10 Years of Virtual Machine Performance (Semi) Demystified http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/ Wed, 08 Feb 2012 12:12:12 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: events planner http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-59063 events planner Wed, 19 Oct 2011 17:01:15 +0000 http://www.engineyard.com/blog/?p=2374#comment-59063 <strong>[...]the time to read or visit the content or sites we have linked to below the[...]…...</strong> [...]here are some links to sites that we link to because we think they are worth visiting[...]…... [...]the time to read or visit the content or sites we have linked to below the[...]……

[...]here are some links to sites that we link to because we think they are worth visiting[...]……

]]> By: SEO http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-59054 SEO Tue, 18 Oct 2011 03:06:55 +0000 http://www.engineyard.com/blog/?p=2374#comment-59054 <strong>[...]we came across a cool site that you might enjoy. Take a look if you want[...]…...</strong> [...]please visit the sites we follow, including this one, as it represents our best SEO picks from the web[...]…... [...]we came across a cool site that you might enjoy. Take a look if you want[...]……

[...]please visit the sites we follow, including this one, as it represents our best SEO picks from the web[...]……

]]> By: Michael Mullany http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-37470 Michael Mullany Mon, 02 Nov 2009 22:26:48 +0000 http://www.engineyard.com/blog/?p=2374#comment-37470 Well I think your sentiments can be characterized sort of as "if we only wrote everything in LISP and Haskell and ran it on a mainframe, we'd be in better shape". True, but sort of beside the point. As Joyce wrote, "History is a nightmare from which I am trying to awake". But in the real world, history has given us a stock of human and physical capital that represents the slow and lately, more rapid accumulation of knowledge and energy. In software, it means that whatever solution we move to, has to leverage the last 35 years of software investment that companies have in-house doing useful work. For many pieces of software -- there is no source code, or it's proprietary binaries with a defunct provider or the code is so impenetrable that no-one can figure it out. Virtualization is a lowest common denominator solution that can put even the worst piece of historical software garbage into a nice container with management dials and levers with guaranteed isolation enforced by hardware. That's why it works, but yes, it ain't pretty. Well I think your sentiments can be characterized sort of as "if we only wrote everything in LISP and Haskell and ran it on a mainframe, we'd be in better shape". True, but sort of beside the point. As Joyce wrote, "History is a nightmare from which I am trying to awake". But in the real world, history has given us a stock of human and physical capital that represents the slow and lately, more rapid accumulation of knowledge and energy. In software, it means that whatever solution we move to, has to leverage the last 35 years of software investment that companies have in-house doing useful work. For many pieces of software — there is no source code, or it's proprietary binaries with a defunct provider or the code is so impenetrable that no-one can figure it out. Virtualization is a lowest common denominator solution that can put even the worst piece of historical software garbage into a nice container with management dials and levers with guaranteed isolation enforced by hardware. That's why it works, but yes, it ain't pretty.

]]> By: Andrew de Andrade http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-35329 Andrew de Andrade Wed, 28 Oct 2009 21:25:41 +0000 http://www.engineyard.com/blog/?p=2374#comment-35329 As the product manager at a peer of EngineYard in Brazil, I'm really curious if processor power really is that important for you guys. In your environment, do you guys see your hosts consuming all the CPU to the point where it impacts performance? Although I also manage a virtualization-based product, I'm with Google on this one as I don't believe that virtualization is the answer. I think it's a necessary evil. Operating Systems *as we know them today* must die. They are a landfill of leftover junk from a 35+ year operating systems feature arms race. Cloud Computing started in the 60s and the minicomputer took us on a 35-year detour (albeit a necessary detour), that we are only now returning from. We don't need more processor power. Instead we need more parallelization and more applications that move the instructions to the data, instead of trying to bring the data to the instructions. That's why I think that Google has the right idea with AppEngine. That's why we have MapReduce/Hadoop. Anyone that is working with the cloud should familiarize themselves with the Von Neumann Bottleneck (<a href="http://www.stanford.edu/class/cs242/readings/backus.pdf)," target="_blank">http://www.stanford.edu/class/cs242/readings/back...</a> and understand that CPU cycles nowadays are effectively free. The only exception I see are HPC applications that are calculation intensive, but these are the exception, not the rule. I wouldn't even go as far as to say that the 70s are archeology as another poster mentioned. A lot of the problems we encounter today were solved in the 60s and 70s, but we've forgotten those lessons learned. That John Backus article I linked to is from 1977. We also need more functional languages designed for parallelization and we need to start teaching teaching CS students them so that they stop using "word-at-a-time" approaches to solving problems. One of the biggest problems with virtualization is that we are permitting OS systems to persist. The OS was designed to own the hardware and manage the hardware. Does't the hypervisor do that as well? Why do we need two pieces of software to manage memory? When the OS starts up, it automatically assumes it owns all the memory given to it and other than some awkward workarounds, there is no way to take that memory back and make it available to other programs in other VMs. If Eiji Toyoda investigated how IaaS clouds work today, he would certainly use to Japanese word "muda" (waste) to describe what we are doing. The OS today, is nothing more than a very expensive runtime, and it is virtualization that is promoting the persistence of this waste. Market demand is the reason we have virtualization. Virtualization doesn't exist because it's the best technical solution. Everyone working in the cloud needs to understanding that "all this amazing architectural work" being done to get the most performance are simply workarounds to a CS bottleneck that has been with us for over 50 years. As the product manager at a peer of EngineYard in Brazil, I'm really curious if processor power really is that important for you guys. In your environment, do you guys see your hosts consuming all the CPU to the point where it impacts performance?

Although I also manage a virtualization-based product, I'm with Google on this one as I don't believe that virtualization is the answer. I think it's a necessary evil. Operating Systems *as we know them today* must die. They are a landfill of leftover junk from a 35+ year operating systems feature arms race. Cloud Computing started in the 60s and the minicomputer took us on a 35-year detour (albeit a necessary detour), that we are only now returning from.

We don't need more processor power. Instead we need more parallelization and more applications that move the instructions to the data, instead of trying to bring the data to the instructions. That's why I think that Google has the right idea with AppEngine. That's why we have MapReduce/Hadoop.

Anyone that is working with the cloud should familiarize themselves with the Von Neumann Bottleneck (http://www.stanford.edu/class/cs242/readings/back… and understand that CPU cycles nowadays are effectively free. The only exception I see are HPC applications that are calculation intensive, but these are the exception, not the rule.

I wouldn't even go as far as to say that the 70s are archeology as another poster mentioned. A lot of the problems we encounter today were solved in the 60s and 70s, but we've forgotten those lessons learned. That John Backus article I linked to is from 1977.

We also need more functional languages designed for parallelization and we need to start teaching teaching CS students them so that they stop using "word-at-a-time" approaches to solving problems.

One of the biggest problems with virtualization is that we are permitting OS systems to persist. The OS was designed to own the hardware and manage the hardware. Does't the hypervisor do that as well? Why do we need two pieces of software to manage memory? When the OS starts up, it automatically assumes it owns all the memory given to it and other than some awkward workarounds, there is no way to take that memory back and make it available to other programs in other VMs. If Eiji Toyoda investigated how IaaS clouds work today, he would certainly use to Japanese word "muda" (waste) to describe what we are doing.

The OS today, is nothing more than a very expensive runtime, and it is virtualization that is promoting the persistence of this waste. Market demand is the reason we have virtualization. Virtualization doesn't exist because it's the best technical solution.

Everyone working in the cloud needs to understanding that "all this amazing architectural work" being done to get the most performance are simply workarounds to a CS bottleneck that has been with us for over 50 years.

]]> By: Michael Mullany http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-23542 Michael Mullany Thu, 08 Oct 2009 19:57:27 +0000 http://www.engineyard.com/blog/?p=2374#comment-23542 Thanks for the catch Alin. 50 dkp- for the proofreader (me) Thanks for the catch Alin. 50 dkp- for the proofreader (me)

]]> By: Alin Hanghiuc http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-23442 Alin Hanghiuc Thu, 08 Oct 2009 15:24:57 +0000 http://www.engineyard.com/blog/?p=2374#comment-23442 Nice article, but I'm pretty sure that the throughputs in the following paragraph are measured in Gb/s (gigabits/s) and not GB/s (gigabytes/s): "Before Intel VT-D, 10GigE workloads became CPU-limited out at around 3.5GB/s of throughput. Afterwards (and with appropriate support in the hypervisor), throughputs above 9.6 GB/s have been achieved." Nice article, but I'm pretty sure that the throughputs in the following paragraph are measured in Gb/s (gigabits/s) and not GB/s (gigabytes/s):

"Before Intel VT-D, 10GigE workloads became CPU-limited out at around 3.5GB/s of throughput. Afterwards (and with appropriate support in the hypervisor), throughputs above 9.6 GB/s have been achieved."

]]> By: khyron4eva http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-22872 khyron4eva Wed, 07 Oct 2009 04:37:25 +0000 http://www.engineyard.com/blog/?p=2374#comment-22872 Ugh. Ok, it looks like Bochs is a x86 simulator (technically) which explains why I was able to consider running it on Ultrix. Ugh. Ok, it looks like Bochs is a x86 simulator (technically) which explains why I was able to consider running it on Ultrix.

]]> By: khyron4eva http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-22870 khyron4eva Wed, 07 Oct 2009 04:32:05 +0000 http://www.engineyard.com/blog/?p=2374#comment-22870 Where does Bochs fit into this conversation? I ran into Bochs long before I ever heard of VMware (and probably before VMware was a company, since this was the mid - late 90s, maybe around the time of the Disco project). <a href="http://bochs.sourceforge.net/" target="_blank">http://bochs.sourceforge.net/</a> Where does Bochs fit into this conversation? I ran into Bochs long before I ever heard of VMware (and probably before VMware was a company, since this was the mid – late 90s, maybe around the time of the Disco project).

http://bochs.sourceforge.net/

]]> By: Mike Malloy http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-22613 Mike Malloy Tue, 06 Oct 2009 20:46:34 +0000 http://www.engineyard.com/blog/?p=2374#comment-22613 Very good posting, Michael. I have forwarded the link to several analysts and colleagues. Very good posting, Michael. I have forwarded the link to several analysts and colleagues.

]]> By: Michael Mullany http://www.engineyard.com/blog/2009/10-years-of-virtual-machine-performance-semi-demystified/comment-page-1/#comment-22612 Michael Mullany Tue, 06 Oct 2009 20:45:19 +0000 http://www.engineyard.com/blog/?p=2374#comment-22612 Chris, the one time I tried to read IBM z/VM docs, I found them fairly impenetrable. They seem to assume a great deal of background in z/OS. It may be a very powerful system, but it's doesn't seem very approachable. Although it would be pretty interesting to get JRuby running on the z/OS JVM and see it run Rails. Chris, the one time I tried to read IBM z/VM docs, I found them fairly impenetrable. They seem to assume a great deal of background in z/OS. It may be a very powerful system, but it's doesn't seem very approachable. Although it would be pretty interesting to get JRuby running on the z/OS JVM and see it run Rails.

]]>