Java "가상 시스템" 대Python "인터프리터" 비유?

Java "가상 시스템" 대Python "인터프리터" 비유?

Java에서 "가상 머신"은 항상 사용되는 반면 Python "가상 머신"은 드물게 읽힌다.

둘 다 바이트 코드를 해석하는데, 왜 하나는 가상 머신이고 다른 하나는 통역기라고 부르는가?

이 게시물에서 "가상 시스템"은 Qemu나 Virtualbox와 같은 시스템 가상 시스템이 아니라 가상 시스템을 처리하는 것을 가리킨다.프로세스 가상 머신은 일반적인 프로그래밍 환경을 제공하는 프로그램일 뿐이며, 프로그래밍할 수 있는 프로그램이다.

자바에는 가상 머신뿐만 아니라 통역기도 있고 파이썬에는 가상 머신도 있고 통역기도 있다.가상 머신(virtual machine)이 자바에서 더 보편적인 용어인 데다 파이썬에서 더 보편적인 용어가 파이썬에서 정적 타이핑(java) 대 동적 타이핑(Python)이라는 두 언어의 주요한 차이와 많은 관련이 있기 때문이다.이러한 맥락에서 "유형"은 데이터의 메모리 내 저장 크기를 제안하는 원시 데이터 유형(유형)을 가리킨다.Java 가상 머신은 쉽게 사용할 수 있다.프로그래머가 각 변수의 원시 데이터 유형을 지정해야 한다.이것은 Java 가상 머신에 의해 해석되고 실행될 뿐만 아니라 심지어 기계 명령으로 컴파일될 수 있는 충분한 정보를 제공한다.Python 가상 머신은 작업에 관련된 각 변수나 데이터 구조에 대한 원시 데이터 유형을 결정하기 위해 각 작업을 실행하기 전에 일시 중지하는 추가 작업을 맡는다는 점에서 더욱 복잡하다.Python은 프로그래머가 원시 데이터 유형의 관점에서 생각하는 것을 자유롭게 하고, 더 높은 수준에서 운영을 표현할 수 있게 한다.이 자유의 대가는 성과다."인터프리터"는 데이터 유형을 검사하기 위해 일시 중지해야 하기 때문에 파이썬이 선호하는 용어인데, 또한 동적으로 타이핑된 언어의 비교적 간결한 구문이 인터프리터(Interpreter)가 인터렉티브 인터페이스에 적합하기 때문이다.대화형 Java 인터페이스를 구축하는 데 기술적인 장벽은 없지만, 정적으로 타이핑된 코드를 대화식으로 작성하려고 하는 것은 지루할 수 있기 때문에, 그렇게는 되지 않는다.

자바 세계에서는 가상 머신이 실제로 머신 명령으로 컴파일할 수 있는 언어로 작성된 프로그램을 실행하기 때문에 쇼를 훔치고, 그 결과는 속도와 자원 효율이다.자바 바이트 코드는 컴파일된 프로그램의 성능에 근접하여 자바 가상 머신에 의해 실행될 수 있다.이는 바이트코드에 원시 데이터 유형 정보가 존재하기 때문이다.Java 가상 머신은 Java를 자체 범주에 포함하며,

정적으로 해석된 휴대용 언어

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

휴대용 해석 어셈블리 언어

"바이트코드"라는 용어는 자바와 파이톤에서 모두 사용되지만 모든 바이트코드가 동일한 것은 아니다. 바이트코드는 컴파일러/인터프리터에 의해 사용되는 중간 언어의 일반 용어에 불과하다.gcc 같은 C 컴파일러도 중간언어(또는 여러 개)를 사용해 일을 완수한다.Java 바이트 코드는 원시 데이터 유형에 대한 정보를 포함하지만 Python 바이트 코드는 그렇지 않다.이런 점에서 파이썬(및 Bash,Perl,Ruby 등) 가상 머신은 Java 가상 머신보다 정말로 속도가 느리거나 오히려 더 많은 작업을 할 수 있다.다음과 같은 다른 바이트 코드 형식으로 포함된 정보를 고려하는 것이 유용하다.

• llvm: CPU 레지스터
• Java: 원시 데이터 유형
• Python: 사용자 정의 유형

실제와 유사하게, LLVM은 원자와, 자바 가상 머신은 분자와, 파이톤 가상 머신은 물질과 함께 작동한다.결국 모든 것이 아원자 입자(실제 기계 작동)로 분해되어야 하기 때문에 Python 가상 머신은 가장 복잡한 작업을 가지고 있다.

정적으로 정형화된 언어의 인터셉터/컴파일러는 동적으로 정형화된 언어의 인터프리터/컴파일러가 가지고 있는 것과 같은 짐을 가지고 있지 않다.정적인 형식의 언어의 프로그래머들은 느슨한 부분을 차지해야 하는데, 그 결과 성과가 나타난다.그러나 모든 비결정론적 기능들이 비밀리에 결정론적이듯이, 모든 동태적 언어들도 비밀리에 정전기적 형식이다.따라서 두 언어 제품군 간의 성능 차이는 파이썬이 HAL 9000으로 이름을 변경할 때쯤으로 밝혀져야 한다.

Python과 같은 동적 언어의 가상 머신은 이상화된 논리 머신을 구현하며, 반드시 실제 물리적 하드웨어와 매우 밀접하게 대응하지는 않는다.이와는 대조적으로 자바 가상 머신은 기계 명령을 방출하는 대신 내장 루틴을 실행한다는 점을 제외하면 일반 C 컴파일러와 기능이 더 유사하다.Python에서 정수는 많은 속성과 메서드가 붙어있는 Python 객체다.자바에서 int는 지정된 비트 수(일반적으로 32개)이다.그것은 사실 공정한 비교가 아니다.파이톤 정수는 정말로 자바 정수 클래스와 비교되어야 한다.Java의 "int" 원시 데이터 유형은 Python 언어의 어떤 것과도 비교할 수 없다. 왜냐하면 Python 언어는 단지 이 원시적인 층이 부족하기 때문이다. 그리고 Python 바이트코드 또한 그렇다.

자바 변수를 명시적으로 입력하기 때문에, Jython 성능 같은 것이 cPython과 같은 야구장에 있을 것이라고 합리적으로 기대할 수 있다.반면 파이톤에서 구현된 자바 가상 머신은 진흙보다 느릴 것이 거의 보장된다.그리고 루비, 펄 등이 더 나아질 것이라고 기대하지 마라.그들은 그렇게 하도록 설계되지 않았다.그것들은 "스크립팅"을 위해 고안되었는데, 이것은 역동적인 언어로 프로그래밍되는 것을 말한다.

가상 시스템에서 수행되는 모든 작업은 결국 실제 하드웨어를 타격해야 한다.가상 시스템에는 논리 연산 조합을 실행할 수 있을 정도로 일반적인 사전 컴파일된 루틴이 포함되어 있다.가상 머신은 새로운 시스템 명령을 방출하지 않을 수 있지만, 가상 머신은 분명 매우 복잡한 시퀀스에서 자체 루틴을 반복적으로 실행하고 있다.Java 가상 머신, Python 가상 머신, 그리고 그 밖의 모든 범용 가상 머신은 여러분이 꿈꿀 수 있는 어떤 논리를 수행하도록 구슬릴 수 있다는 점에서 동일하지만, 어떤 작업을 맡기고, 어떤 작업을 프로그래머에게 맡기는가에 있어서는 다르다.

Python용 Python은 완전한 Python 가상 머신이 아니라, 몇 줄의 코드를 컴파일할 수 있다고 생각하는 지점에서 일반 Python 가상 머신을 가로채는 적시 컴파일러(Just-in-Time 컴파일러)로, 주로 각 반복에 따라 값이 변화하더라도 일부 변수의 원시 유형이 일정하게 유지될 것이라고 생각하는 루프를 말한다.이 경우 일반 가상 머신의 끊임없는 유형 결정 중 일부를 포기할 수 있다.그래도 싸이코의 발밑에서 활자를 빼내지 않도록 조금 조심해야 한다.그러나 Pysco는 일반적으로 유형이 변경되지 않을 것이라고 완전히 확신하지 못하면 일반 가상 머신으로 다시 돌아가는 것을 알고 있다.

이야기의 교훈은 원시 데이터 유형 정보가 컴파일러/가상 시스템에 정말로 도움이 된다는 것이다.

마지막으로, 이를 모두 고려하십시오. Python 인터프리터/가상 머신이 Java에서 실행되는 Java에서 실행되는 Python 프로그램/가상 머신이 iPhone에서 실행되는 Qemu 가상 머신으로 실행되는 LLVM에서 실행되는 Python 프로그램을 참조하십시오.

퍼머링크

가상 머신은 특정 언어와 독립적으로 지원되는 특정 원자성 잘 정의된 명령어 집합을 가진 가상 컴퓨팅 환경이며, 일반적으로 샌드박스 그 자체로 간주된다.VM은 특정 CPU의 명령 집합과 유사하며 다음 명령(또는 바이트 코드)과 독립적인 매우 기본적인 구성 블록으로 보다 근본적인 수준에서 작동하는 경향이 있다.명령은 가상 시스템의 현재 상태에 대해서만 결정적으로 실행되며 해당 시점의 명령 스트림의 다른 위치에 있는 정보에 의존하지 않는다.

반면 통역사는 특정 언어의 일부 구문과 주변 토큰의 맥락에서 해독해야 하는 특정 문법의 흐름을 구문 분석하는 데 적합하다는 점에서 더욱 정교하다.각 바이트나 심지어 각 행을 분리해서 볼 수도 없고 다음에 무엇을 해야 할지 정확히 알 수도 없다.해당 언어의 토큰은 VM의 명령(바이트 코드)에 상대적일 수 있는 것처럼 분리하여 사용할 수 없다.

자바 컴파일러는 C 컴파일러가 C 언어 프로그램을 어셈블리 코드로 변환하는 것과 다를 바 없이 자바 언어를 바이트 코드 스트림으로 변환한다.반면에 통역사는 프로그램을 어떤 잘 정의된 중간 형태로 변환하는 것이 아니라, 단지 그 프로그램의 행동을 출처를 해석하는 과정의 문제로 받아들인다.

VM과 통역사의 차이에 대한 또 다른 테스트는 VM을 언어에 독립적인 것으로 생각하는가 하는 것이다.Java VM으로 알려진 것은 실제로 Java에 특정되지 않는다.다른 언어로 컴파일러를 만들어 JVM에서 실행할 수 있는 바이트 코드를 만들 수 있다.반면에, 나는 우리가 파이톤 통역사의 해석을 위해 파이톤 이외의 다른 언어를 파이톤으로 "컴파일"하는 것을 정말로 생각하지는 않을 것이라고 생각한다.

해석 과정의 정교함 때문에, 이것은 비교적 느린 과정이 될 수 있다.... 구체적으로 구문 분석과 언어 토큰 등을 식별하고, 통역사 내에서 실행 과정을 수행할 수 있는 출처의 맥락을 이해한다.이러한 해석 언어의 가속화를 돕기 위해, 여기서 우리는 보다 쉽게 직접 해석되는 사전 페이징, 사전 토큰화된 소스 코드의 중간 형식을 정의할 수 있다.이러한 종류의 이진 형식은 여전히 실행 시간에 해석된다. 그것은 단지 성능 향상을 위해 인간이 읽을 수 있는 훨씬 적은 형식에서 출발하는 것이다.그러나 그러한 형식을 실행하는 논리는 가상 머신이 아니다. 왜냐하면 그러한 코드들은 여전히 분리해서 취할 수 없기 때문이다. 주변의 토큰들의 맥락은 여전히 중요하기 때문이다. 그들은 이제 다른 컴퓨터 효율적 형태에 있다.

아마도 다른 용어의 한 가지 이유는 사람들이 보통 사람이 읽을 수 있는 원시 소스 코드를 먹이고 바이트 코드와 그 모든 것에 대해 걱정하지 않기 때문이다.

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

Python은 커버 아래 가상 머신을 사용하지만, 사용자 입장에서는 대부분의 경우 이 세부 사항을 무시할 수 있다.

인터프리터, 소스 코드를 어떤 효율적인 중간 표현(코드)으로 번역하고 이것을 즉시 실행한다.

가상 시스템, 인터프리터 시스템의 일부인 컴파일러에 의해 작성된 저장된 사전 컴파일 코드를 명시적으로 실행한다.

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

python의 경우, 만약 우리가 이 포스트의 코멘트에 언급된 것처럼, pyc 파일을 보관하고 있다면, 그 메커니즘은 VM에 더 가까워질 것이고, 그리고 이 바이트 코드는 더 빨리 실행될 것이다-- 그것은 여전히 해석될 것이지만 훨씬 더 컴퓨터 친화적인 형태에서.이것을 전체적으로 보면 PVM은 파이톤 인터프리터의 마지막 단계다.

요컨대, Python 인터프리터를 언급할 때, 그것은 우리가 PVM을 언급하고 있다는 것을 의미하며, 그것은 우리가 단지 런타임 환경인 Python 인터프리터의 일부에 대해 이야기하고 있다는 것을 의미한다.자바의 그것과 유사하게, 우리는 다른 요소들 differentyl, JRE, JVM, JDK 등을 참조한다.

자세한 내용은 위키백과 항목:인터프리터 및 가상 시스템.하지만 여기 또 하나 있어.여기에서 애플리케이션 가상 시스템 비교를 참조하십시오.컴파일러, 인터프리터 및 VM 간의 차이점을 이해하는 데 도움이 된다.

"왜 자바 가상 머신, 그러나 파이톤 통역?"이라는 질문에 대한 심도 있는 답을 제공하기 위해, 토론의 시작점에 대해서는 컴파일 이론의 영역으로 돌아가 보도록 하자.

일반적인 프로그램 컴파일 프로세스에는 다음 단계가 포함된다.

1. 어휘 분석.프로그램 텍스트를 토큰이라는 의미 있는 "단어"로 분할(프로그래밍 동작에 영향을 주지 않기 때문에 모든 주석, 공백, 새로운 줄 등)그 결과는 순서가 정해진 토큰 스트림이다.
2. 구문 분석.토큰 스트림에서 소위 추상 구문 트리(AST)를 구축한다.AST는 토큰 간의 관계를 설정하고 그 결과 프로그램의 평가 순서를 정의한다.
3. 의미 분석.프로그래밍 언어의 유형 및 의미 규칙 집합에 대한 정보를 사용하여 AST의 의미론적 정확성을 검증한다.(예를 들면,a = b + c구문론적 관점에서 보면 정확한 문장이지만, 의미론적 관점에서 보면 완전히 부정확하다.a상수 객체로 선언됨)
4. 중간 코드 생성.AST를 기계 독립 "기본" 작동의 선형 순서 스트림으로 직렬화.실제로 코드 생성기는 AST를 통과하고 평가 단계의 순서를 기록한다.그 결과, 프로그램의 트리 같은 표현으로부터, 프로그램 평가의 순서가 보존되는 훨씬 더 간단한 목록 같은 표현을 달성한다.
5. 기계 코드 생성.기계에 독립적인 "기본" 바이트 코드 형태의 프로그램은 특정 프로세서 아키텍처의 기계 코드로 변환된다.

자, 이제 용어를 정의해 봅시다.

그 단어의 고전적 의미로 해석자는 프로그램 텍스트에서 직접 생성된 AST에 기초한 프로그램 평가에 기초하여 실행을 가정한다.이 경우 프로그램은 소스 코드의 형태로 배포되고 통역자는 프로그램 텍스트로 제공되며, 자주 동적인 방법(문장별 또는 라인별)으로 제공된다.각 입력문에 대해, 통역자는 AST를 구축하고, 즉시 프로그램의 "상태"를 변경하는 것을 평가한다.이것은 대본 언어에 의해 증명된 전형적인 행동이다.예를 들어 Bash, Windows CMD 등을 고려해 보십시오.개념적으로 파이톤도 이 길을 택한다.

만약 우리가 중간 기계에 독립적인 바이너리 바이트 코드 단계의 생성에 관한 AST 기반 실행 단계를 대체한다면, 우리는 프로그램 실행의 전체 과정을 두 개의 별도 단계, 즉 컴파일과 실행으로 나눌 것이다.그 경우 이전에 통역관이던 것이 바이트코드 컴파일러가 되어 텍스트 형태에서 프로그램을 어떤 이진 형태로 변형시킨다.그러면 프로그램은 그 바이너리 형태로 배포되지만 소스 코드의 형태는 배포되지 않는다.사용자 머신에서, 그 바이트코드는 새로운 엔티티로 공급되는데, 가상 머신은 실제로 바이트코드를 해석한다.이 때문에 가상 머신을 바이트코드 인터프리터라고도 부른다.하지만 여기에 집중해!고전 통역은 텍스트 통역사지만 가상 머신은 바이너리 통역사!이것은 자바와 C#가 취한 접근법이다.

마지막으로, 우리가 바이트코드 컴파일러에 기계코드 생성을 추가한다면 우리는 우리가 고전 컴파일러라고 부르는 결과를 얻을 수 있다.클래식 컴파일러는 프로그램 소스 코드를 특정 프로세서의 기계 코드로 변환한다.그 기계 코드는 추가 조정 없이 대상 프로세서에서 직접 실행될 수 있다. (어떤 종류의 통역도 없이 텍스트 통역사도 바이너리 통역기도 없다.)

이제 원래의 질문으로 돌아가서 Java 대 Python을 생각해 봅시다.

자바는 처음에 가능한 한 적은 구현 의존성을 갖도록 설계되었다.그 디자인은 "한 번 쓰기, 어디서나 실행"(WORA) 원칙을 기반으로 한다.이를 구현하기 위해 자바(Java)는 초기에는 기계에 독립적인 이진 바이트 코드로 컴파일하는 프로그래밍 언어로 설계되었으며, 그 다음에는 재컴파일 없이도 자바를 지원하는 모든 플랫폼에서 실행할 수 있다.자바도 WORA 기반 C++처럼 생각할 수 있다.사실 자바어는 파이톤과 같은 스크립팅 언어보다 C++에 가깝다.그러나 C++와 대조적으로 자바는 바이너리 바이트 코드로 컴파일되어 가상 머신의 환경에서 실행되도록 설계되었고, C++는 머신 코드로 컴파일된 후 대상 프로세서에 의해 직접 실행되도록 설계되었다.

Python은 처음에 스크립트(프로그래밍 언어 규칙에 따라 쓰여진 텍스트 형태의 프로그램)를 해석하는 일종의 스크립팅 프로그램 언어로서 설계되었다.이 때문에 파이썬은 처음에는 바시나 윈도 CMD가 하는 것처럼 한 줄 명령이나 문장의 동적 해석을 지원해왔다.같은 이유로, Python의 초기 구현에는 내부에 그러한 바이트코드의 실행을 위한 어떤 종류의 바이트코드 컴파일러와 가상 머신이 없었지만, 처음부터 Python은 Python 프로그램 텍스트를 이해하고 평가할 수 있는 통역기가 필요했다.

이 때문에 역사적으로 자바 개발자들은 자바 가상 머신(Java Virtual Machine)에 대해 이야기하는 경향이 있었고(처음에는 자바 바이트코드 컴파일러와 바이트코드 통역기의 패키지로 자바를 등장시켰기 때문에 -- JVM), 파이썬 개발자들은 파이톤 통역기에 대해 이야기하는 경향이 있었다(Python은 처음에는 가상 머신이 없고 고전적인 텍스트 번역기의 일종이었기 때문이다).어떤 종류의 컴파일이나 바이너리 코드로의 변환 없이 프로그램 텍스트를 직접 실행하는 것).

현재 파이썬도 가상 머신을 후드 아래에 두고 있으며 파이썬 바이트코드를 컴파일하고 해석할 수 있다.그리고 그 사실은 "왜 Java Virtual Machine, 그러나 Python 통역?"이라는 혼란에 추가 투자를 하게 되는데, 두 언어의 구현에는 가상 머신이 포함되어 있는 것 같기 때문이다.하지만! 프로그램 텍스트의 현재 순간에도 해석은 파이썬 프로그램 실행의 일차적인 방법이다.Python 구현은 최적화 기법으로만 후드 아래 가상 머신을 활용한다.가상 머신에서 바이너리 바이트 코드의 해석은 원래 프로그램 텍스트의 직접 해석보다 훨씬 효율적이다.동시에 Python 언어 디자이너와 Python 프로그램 개발자 모두에게 가상 머신의 존재는 절대적으로 투명하다.가상 머신을 사용하는 경우와 사용하지 않는 경우 통역기에서 동일한 언어를 구현할 수 있다.같은 방법으로, 가상 머신이 있는 곳과 없는 곳에서 동일한 프로그램을 실행할 수 있으며, 그 프로그램은 정확히 동일한 동작을 보여주고 동일한 입력으로부터 동일한 출력을 산출할 것이다.관측 가능한 유일한 차이는 프로그램 실행 속도와 통역사가 소비하는 메모리 양일 것이다.따라서 Python의 가상 머신은 언어 설계에서 피할 수 없는 부분이 아니라 주요 Python 통역사의 선택적 확장일 뿐이다.

자바도 비슷한 방식으로 생각할 수 있다.후드 아래 자바에는 JIT 컴파일러가 있으며, 자바 클래스의 방법을 선택적으로 대상 플랫폼의 머신 코드로 컴파일한 후 직접 실행할 수 있다.하지만! 자바는 여전히 자바 프로그램 실행의 주요 방법으로 바이트코드 해석을 사용한다.가상 머신을 최적화 기법으로 독점적으로 이용하는 Python 구현과 마찬가지로 Java 가상 머신은 최적화 목적으로만 Just-In-Time 컴파일러를 사용한다.마찬가지로 기계코드의 직접 실행이 자바 바이트코드의 해석보다 최소 10배 이상 빠르다는 사실만으로 말이다.그리고 파이썬의 경우와 마찬가지로 JVM의 후드 아래 JIT 컴파일러의 존재는 자바어 디자이너와 자바 프로그램 개발자 모두에게 절대적으로 투명하다.JIT 컴파일러의 유무에 따라 JVM에 의해 동일한 Java 프로그래밍 언어가 구현될 수 있다.그리고 같은 방법으로, 동일한 프로그램을 JIT가 내부에 있는 경우와 없는 경우 JVM에서 실행할 수 있으며, 동일한 프로그램은 정확히 동일한 동작을 입증하고 JVM 양쪽(JIT가 있는 경우와 없는 경우)에 대한 동일한 입력으로부터 동일한 출력을 산출할 것이다.그리고 파이썬의 경우와 마찬가지로 그들 사이의 유일한 관찰 가능한 차이는 실행 속도와 JVM이 소비하는 메모리 양에 있을 것이다.그리고 마지막으로 파이썬의 경우와 마찬가지로 자바에서의 JIT 역시 언어 설계에서 피할 수 없는 부분이 아니라 주요 JVM 구현의 선택적 확장일 뿐이다.

Java와 Python의 가상 머신의 설계와 구현의 관점에서는 크게 다른 반면 (관심!) 둘 다 여전히 가상 머신에 머무르고 있다.JVM은 간단한 기본 운영과 높은 명령 디스패치 비용을 가진 낮은 수준의 가상 머신의 예다.파이썬은 고급 가상 머신으로, 명령어가 복잡한 동작을 보여주며 명령어 발송 비용이 그리 크지 않다.자바는 매우 낮은 추상화 수준으로 운영된다.JVM은 잘 정의된 소규모 원시 유형 집합에서 작동하며 바이트 코드 지침과 네이티브 머신 코드 지침 사이에 매우 긴밀하게 대응된다(일반적으로 1 대 1).반대로 파이톤 가상 머신은 높은 추상화 수준에서 작동하며 복잡한 데이터 유형(객체)으로 작동하며 ad-hoc 다형성을 지원하는 반면, 바이트코드 명령어는 복잡한 동작을 노출시켜 일련의 다중 네이티브 머신 코드 명령으로 나타낼 수 있다.예를 들어, Python은 무한 범위 수학을 지원한다.따라서 Python VM은 작업 결과가 기계 단어를 오버플로할 수 있는 잠재적으로 큰 정수를 위해 긴 산술적 산술을 이용하도록 강제된다.따라서 Python에서 산술에 대한 1바이트 코드 명령은 Python VM 내부의 함수 호출에 노출될 수 있는 반면, JVM 산술 연산에서는 하나 또는 소수의 네이티브 머신 지침에 의해 표현되는 간단한 작동에 노출될 수 있다.

결과적으로 우리는 다음 결론을 도출할 수 있다.Java Virtual Machine을 사용하지만 Python 통역기는 다음과 같은 이유:

1. 가상 머신의 용어는 이진 바이트 코드 해석을 가정하는 반면, 해석기 용어는 프로그램 텍스트 해석을 가정한다.
2. 역사적으로 자바(Java)는 이진 바이트 코드 해석을 위해 설계되고 구현되었으며, 파이썬은 프로그램 텍스트 해석을 위해 처음 설계되고 구현되었다.따라서 자바 가상 머신(Java Virtual Machine)이라는 용어는 역사적이고 자바 커뮤니티에서 잘 확립되어 있다.그리고 비슷하게 파이톤 통역이라는 용어는 역사적이고 파이톤 사회에서 잘 확립되어 있다.사람들은 전통을 연장하고 오래 전에 사용되었던 것과 같은 용어를 사용하는 경향이 있다.
3. 마지막으로, 현재 자바에게 바이너리 바이트 코드 해석은 프로그램 실행의 일차적인 방법인 반면, JIT 컴필레이션은 선택적이고 투명한 최적화일 뿐이다.그리고 Python에게 있어서, 현재 프로그램 텍스트 해석은 Python 프로그램 실행의 일차적인 방법인 반면, Python VM 바이트 코드로의 컴파일은 선택적이고 투명한 최적화일 뿐이다.

---

따라서 가상 머신을 가진 자바와 파이썬 모두 바이너리 바이트코드 인터프리터가 있어 '자바 가상 머신이 왜 파이썬 인터프리터인가'와 같은 혼란을 초래할 수 있다.여기서 중요한 점은 Python에게 가상 머신은 프로그램 실행의 기본 또는 필수 수단이 아니며, 이는 고전 텍스트 통역기의 선택적 확장일 뿐이라는 것이다.반면 가상 머신은 자바 프로그램 실행 생태계의 핵심이자 피할 수 없는 부분이다.프로그래밍 언어 설계를 위한 정적 또는 동적 타이핑 선택은 주로 가상 시스템 추상화 수준에만 영향을 미치지만 가상 시스템이 필요한지 여부를 지시하지는 않는다.두 타이핑 시스템을 모두 사용하는 언어는 원하는 실행 모델에 따라 가상 머신의 환경 내에서 컴파일, 해석 또는 실행되도록 설계할 수 있다.

통역사라는 용어는 이전의 셸 스크립팅 언어에서 유래한 유구한 용어다.'스크립팅 언어'가 완전한 피처링 언어로 발전하고 그에 상응하는 플랫폼이 더욱 정교해지고 샌드박스화됨에 따라 가상 머신과 통역(파이톤 의미)의 구분이 매우 작거나 존재하지 않는다.

The Python interpreter still functions in the same way as a shell script, in the sense that it can be executed without a separate compile step. Beyond that, the differences between Python's interpreter (or Perl or Ruby's) and Java's virtual machine are mostly implementation details. (One could argue that Java is more fully sandboxed than Python, but both ultimately provide access to the underlying architecture via a native C interface.)

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

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!

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.

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.

for posts that mention that python does not need to generate byte code, I'm not sure that's true. it seems that all callables in Python must have a .__code__.co_code attribute which contains the byte code. I don't see a meaningful reason to call python "not compiled" just because the compiled artifacts may not be saved; and often aren't saved by design in Python, for example all comprehension compile new bytecode for it's input, this is the reason comprehension variable scope is not consistent between compile(mode='exec, ...) and compile compile(mode='single', ...) such as between running a python script and using pdb

There actually might be a reason why the HotSpot runtime is called a Virtual Machine while CPython is merely referred to as an interpreter

Firstly, CPython is just your average run of the mill, stack based, bytecode interpreter. You input Python opcode into it, and the software stack machine inside CPython evaluates your code, just like a normal Interpreter would.

The Java HotSpot runtime is different. First and foremost, Java has 3 Just-in Time Compilers, C1, C2, and an experimental one that isn't in use yet. But that's not the main reason. The Interpreter inside the JVM is a very special kind of Interpreter called a Template Interpreter. Instead of just executing bytecode directly in a massive opcode switch case statement like CPython (And really almost every other interpreter does) does, the Template Interpreter inside the JVM contains an enormous arraylist. What does it contain? Key-value pairs of bytecodes and native CPU instructions! The arraylist is empty on startup and is filled with mappings of bytecodes pointing to native machine language to be directly run on the hardware just before your application starts up, what this means is that the "Interpreter" inside the JVM isn't actually an Interpreter at all- It's actually a discount Compiler! When Java bytecode is run, the "Interpreter" simply maps the input bytecode directly to native machine language and executes the native mapping directly, rather than implementing it in software. I'm not exactly sure why the JVM was made this way, but I suspect it was to easily execute "Interpreted" Code together with JIT Compiled Code seamlessly, and for speed/performance. If you pitted the JVM without JIT against CPython or most other interpreters it would still probably come out ahead of them, in virtue of its ingenious design which to my knowledge no other language has used before.

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