컴파일된 vs.해석된 언어

컴파일된 vs.해석된 언어

나는 그 차이를 더 잘 이해하려고 노력하고 있다.온라인에서 많은 설명을 찾았지만, 실제적인 의미보다는 추상적인 차이를 지향하는 경향이 있다.

나의 프로그래밍 경험의 대부분은 CPython(동적, 해석적), Java(정적, 컴파일된)에 있었다.하지만 다른 종류의 해석과 편찬된 언어도 있는 것으로 알고 있다.컴파일된 언어로 작성된 프로그램에서 실행 파일을 배포할 수 있다는 사실 이외에도, 각 유형별로 장점/불편점이 있는가?종종, 나는 사람들이 해석된 언어는 대화적으로 사용될 수 있다고 주장하는 것을 듣지만, 나는 컴파일된 언어도 대화형 구현을 할 수 있다고 믿는다, 맞지?

편찬된 언어는 일단 편찬된 프로그램이 대상 기계의 지시로 표현되는 것을 말한다.예를 들어, 소스 코드의 추가 "+" 작업은 기계 코드의 "추가" 명령으로 직접 변환될 수 있다.

해석된 언어는 지시사항이 대상 기계에 의해 직접 실행되지 않고, 대신 다른 프로그램(보통 원주민 기계 언어로 작성됨)에 의해 읽고 실행하는 언어다.예를 들어, 동일한 "+" 연산은 런타임에 통역사가 인식하며, 적절한 인수를 가진 자체 "add(a,b)" 함수를 호출하여 기계 코드 "ADD" 명령을 실행한다.

당신은 컴파일된 언어와 그 반대로 해석된 언어로 당신이 할 수 있는 모든 것을 할 수 있다 - 그들은 둘 다 튜링완료다.그러나 두 가지 모두 구현과 사용에 장단점이 있다.

나는 완전히 일반화 할 것이다(청산주의자들은 나를 용서한다!) 하지만, 대략, 여기에 편찬된 언어의 이점이 있다.

• 대상 시스템의 네이티브 코드를 직접 사용하여 성능 향상
• 컴파일 단계에서 상당히 강력한 최적화를 적용할 수 있는 기회

그리고 해석 언어의 장점은 다음과 같다.

• 구현이 용이함(좋은 컴파일러를 쓰는 것은 매우 어렵다!!)
• 컴파일 단계 실행 필요 없음: 코드를 "즉각"으로 직접 실행할 수 있음
• 동적 언어에 더 편리할 수 있음

바이트 코드 컴파일과 같은 현대적 기술은 약간의 추가적인 복잡성을 더한다는 점에 유의하십시오. 여기서 발생하는 것은 컴파일러가 기본 하드웨어와 같지 않은 "가상 머신"을 목표로 한다는 것이다.그런 다음 이러한 가상 시스템 지침을 나중에 다시 컴파일하여 네이티브 코드를 가져올 수 있다(예: Java JVM JIT 컴파일러에서 수행).

언어 자체는 편찬되거나 해석되지 않으며, 언어의 특정한 구현만이 가능하다.자바는 완벽한 예다.바이트코드 기반 플랫폼(JVM), 네이티브 컴파일러(gcj), 자바(bsh)의 상위 집합용 인터피터가 있다.그래서 지금 자바란 무엇인가?바이트 코드 컴파일, 네이티브 컴파일 또는 해석?

해석뿐만 아니라 편찬되는 다른 언어로는 스칼라, 하스켈 또는 오캄이 있다.이들 각 언어에는 바이트 코드 또는 네이티브 머신 코드에 대한 컴파일러뿐만 아니라 인터랙티브 인터프리터가 있다.

그래서 일반적으로 언어를 "컴파일"과 "해석"으로 분류하는 것은 그다지 말이 되지 않는다.

과거로부터의 폭발이라는 관점에서 생각하기 시작하라.

옛날에, 아주 오래 전에, 컴퓨터 통역사와 컴파일러의 나라에 살았다.한 사람의 장점을 놓고 다른 한 사람에 대한 온갖 소동이 뒤따랐다.당시의 일반의견은 다음과 같은 선에 따른 것이었다.

• 통역자:빠른 개발(편집 및 실행)각 문장이 실행될 때마다 기계 코드로 해석되어야 했기 때문에 실행이 느리다(수천 번 실행된 루프에 대해 이것이 무엇을 의미하는지 생각해 보십시오).
• 컴파일러:개발 속도가 느림(편집, 컴파일, 링크 및 실행)컴파일/링크 단계는 심각한 시간이 걸릴 수 있다.)실행 속도가 빠름.프로그램 전체가 이미 네이티브 머신 코드로 되어 있었다.

해석된 프로그램과 컴파일된 프로그램 사이에는 런타임 성능의 한두 가지 정도의 차이가 존재했다.예를 들어, 코드의 런타임 변이성 등 다른 구분점들도 일부 관심이 있었지만 주요 구분점은 런타임 성능 문제를 중심으로 이루어졌다.

오늘날 풍경은 편찬/해석된 구별은 거의 무관할 정도로 진화했다.컴파일된 많은 언어는 완전히 기계 코드에 기반하지 않은 런타임 서비스를 호출한다.또한 대부분의 해석 언어들은 실행 전에 바이트 코드로 "컴파일"된다.바이트 코드 인터프리터는 매우 효율적이며 실행 속도 관점에서 일부 컴파일러 생성 코드에 필적할 수 있다.

전형적인 차이점은 컴파일러가 원시 머신 코드를 생성하고, 인터프리터가 소스 코드를 읽고, 런타임 시스템을 사용하여 머신 코드를 즉시 생성했다는 것이다.오늘날에는 고전적인 통역사가 거의 남아 있지 않다. 거의 모든 통역사가 바이트 코드(또는 일부 다른 반컴파일 상태)로 컴파일되어 가상의 "기계"에서 실행된다.

극단적이고 간단한 사례:

• 컴파일러는 대상 시스템의 기본 실행 파일 형식으로 이진 실행 파일을 생성한다.이 이진 파일은 시스템 라이브러리를 제외한 모든 필요한 리소스를 포함하고 있으므로 추가 준비 및 처리 없이 실행할 수 있으며 코드가 대상 시스템의 CPU에 대한 네이티브 코드이기 때문에 번개처럼 실행된다.

• 통역사는 사용자에게 문이나 코드를 입력할 수 있는 루프에서, 그리고 때릴 때 프롬프트를 제시한다.RUN또는 프로그램이 정지 지점 또는 오류까지 실행될 때까지 통역이 각 라인을 검사, 스캔, 구문 분석 및 해석할 수 있는 동등한 값.각 행은 스스로 처리하고 통역은 그 행을 전에 본 적이 있는 것으로부터 아무것도 '배우는' 것이 없기 때문에, 사람이 읽을 수 있는 언어를 기계지시로 전환하려는 노력이 행마다 매번 발생하기 때문에 개는 느리다.긍정적인 측면에서 사용자는 다음과 같은 모든 방법으로 자신의 프로그램을 검사하고 다른 방법으로 상호작용할 수 있다.변수 변경, 코드 변경, 추적 또는 디버그 모드에서 실행 중...어떻든 간에

이런 것들을 벗어났으니, 이제 인생은 더 이상 그렇게 간단하지 않다는 것을 설명하겠다.예를 들어.

• 많은 통역사들이 주어진 코드를 미리 컴파일하여 번역 단계를 반복할 필요가 없도록 할 것이다.
• 일부 컴파일러는 CPU별 기계 지침이 아닌 가상 기계에 대한 인공 기계 코드의 일종인 바이트 코드로 컴파일한다.이것은 컴파일된 프로그램을 좀 더 이동 가능하게 만들지만, 모든 대상 시스템에 바이트 코드 통역기가 필요하다.
• 바이트코드 인터프리터(여기서 자바를 보고 있다)는 최근 실행 직전(JIT라고 함) 대상 섹션의 CPU에 대해 얻은 바이트코드를 다시 컴파일하는 경향이 있다.시간을 절약하기 위해 자주 실행되는 코드(핫스팟)에 대해서만 이 작업을 수행하는 경우가 많다.
• 통역자처럼 보이고 행동하는 일부 시스템(예를 들어, Clojure)은 그들이 얻는 코드를 즉시 컴파일하지만 프로그램의 환경에 대한 대화형 액세스를 허용한다.그것이 기본적으로 바이너리 컴파일 속도의 통역사의 편리함이다.
• 어떤 컴파일러들은 실제로 컴파일을 하지 않고, 단지 미리 소거하고 코드를 압축한다.얼마 전에 펄이 그렇게 작동한다고 들었어.그래서 때때로 컴파일러는 단지 약간의 일을 하고 있을 뿐이고 그 대부분은 여전히 해석이다.

결국, 요즈음은 해석 대 컴파일이 트레이드오프(trade-off)로서, 컴파일에 소비되는 시간(한 번)은 종종 더 나은 런타임 성과에 의해 보상되지만, 해석적인 환경은 상호작용의 기회를 더 많이 준다.컴파일 대 해석은 대부분 프로그램을 '이해'하는 작업이 서로 다른 과정으로 어떻게 나뉘느냐의 문제인데, 요즘은 언어와 제품이 양쪽 세계의 장점을 제공하려 하기 때문에 선이 약간 흐릿하다.

출처: http://www.quora.com/What-is-the-difference-between-compiled-and-interpreted-programming-languages

"컴파일된 프로그래밍 언어"와 "해석된 프로그래밍 언어"는 의미 있는 개념이 아니기 때문에 차이가 없다.어떤 프로그래밍 언어든, 내 말은, 정말로, 해석되거나 편집될 수 있다.그러므로 해석과 편찬은 언어의 속성이 아니라 실행 기법이다.

해석은 다른 프로그램인 통역사가 프로그램을 실행하기 위해 해석되는 프로그램을 대신하여 작업을 수행하는 기법이다.만약 여러분이 프로그램을 읽고, 스크래치 페이퍼에 대고 말하는 것을 단계별로 하는 것을 상상할 수 있다면, 그것은 통역사도 하는 것이다.프로그램을 해석하는 일반적인 이유는 통역사가 비교적 쓰기 쉽기 때문이다.또 다른 이유는 통역이 프로그램이 실행될 때, 말하자면 보안을 위해 정책을 시행하기 위해 무엇을 하려고 하는지 감시할 수 있기 때문이다.

컴파일은 한 언어("소스 언어")로 쓰여진 프로그램을 다른 언어("객체 언어")의 프로그램으로 번역하는 기법인데, 이것은 희망컨대 원래의 프로그램과 같은 것을 의미한다.번역을 하는 동안 컴파일러도 (의미를 바꾸지 않고) 오브젝트 프로그램을 더 빨리 만들 수 있는 방법으로 프로그램을 변형시키려 하는 것이 일반적이다.프로그램을 컴파일하는 일반적인 이유는 도중에 소스 언어를 해석하는 오버헤드 없이 객체 언어로 프로그램을 빠르게 실행할 수 있는 좋은 방법이 있기 때문이다.

위의 정의에 근거하여 이 두 구현 기법이 상호 배타적이지 않으며, 심지어 상호 보완적일 수도 있다고 추측했을 수 있다.전통적으로 컴파일러의 객체 언어는 기계 코드 또는 유사한 것으로, 특정 컴퓨터 CPU가 이해하는 프로그래밍 언어의 수를 의미한다.그러면 기계 코드는 "금속 위에서" 실행될 것이다. (하지만 자세히 보면 "금속"이 통역사처럼 많이 작동한다는 것을 알 수 있다.)그러나 오늘날에는 컴파일러를 사용하여 해석해야 할 객체 코드를 생성하는 것이 매우 일반적이다. 예를 들어, 자바(Java)는 과거에 (그리고 때로는 지금도) 이렇게 작동한다.다른 언어를 JavaScript로 변환하는 컴파일러가 있는데, 이 컴파일러는 종종 웹 브라우저에서 실행되어 JavaScript를 해석하거나 가상 머신이나 네이티브 코드를 컴파일할 수 있다.우리는 또한 기계 코드에 대한 통역사를 가지고 있는데, 그것은 다른 종류의 하드웨어를 모방하는데 사용될 수 있다.또는 컴파일러를 사용하여 다른 컴파일러의 소스 코드인 객체 코드를 생성할 수도 있고, 실행될 시간에 맞춰 메모리에 코드를 컴파일할 수도 있는데, 그 아이디어는 이해하셨을 겁니다.이 개념들을 결합하는 많은 방법들이 있다.

컴파일된 소스 코드보다 해석된 소스 코드의 가장 큰 장점은 이식성이다.

소스 코드가 컴파일된 경우 프로그램을 실행할 프로세서 및/또는 플랫폼 유형(예: 윈도우즈 x86용, 윈도우즈 x64용, 리눅스 x64용)에 대해 다른 실행 파일을 컴파일해야 한다.게다가, 당신의 코드가 완전히 표준을 준수하고 어떤 플랫폼별 기능/라이브러리도 사용하지 않는 한, 당신은 실제로 복수의 코드 베이스를 쓰고 유지할 필요가 있을 것이다!

소스 코드가 해석되면 한 번만 작성하면 되고 어느 플랫폼에서든 적절한 통역자가 해석하고 실행할 수 있다!휴대할 수 있어!통역자 자체가 특정 플랫폼에 대해 작성 및 컴파일되는 실행 가능한 프로그램이라는 점에 유의하십시오.

컴파일된 코드의 장점은 인간이 읽을 수 있는 원본 코드를 배포하는 대신 모호한 이진 실행 파일을 배포하기 때문에 최종 사용자(지식재산권일 수 있음)로부터 소스 코드를 숨긴다는 것이다.

컴파일러와 통역자는 같은 일을 한다: 프로그래밍 언어를 보통 하드웨어에 더 가깝고 종종 직접 실행 가능한 기계 코드에 가까운 다른 pgoramming 언어로 번역한다.

전통적으로, "컴파일"은 이 번역이 모두 한 번에 이루어지며, 개발자에 의해 수행되며, 그 결과 실행 가능한 것이 사용자에게 배포된다는 것을 의미한다.순수한 예: C++. 컴파일은 보통 꽤 오래 걸리고 결과 실행이 더 빨리 실행되도록 값비싼 옵티메이션을 많이 시도한다.최종 사용자는 스스로 내용을 컴파일할 수 있는 툴과 지식이 없고, 실행 파일은 다양한 하드웨어에서 실행해야 하는 경우가 많아 하드웨어별 최적화를 많이 할 수 없다.개발 중에 별도 컴파일 단계는 피드백 주기가 더 길다는 것을 의미한다.

전통적으로 "해석"은 사용자가 프로그램을 실행하고자 할 때 "즉시" 번역이 이루어진다는 것을 의미한다.순수한 예: 바닐라 PHP.순진한 통역사는 매번 실행될 때마다 코드 하나하나를 구문 분석하여 번역해야 하기 때문에 매우 느리게 된다.복잡하고 비용이 많이 드는 최적화는 실행할 때 절약되는 시간보다 더 오래 걸리기 때문에 수행할 수 없다.그러나 실행 중인 하드웨어의 기능을 충분히 사용할 수 있다.분리율 컴파일 단계가 없기 때문에 개발 중 피드백 시간이 단축된다.

그러나 오늘날 "컴파일 대 해석"은 흑백 문제가 아니라 그 사이에 그늘이 있다.순진하고 단순한 통역사는 거의 멸종되었다.많은 언어는 높은 수준의 코드가 플랫폼 독립 바이트 코드(해석 속도가 훨씬 빠름)로 번역되는 2단계 프로세스를 사용한다.그러면 프로그램 실행당 최대 한 번에 코드를 컴파일하고, 때로는 결과를 캐시하며, 드물게 실행되는 코드를 지능적으로 해석하고, 많이 실행되는 코드에 대해 강력한 최적화를 수행하는 "정시 컴파일러"가 있다.개발 중에 디버거는 전통적으로 컴파일된 언어에도 실행 중인 프로그램 내에서 코드를 전환할 수 있다.

첫째로, 설명하자면, 자바는 완전히 정적 컴파일되지 않고 C++ 방식으로 연결된다.바이트 코드로 컴파일되며, 그 다음 JVM에 의해 해석된다.JVM은 가서 네이티브 머신 언어로 적시 컴파일을 할 수 있지만, 굳이 할 필요는 없다.

자세한 내용은 다음을 참조하십시오.나는 상호작용성이 가장 큰 실질적인 차이점이라고 생각한다.모든 것이 해석되기 때문에 코드를 조금씩 발췌하여 구문 분석하여 환경의 현 상태에 반하여 실행할 수 있다.따라서 변수를 초기화한 코드를 이미 실행했다면 그 변수에 대한 액세스 권한 등을 갖게 될 것이다.그것은 기능적인 스타일과 같은 것에 정말로 자신을 빌려준다.

그러나 해석은 비용이 많이 들고, 특히 참조와 문맥이 많은 큰 시스템을 가지고 있을 때는 특히 비용이 많이 든다.정의상 동일한 코드를 두 번 해석하고 최적화해야 할 수 있기 때문에 낭비적이다(대부분의 런타임에는 그에 대한 캐싱과 최적화가 있다.그럼에도 불구하고 당신은 런타임 비용을 지불하고 종종 런타임 환경이 필요하다.또한 당신은 현재 그들의 성능이 충분히 상호작용하지 않기 때문에 복잡한 절차간 최적화를 볼 가능성이 적다.

따라서 큰 변화가 없는 대형 시스템, 특정 언어의 경우 모든 것을 사전 컴파일하고 사전 링크하는 것이 더 이치에 맞다. 할 수 있는 모든 최적화를 한다.이는 결국 대상 시스템에 이미 최적화되어 있는 매우 희박한 런타임이 된다.

실행 파일 생성에 관해서는, 그것은 IMHO와 거의 관련이 없다.컴파일된 언어로 실행 파일을 만들 수 있는 경우가 많다.그러나 통역사와 런타임은 이미 탐지 가능으로 포장되어 있고 당신에게 숨겨져 있다는 점을 제외하고는 해석된 언어로 실행 가능한 파일을 만들 수도 있다.이것은 당신이 일반적으로 여전히 런타임 비용을 지불한다는 것을 의미한다.

나는 모든 언어가 상호작용으로 만들어질 수 있다는 것에 동의하지 않는다.C와 같은 특정 언어는 기계와 전체 링크 구조에 너무 얽매여 있어서 의미 있는 완전한 인터랙티브 버전을 만들 수 있을지 잘 모르겠다.

이것은 내가 추측하기에 컴퓨터 과학에서 가장 큰 오해를 받고 있는 것 중 하나이다.왜냐하면 해석과 편찬은 전혀 다른 두 가지, 이런 식으로 비교할 수 없기 때문이다.

편찬은 한 언어를 다른 언어로 번역하는 과정이다.컴필레이션의 종류는 거의 없다.

• 컴파일 - 고급 언어를 기계/바이트 코드로 변환(예: C/C++/Java)
• Transpiling - 고급 언어를 다른 고급 언어로 변환(예: TypeScript)

해석은 프로그램을 실제로 실행하는 과정이다.이것은 몇 가지 다른 방법으로 일어날 수 있다.

• 기계 수준 해석 - 이 해석은 기계 코드로 컴파일되는 코드에 발생한다.지시사항은 프로세서에 의해 직접 해석된다.C/C++와 같은 프로그래밍 언어는 프로세서에서 실행 가능한 컴퓨터 코드를 생성한다.그래서 프로세서가 이러한 지시를 직접 실행할 수 있다.

• 가상 시스템 수준 해석 - 이 해석은 시스템 수준(프로세서 지원) 코드로 컴파일되지 않고 일부 중간 수준 코드로 컴파일되는 코드에 발생한다.이 실행은 프로세서에 의해 실행되는 다른 소프트웨어에 의해 수행된다.현재 프로세서가 우리의 애플리케이션을 보지 못하고 있다.애플리케이션 실행 중인 가상 시스템을 실행하는 것뿐입니다.Java, Python, C#와 같은 프로그래밍 언어는 가상 인터프리터/머신에 의해 실행 가능한 바이트 코드를 생성한다.

그래서 결국 우리가 이해해야 할 것은 세상의 모든 프로그래밍 언어는 언젠가는 해석되어야 한다는 것이다.프로세서(하드웨어) 또는 가상 머신에 의해 수행될 수 있다.

컴파일은 인간이 이해할 수 있는 높은 수준의 코드를 하드웨어/소프트웨어 기계의 이해할 수 있는 수준으로 가져오는 과정일 뿐이다.

이건 완전히 다른 두 가지인데, 우리가 비교할 수 없는 겁니다.하지만 그 용어는 초보자들에게 프로그래밍 언어가 어떻게 작동하는지 가르쳐주기에 아주 좋다.

PS:
자바와 같은 일부 프로그래밍 언어들은 이것을 하기 위한 하이브리드 접근법을 가지고 있다.첫째, 높은 수준의 코드를 가상 머신을 읽을 수 있는 바이트 코드로 컴파일하십시오.그리고 즉석에서 JIT 컴파일러라는 구성요소는 바이트 코드를 기계 코드로 컴파일한다.구체적으로는 몇 번이고 실행된 코드 라인이 기계어로 번역되어 해석 과정이 훨씬 빨라진다.하드웨어 프로세서가 항상 가상 인터프리터/프로세서보다 훨씬 빠르기 때문이다.

Java JIT 컴파일러의 작동 방식

언어의 정의 자체에 대한 차이점이 있기 때문에 실제적인 답변을 하는 것은 다소 어렵다.모든 컴파일된 언어에 대해 통역을 만드는 것은 가능하지만, 모든 번역된 언어에 대해 컴파일러를 만드는 것은 불가능하다.그것은 언어의 공식적인 정의에 관한 것이다.이론적 정보학자들이 대학에서 좋아하는 거군

파이썬 북 © 2015 이매진 출판사는 단순히 10페이지에서 언급된 다음과 같은 힌트로 차이를 구분한다.

Python과 같이 해석된 언어는 프로그램이 실행될 때마다 소스 코드를 기계 코드로 변환한 다음 실행하는 언어다.이는 C와 같이 컴파일된 언어와 다른데, 소스 코드는 한 번만 기계 코드로 변환되며, 그 결과 기계 코드는 프로그램이 실행될 때마다 실행된다.

컴파일이란 컴파일된 프로그래밍 언어로 작성된 코드에서 실행 가능한 프로그램을 만드는 과정이다.컴파일을 하면 컴퓨터는 프로그램을 만드는 데 사용되는 프로그래밍 소프트웨어의 필요 없이 프로그램을 실행하고 이해할 수 있다.프로그램을 컴파일할 때, IBM 호환 컴퓨터와 작동하는 특정 플랫폼(예: IBM 플랫폼)을 위해 컴파일되는 경우가 많지만, 다른 플랫폼(예: Apple 플랫폼)은 컴파일하지 않는다.첫 컴파일러는 Grace Hopper에 의해 하버드 마크 1 컴퓨터로 작업하면서 개발되었다.오늘날 대부분의 고급 언어는 자체 컴파일러를 포함하거나 프로그램을 컴파일하는 데 사용할 수 있는 툴킷을 가질 것이다.자바와 함께 사용되는 컴파일러의 좋은 예는 Eclipse이고, C와 C++와 함께 사용되는 컴파일러의 예는 gcc 명령이다.프로그램의 크기에 따라 컴파일하는 데 몇 초 또는 몇 분이 걸리고 컴파일되는 동안 오류가 발생하지 않으면 실행 파일이 생성된다.이 정보를 확인하다

짧은(정밀하지 않은) 정의:

컴파일된 언어:전체 프로그램이 한 번에 기계 코드로 변환된 다음, 기계 코드는 CPU에 의해 실행된다.

해석 언어:프로그램은 라인별로 읽히고 라인이 읽히는 즉시 CPU에 의해 해당 라인에 대한 기계 지침이 실행된다.

그러나 실제로, 오늘날에는 순수하게 편찬되거나 순수하게 해석되는 언어가 거의 없으며, 종종 혼용된다.사진에 대한 자세한 설명은 다음 스레드를 참조하십시오.

편찬과 해석의 차이는 무엇인가?

또는 나중에 블로그 게시물:

https://orangejuiceliberationfront.com/the-difference-between-compiler-and-interpreter/

참조URL: https://stackoverflow.com/questions/3265357/compiled-vs-interpreted-languages