자바“가상 머신”과 파이썬“인터프리터”의 용어?

자바“가상 머신”과 파이썬“인터프리터”의 용어?

---

Java "가상 머신"이 항상 사용되는 동안 파이썬 "가상 머신"을 읽는 것은 드문 것 같습니다.

둘 다 바이트 코드를 해석합니다. 왜 하나는 가상 머신이고 다른 하나는 통역사라고 부르는가?

---

가상 머신은 특정 언어와 독립적으로 지원되는 특정 원자 단위로 정의 된 명령어 세트가있는 가상 컴퓨팅 환경이며 일반적으로 자체 샌드 박스로 간주됩니다. VM은 특정 CPU의 명령어 세트와 유사하며 다음 명령어와 독립적 인 명령어 (또는 바이트 코드)의 매우 기본적인 빌딩 블록으로보다 기본적인 수준에서 작동하는 경향이 있습니다. 명령은 가상 머신의 현재 상태에만 기반하여 결정적으로 실행되며 해당 시점의 명령 스트림에있는 다른 정보에 의존하지 않습니다.

반면에 인터프리터는 특정 언어 및 주변 토큰의 컨텍스트에서 디코딩되어야하는 특정 그래머의 일부 구문 스트림을 구문 분석하도록 조정되어 있기 때문에 더 정교합니다. 각 바이트 또는 각 라인을 개별적으로 볼 수 없으며 다음에 수행 할 작업을 정확히 알 수 없습니다. 언어의 토큰은 VM의 명령어 (바이트 코드)와 관련하여 격리 할 수 ​​없습니다.

Java 컴파일러는 Java 언어를 바이트 코드 스트림으로 변환하고 C 컴파일러는 C 언어 프로그램을 어셈블리 코드로 변환합니다. 반면에 통역사는 실제로 프로그램을 잘 정의 된 중간 형식으로 변환하지 않으며 단지 소스를 해석하는 과정에서 프로그램 동작을 취합니다.

VM과 인터프리터의 차이점에 대한 또 다른 테스트는 VM이 ​​언어 독립적이라고 생각하는지 여부입니다. 우리가 Java VM으로 알고있는 것은 실제로 Java에 특정한 것은 아닙니다. JVM에서 실행될 수있는 바이트 코드를 생성하는 다른 언어로 컴파일러를 작성할 수 있습니다. 다른 한편으로, 나는 파이썬 인터프리터가 해석하기 위해 파이썬 이외의 다른 언어를 파이썬으로 "컴파일"할 것이라고 생각하지 않습니다.

해석 과정의 정교함 때문에 이것은 비교적 느린 과정 일 수 있습니다. 특히 언어 토큰을 구문 분석 및 식별하는 등 통역사 내에서 실행 프로세스를 수행 할 수있는 소스의 컨텍스트를 이해합니다. 이러한 해석 된 언어를 가속화하기 위해보다 쉽게 ​​직접 해석되는 사전 구문 분석 된 사전 토큰 화 된 소스 코드의 중간 형식을 정의 할 수 있습니다. 이러한 종류의 이진 형식은 여전히 ​​실행 시간에 해석되며 성능을 향상시키기 위해 사람이 읽을 수있는 형식이 훨씬 적습니다. 그러나 해당 형식을 실행하는 논리는 가상 머신이 아닙니다. 이러한 코드는 여전히 분리되어 사용할 수 없기 때문입니다. 주변 토큰의 컨텍스트는 여전히 중요합니다.

---

이 게시물에서 "가상 머신"은 Qemu 또는 Virtualbox와 같은 시스템 가상 머신이 아닌 프로세스 가상 머신을 나타냅니다. 프로세스 가상 머신은 일반적인 프로그래밍 환경 (프로그래밍 할 수있는 프로그램)을 제공하는 프로그램입니다.

Java에는 가상 머신뿐만 아니라 인터프리터도 있고 Python에는 인터프리터뿐만 아니라 가상 머신도 있습니다. "가상 머신"이 Java에서 더 일반적인 용어이고 "인터프리터"가 파이썬에서 더 일반적인 용어 인 이유는 정적 타이핑 (Java)과 동적 타이핑 (Python)의 두 언어의 주요 차이점과 관련이 있습니다. 이와 관련하여 "유형"은 기본 데이터 유형 (데이터의 메모리 내 저장 크기를 제안하는 유형)을 나타냅니다 . 자바 가상 머신은 쉽다. 프로그래머는 각 변수의 원시 데이터 유형을 지정해야합니다. 이것은 Java 바이트 코드가 Java 가상 머신에 의해 해석되고 실행될뿐만 아니라 머신 명령어 로 컴파일되기에 충분한 정보를 제공합니다.. Python 가상 머신은 각 작업을 실행하기 전에 일시 중지하는 추가 작업을 수행하여 작업에 관련된 각 변수 또는 데이터 구조의 기본 데이터 유형을 결정한다는 점에서 더 복잡합니다. Python은 프로그래머가 기본 데이터 유형의 관점에서 생각하지 못하게하고 작업을 더 높은 수준으로 표현할 수 있도록합니다. 이 자유의 가격은 성능입니다. "인터프리터 (interpreter)"는 데이터 타입을 검사하기 위해 일시 ​​정지해야하기 때문에 파이썬에서 선호하는 용어이며, 동적으로 타입이 지정된 언어의 비교적 간결한 구문이 인터랙티브 인터페이스에 적합하기 때문입니다. 대화식 Java 인터페이스를 구축하는 데 기술적 장벽은 없지만 정적 형식 코드를 대화식으로 작성하는 것은 번거로운 일이므로 그렇게하지는 않습니다.

Java 세계에서 가상 머신은 실제로 머신 명령어로 컴파일 될 수있는 언어로 작성된 프로그램을 실행하기 때문에 쇼를 훔쳐 결과적으로 속도와 리소스 효율성이 향상됩니다. Java 바이트 코드는 Java 가상 머신에서 컴파일 된 프로그램의 성능에 비교적 근접한 성능으로 실행될 수 있습니다. 바이트 코드에 기본 데이터 형식 정보가 있기 때문입니다. Java 가상 머신은 Java를 자체 범주에 배치합니다.

이식 가능하고 정적 인 유형의 언어

다음으로 가장 가까운 것은 LLVM이지만 LLVM은 다른 수준에서 작동합니다.

휴대용 해석 언어

"바이트 코드"라는 용어는 Java와 Python 모두에서 사용되지만 모든 바이트 코드가 동일하게 생성되는 것은 아닙니다. 바이트 코드는 컴파일러 / 통역사가 사용하는 중간 언어의 일반적인 용어입니다. gcc와 같은 C 컴파일러조차도 중간 언어 (또는 여러 언어) 를 사용하여 작업을 완료합니다. Java 바이트 코드에는 기본 데이터 유형에 대한 정보가 포함되어 있지만 Python 바이트 코드에는 없습니다. 이와 관련하여 Python (및 Bash, Perl, Ruby 등) 가상 머신은 기본적으로 Java 가상 머신보다 느리거나 오히려 더 많은 작업이 필요합니다. 다른 바이트 코드 형식에 포함 된 정보를 고려하는 것이 유용합니다.

• llvm : CPU 레지스터
• Java : 기본 데이터 유형
• 파이썬 : 사용자 정의 타입

실제 비유를 그리려면 LLVM은 원자와 함께 작동하고 Java 가상 머신은 분자와 작동하며 Python 가상 머신은 재료와 작동합니다. 모든 것이 궁극적으로 아 원자 입자 (실제 기계 작동)로 분해되어야하기 때문에 Python 가상 기계는 가장 복잡한 작업을 수행합니다.

정적 타입 언어의 인터프리터 / 컴파일러에는 동적 타입 언어의 인터프리터 / 컴파일러와 동일한 수하물이 없습니다. 정적으로 유형이 지정된 언어의 프로그래머는 여유를 극복해야합니다. 그러나 모든 비 결정적 함수가 비밀리에 결정론적인 것처럼 동적으로 유형이 지정된 언어는 모두 정적으로 유형이 정해집니다. 따라서 두 언어 제품군 간의 성능 차이는 Python이 HAL 9000으로 이름을 변경하는 시점에서 수평을 유지해야합니다.

파이썬과 같은 동적 언어의 가상 머신은 이상적인 논리 머신을 구현하며 실제 물리적 하드웨어와 반드시 긴밀하게 대응할 필요는 없습니다. 반면 Java 가상 머신은 기능을 일반 C 컴파일러와 비슷하지만 머신 명령어를 내보내는 대신 내장 루틴을 실행한다는 점이 다릅니다. 파이썬에서 정수는 많은 속성과 메소드가 첨부 된 파이썬 객체입니다. Java에서 int는 지정된 수의 비트 (일반적으로 32)입니다. 이것은 실제로 공정한 비교가 아닙니다. 파이썬 정수는 실제로 Java Integer 클래스와 비교되어야합니다. Java의 "int"프리미티브 데이터 유형은 Python 언어에이 프리미티브 계층이 없으므로 Python 바이트 코드도 없기 때문에 Python 언어의 어떤 것과도 비교할 수 없습니다.

Java 변수가 명시 적으로 입력 되었기 때문에 Jython 성능 과 같은 것이 cPython 과 같은 구장에 있다고 합리적으로 기대할 수 있습니다 . 반면에, 파이썬으로 구현 된 자바 가상 머신은 진흙보다 느리게 보장됩니다. 그리고 루비, 펄 등이 더 나아질 것으로 기대하지 마십시오. 그들은 그렇게하도록 설계되지 않았습니다. 이들은 "스크립트"를 위해 설계되었으며, 이는 동적 언어로 프로그래밍하는 것입니다.

Every operation that takes place in a virtual machine eventually has to hit real hardware. Virtual machines contain pre-compiled routines which are general enough to to execute any combination of logical operations. A virtual machine may not be emitting new machine instructions, but it certainly is executing its own routines over and over in arbirtrarily complex sequences. The Java virtual machine, the Python virtual machine, and all the other general-purpose virtual machines out there are equal in the sense that they can be coaxed into performing any logic you can dream up, but they are different in terms of what tasks they take on, and what tasks they leave to the programmer.

Psyco for Python is not a full Python virtual machine, but a just-in-time compiler that hijacks the regular Python virtual machine at points it thinks it can compile a few lines of code -- mainly loops where it thinks the primitive type of some variable will remain constant even if the value is changing with each iteration. In that case, it can forego some of the incessent type determination of the regular virtual machine. You have to be a little careful, though, lest you pull the type out from under Psyco's feet. Pysco, however, usually knows to just fall back to the regular virtual machine if it isn't completely confident the type won't change.

The moral of the story is that primitive data type information is really helpful to a compiler/virtual machine.

마지막으로, 모든 관점에서 살펴보면 이것을 고려하십시오 .iPhone에서 실행되는 qemu 가상 머신에서 실행되는 LLVM에서 실행되는 Java 인터프리터 / 가상 머신에서 실행되는 Java로 구현 된 Python 인터프리터 / 가상 머신에서 실행되는 Python 프로그램입니다.

퍼머 링크

---

아마도 다른 용어에 대한 한 가지 이유는 일반적으로 파이썬 인터프리터 원시 인간 판독 가능 소스 코드를 제공하고 바이트 코드와 그 모든 것에 대해 걱정하지 않기 때문입니다.

Java에서는 명시 적으로 바이트 코드로 컴파일 한 다음 VM의 소스 코드가 아닌 바이트 코드 만 실행해야합니다.

비록 파이썬이 덮개 아래에서 가상 머신을 사용하더라도, 사용자 관점에서이 세부 사항은 대부분 무시할 수 있습니다.

---

Interpreter 는 소스 코드를 효율적인 중간 표현 (코드)으로 변환하여 즉시 실행합니다.

Virtual Machine 은 인터프리터 시스템의 일부인 컴파일러로 빌드 된 저장된 사전 컴파일 된 코드를 명시 적으로 실행합니다.

가상 머신의 매우 중요한 특성은 내부에서 실행되는 소프트웨어가 가상 머신이 제공하는 리소스로 제한된다는 것입니다. 정확하게, 그것은 가상 세계에서 벗어날 수 없습니다. 원격 코드 인 Java 애플릿의 안전한 실행을 생각하십시오.

파이썬의 경우 ,이 게시물의 의견에서 언급했듯이 pyc 파일을 유지 하면 메커니즘이 VM과 같아 지고이 바이트 코드가 더 빠르게 실행됩니다. . 이것을 전체적으로 보면 PVM은 Python Interpreter의 마지막 단계입니다.

The bottomline is, when refer Python Interpreter, it means we are referring it as a whole, and when we say PVM, that means we are just talking about a part of Python Interpreter, a runtime-environment. Similar to that of Java, we refer different parts differentyl, JRE, JVM, JDK, etc.

For more, Wikipedia Entry: Interpreter, and Virtual Machine. Yet another one here. Here you can find the Comparison of application virtual machines. It helps in understanding the difference between, Compilers, Interpreters, and VMs.

---

인터프리터라는 용어는 이전 쉘 스크립팅 언어로 거슬러 올라가는 레거시 용어입니다. "스크립팅 언어"가 완전한 기능을 갖춘 언어로 발전하고 해당 플랫폼이 더욱 정교 해지고 샌드 박스 화됨에 따라 가상 머신과 인터프리터 (Python의 의미)의 차이는 매우 작거나 존재하지 않습니다.

파이썬 인터프리터는 별도의 컴파일 단계없이 실행될 수 있다는 점에서 쉘 스크립트와 동일한 방식으로 작동합니다. 그 외에도 Python의 인터프리터 (또는 Perl 또는 Ruby)와 Java의 가상 머신의 차이점은 대부분 구현 세부 사항입니다. (Java가 Python보다 샌드 박스가 더 완벽하다고 주장 할 수 있지만 궁극적으로는 네이티브 C 인터페이스를 통해 기본 아키텍처에 대한 액세스를 제공합니다.)

---

There's no real difference between them, people just follow the conventions the creators have chosen.

---

To provide a deep answer to the question "Why Java Virtual Machine, but Python interpreter?" let's try to go back to the field of compilation theory as to the starting point of the discussion.

The typical process of program compilation includes next steps:

1. Lexical analysis. Splits program text into meaningful "words" called tokens (as part of the process all comments, spaces, new-lines etc. are removed, because they do not affect program behavior). The result is an ordered stream of tokens.
2. Syntax analysis. Builds the so-called Abstract Syntax Tree (AST) from the stream of tokens. AST establish relations between tokens and, as a consequence, defines an order of evaluation of the program.
3. Semantic analysis. Verifies semantical correctness of the AST using information about types and a set of semantical rules of the programming language. (For example, a = b + c is a correct statement from the syntaxis point of view, but completely incorrect from the semantic point of view if a was declared as a constant object)
4. Intermediate code generation. Serializes AST into the linearly ordered stream of machine independent "primitive" operations. In fact, code generator traverses AST and logs the order of evaluation steps. As a result, from the tree-like representation of the program, we achieve much more simple list-like representation in which order of program evaluation is preserved.
5. Machine code generation. The program in the form of machine independent "primitive" bytecode is translated into machine code of particular processor architecture.

Ok. Lets now define the terms.

Interpreter, in the classical meaning of that word, assumes execution based on the program evaluation based on AST produced directly from the program text. In that case, a program is distributed in the form of source code and the interpreter is fed by program text, frequently in a dynamic way (statement-by-statement or line-by-line). For each input statement, interpreter builds its AST and immediately evaluates it changing the "state" of the program. This is a typical behavior demonstrated by scripting languages. Consider for example Bash, Windows CMD etc. Conceptually, Python takes this way too.

If we replace the AST-based execution step on the generation of intermediate machine-independent binary bytecode step in the interpreter we will split the entire process of program execution into two separate phases: compilation and execution. In that case what previously was an interpreter will become a bytecode compiler, which will transform the program from the form of the text into some binary form. Then the program is distributed in that binary form, but not in the form of source code. On the user machine, that bytecode is fed into a new entity -- virtual machine, which in fact interpret that bytecode. Due to this, virtual machines are also called bytecode interpreter. But put your attention here! A classical interpreter is a text interpreter, but a virtual machine is a binary interpreter! This is an approach taken by Java and C#.

Finally, if we add the machine code generation to the bytecode compiler we achieve in result what we call a classical compiler. A classical compiler converts the program source code into the machine code of a particular processor. That machine code then can be directly executed on the target processor without any additional mediation (without any kind of interpreter neither text interpreter nor binary interpreter).

Lets now go back to the original question and consider Java vs Python.

Java was initially designed to have as few implementation dependencies as possible. Its design is based on the principle "write once, run anywhere" (WORA). To implement it, Java was initially designed as a programming language that compiles into machine-independent binary bytecode, which then can be executed on all platforms that support Java without the need for its recompilation. You can think about Java like about WORA-based C++. Actually, Java is closer to C++ than to the scripting languages like Python. But in contrast to C++, Java was designed to be compiled into binary bytecode which then is executed in the environment of the virtual machine, while C++ was designed to be compiled in machine code and then directly executed by the target processor.

Python was initially designed as a kind of scripting programing language which interprets scripts (programs in the form of the text written in accordance with the programming language rules). Due to this, Python has initially supported a dynamic interpretation of one-line commands or statements, as the Bash or Windows CMD do. For the same reason, initial implementations of Python had not any kind of bytecode compilers and virtual machines for execution of such bytecode inside, but from the start Python had required interpreter which is capable to understand and evaluate Python program text.

Due to this, historically, Java developers tended to talk about Java Virtual Machine (because initially, Java has come as package of Java bytecode compiler and bytecode interpreter -- JVM), and Python developers tended to talk about Python interpreter (because initially Python has not any virtual machine and was a kind of classical text interpreter that executes program text directly without any sort of compilation or transformation into any form of binary code).

Currently, Python also has the virtual machine under the hood and can compile and interpret Python bytecode. And that fact makes an additional investment into the confusion "Why Java Virtual Machine, but Python interpreter?", because it seems that implementations of both languages contain virtual machines. But! Even in the current moment interpretation of program text is a primary way of Python programs execution. Python implementations exploit virtual machines under the hood exclusively as an optimization technique. Interpretation of binary bytecode in the virtual machine is much more efficient than a direct interpretation of the original program text. At the same time, the presence of the virtual machine in the Python is absolutely transparent for both Python language designers and Python programs developers. The same language can be implemented in interpreters with and without the virtual machine. In the same way, the same programs can be executed in interpreters with and without the virtual machine, and that programs will demonstrate exactly the same behavior and produce equally the same output from the equal input. The only observable difference will be the speed of program execution and the amount of memory consumed by the interpreter. Thus, the virtual machine in Python is not an unavoidable part of the language design, but just an optional extension of the major Python interpreter.

Java can be considered in a similar way. Java under the hood has a JIT compiler and can selectively compile methods of Java class into machine code of the target platform and then directly execute it. But! Java still uses bytecode interpretation as a primary way of Java program execution. Like Python implementations which exploit virtual machines under the hood exclusively as an optimization technique, the Java virtual machines use Just-In-Time compilers exclusively for optimization purposes. Similarly, just because of the fact that direct execution of the machine code at least ten times faster than the interpretation of Java bytecode. And like in the case of Python, the presence of JIT compiler under the hood of JVM is absolutely transparent for both Java language designers and Java program developers. The same Java programming language can be implemented by JVM with and without JIT compiler. And in the same way, the same programs can be executed in JVMs with and without JIT inside, and the same programs will demonstrate exactly the same behavior and produce equally the same output from the equal input on both JVMs (with and without JIT). And like in the case of Python, the only observable difference between them, will be in the speed of execution and in the amount of memory consumed by JVM. And finally, like in the case of Python, JIT in Java also is not an unavoidable part of the language design, but just an optional extension of the major JVM implementations.

From the point of view of design and implementation of virtual machines of Java and Python, they differ significantly, while (attention!) both still stay virtual machines. JVM is an example of a low-level virtual machine with simple basic operations and high instruction dispatch cost. Python in its turn is a high-level virtual machine, for which instructions demonstrate complex behavior, and instruction dispatch cost is not so significant. Java operates with very low abstraction level. JVM operates on the small well-defined set of primitive types and has very tight correspondence (typically one to one) between bytecode instructions and native machine code instructions. In contrary, Python virtual machine operates at high abstraction level, it operates with complex data types (objects) and supports ad-hoc polymorphism, while bytecode instructions expose complex behavior, which can be represented by a series of multiple native machine code instructions. For example, Python supports unbounded range mathematics. Thus Python VM is forced to exploit long arithmetics for potentially big integers for which result of the operation can overflow the machine word. Hence, one bytecode instruction for arithmetics in Python can expose into the function call inside Python VM, while in JVM arithmetic operation will expose into simple operation expressed by one or few native machine instructions.

As a result, we can draw the next conclusions. Java Virtual Machine but Python interpreter is because:

1. The term of virtual machine assumes binary bytecode interpretation, while the term interpreter assumes program text interpretation.
2. Historically, Java was designed and implemented for binary bytecode interpretation and Python was initially designed and implemented for program text interpretation. Thus, the term "Java Virtual Machine" is historical and well established in the Java community. And similarly, the term "Python Interpreter" is historical and well established in the Python community. Peoples tend to prolong the tradition and use the same terms that were used long before.
3. Finally, currently, for Java, binary bytecode interpretation is a primary way of programs execution, while JIT-compilation is just an optional and transparent optimization. And for Python, currently, program text interpretation is a primary way of Python programs execution, while compilation into Python VM bytecode is just an optional and transparent optimization.

---

Therefore, both Java and Python have virtual machines are binary bytecode interpreters, which can lead to confusion such as "Why Java Virtual Machine, but Python interpreter?". The key point here is that for Python, a virtual machine is not a primary or necessary means of program execution; it is just an optional extension of the classical text interpreter. On the other hand, a virtual machine is a core and unavoidable part of Java program execution ecosystem. Static or dynamic typing choice for the programming language design affects mainly the virtual machine abstraction level only, but does not dictate whether or not a virtual machine is needed. Languages using both typing systems can be designed to be compiled, interpreted, or executed within the environment of virtual machine, depending on their desired execution model.

---

Don't forget that Python has JIT compilers available for x86, further confusing the issue. (See psyco).

A more strict interpretation of an 'interpreted language' only becomes useful when discussing performance issues of the VM, for example, compared with Python, Ruby was (is?) considered to be slower because it is an interpreted language, unlike Python - in other words, context is everything.

---

Python can interpret code without compiling it to bytecode. Java can't.

Python is an interpreted language, as opposed to a compiled one, though the distinction can be blurry because of the presence of the bytecode compiler. This means that source files can be run directly without explicitly creating an executable which is then run.

(from the documentation).

In java, every single file has to be compiled to a .class file, which then runs on the JVM. On the contrary, python does that are imported by your main script, to help speed up subsequent uses of those files.

However, in the typical case, most of the python (at least, CPython) code runs in an emulated stack machine, which has nearly identical instructions to those of the JVM, so there's no great difference.

The real reason for the distiction however is because, from the beginning, java branded itself as "portable, executable bytecode" and python branded itself as dynamic, interpreted language with a REPL. Names stick!

---

First of all you should understand that programming or computer science in general is not mathematics and we don't have rigorous definitions for most of the terms we use often.

now to your question :

what is an Interpreter (in computer science)

It translates source code by smallest executable unit and then executes that unit.

what is a virtual machine

in case of JVM the virtual machine is a software which contains an Interpreter, class loaders, garbage collector, thread scheduler , JIT compiler and many other things.

as you can see interpreter is a part or JVM and whole JVM can not be called an interpreter because it contains many other components.

why use word "Interpreter" when talking about python

with java the compilation part is explicit. python on the other hand is not explicit as java about its compilation and interpretation process, from end user's perspective interpretation is the only mechanism used to execute python programs

---

No, they don't both interpret byte code.

Python only interprets bytecode if you are running with pypy. Otherwise it is compiled into C and interpreted at that level.

Java compiles to bytecode.

---

I think the lines between both are blurred, people mostly argue around meaning of word "interpreter" and how close the language stands to each side of "interpreter...compiler" spectrum. None makes 100% however. I think it is easy to write Java or Python implementation which be of any value of the spectrum.

Currently both Java and Python have virtual machines and bytecode, though one operates by concrete value sizes (like 32-bit integer) while other has to determine the size for each call, which in my opinion doesn't define the border between the terms.

The argument that Python doesn't have officially defined bytecode and it exists only in memory also doesn't convince me, just because I am planning to develop devices which will recognize only Python bytecode and the compilation part will be done in browser JS machine.

Performance is only about the concrete implementation. We don't need to know the size of the object to be able to work with it, and finally, in most cases, we work with structures, not basic types. It is possible to optimize Python VM in the way that it will eliminate the need of creating new object each time during expression calculation, by reusing existing one. Once it is done, there is no global performance difference between calculating sum of two integers, which is where Java shines.

There is no killer difference between the two, only some implementation nuances and lack of optimization which are irrelevant to the end user, maybe up at the point where she starts to notice performance lags, but again it is implementation and not architecture issue.

참고URL : https://stackoverflow.com/questions/441824/java-virtual-machine-vs-python-interpreter-parlance