| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are no compilers or interpreters. In reality, there are only translators that convert one form into another.
For example, this is a language called "C" that computes the greatest common divisor:
unsigned int gcd (unsigned int a, unsigned int b)
{
if (a == 0 &&b == 0)
b = 1;
else if (b == 0)
b = a;
else if (a != 0)
while (a != b)
if (a <b)
b -= a;
else
a -= b;
return b;
}
And this another language, called the "WATCOM C/C++ v10.0a assembler" that is generated by a "C" to "assembler" translator:
gcd: mov ebx,eax
mov eax,edx
test ebx,ebx
jne L1
test edx,edx
jne L1
mov eax,1
ret
L1: test eax,eax
jne L2
mov eax,ebx
ret
L2: test ebx,ebx
je L5
L3; cmp ebx,eax
je L5
jae L4
sub eax,ebx
jmp L3
L4: sub ebx,eax
jmp L3
L5: ret
Sometimes translation + optimization takes so long, that it is worth while caching the translated form (so if we ever need it again, we just run the cached form). This is called compilation
Every translation is ready by an interpreter. Some interperators are actual silicon hardware. If we translate down to this form, our binary code it sloshes around, and gets translated into (say) changes to pixels on the screen or changes to the contents of a file.
We call silicon interpreters actual machines and the all the other interpreters that read all the other non-binary translations virtual machines (VM). And any computation is really a sequence of translations down a hierachy of virtual machines; e.g. example:
requirements document # translated by "human" into .. deisgn notation # e.g. UML, translated to "C++" by "CAD tool" "c++" # older versions of "c++" translated to "c" "c" # and so it goes on assembler machine code binary # and finally... ------- silicon
The advantages list of pros and cons of virtual machines is based on some excellent article by Wellie Chao.
Every layer of translation slows down the computer. This is less of a problem these days (faster CPUs, better optimizers) but it is something to bear in mind.
I’m going to let you run any old program inside a VM on my hardware? And that program could (say) launch a denial of service of attack on China without me knowing about it? And, if that program breaks through the walls around the virtual machine, it could take all the data on my machine?
Yeah, right, that’ll work.
Now, my business critical apps are running on someone else’s machines. I do not control my own infrastructure. Can I live with that?
To run N languages on P platforms, just port take a VM that runs the N languges, then port it once for each platform.
Heck, some one has probably done this already if it is a common language (like JAVA) or a poplular plaform (like Windows, Linux, Mac). Which means that, to run your code on many platforms, just make it compatiable with a VM that runs on those platforms.
Most of the virtual machine software on the market today stores a whole disk in the guest environment as a single file in the host environment. Snapshot and rollback capabilities are implemented by storing the change in state in a separate file in the host information.
Running everything on one machine would be great if it all worked, but many times it results in undesirable interactions or even outright conflicts. The cause often is software problems or business requirements, such as the need for isolated security. Virtual machines allow you to isolate each application (or group of applications) in its own sandbox environment. The virtual machines can run on the same physical machine (simplifying IT hardware management), yet appear as independent machines to the software you are running.
If one virtual machine goes down due to application or operating system error, the others continue running, providing services your business needs to function smoothly.
Virtual machines let you test scenarios easily. Most virtual machine software today provides snapshot and rollback capabilities. This means you can stop a virtual machine, create a snapshot, perform more operations in the virtual machine, and then roll back again and again until you have finished your testing.
Once you can run N copies on P platforms, why keep P small? Why not, instead, keep hopping your applciations around to any space CPU, whereever it appears?
VMs make it very easy for someone to sell your their spare CPU. They don’ have to deal with the details of your application (which can be quirky++). Instead, they just have to advertise that they handle a small number of virtual machines.
Data Consistency Properties and the Trade-offs in Commercial Cloud Storages: the Consumers’ Perspective, Zhao Liang, Liu Anna, Keung Jacky, Asia Pacific Software Engineering Conference, Dec 2010
Expected behavior: cloud scales to handle more http requests, as needed.
Actual (observed on Amazon Web Services Google App Engine, Microsoft Windows Azure):
Lesson: cloud can be good, but current commercial servings could be improved.
| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on April 19, 2011 using texi2html 5.0.