인터프리터: 두 판 사이의 차이

잔글 (문자열 찾아 바꾸기 - "는거" 문자열을 "는 거" 문자열로)
편집 요약 없음
7번째 줄: 7번째 줄:
== 더 보기 ==
== 더 보기 ==
* [[컴파일러]]
* [[컴파일러]]
* [[Just-in-Time 컴파일]]
* [[Just-in-time 컴파일]]


== 주석 ==
== 주석 ==
<references>
<references>
[[분류:컴퓨터 프로그래밍]]

2015년 5월 5일 (화) 00:53 판

프로그래밍 언어로 된 코드를 입력받아, 자기가 그 코드에 적힌 프로그램의 내용을 수행하는 컴퓨터 프로그램. 마치 해당 프로그래밍 언어가 기계어인 또 다른 컴퓨터처럼 동작한다는 점에서 가상 머신과 궤를 같이 한다고 볼 수도 있다. 컴파일러와는 달리 코드를 한줄씩 즉석에서 번역하는데, 이로인해 수정이 간단한 등 많은 장점이 있다. 특히 코드 중에 한글자 삑사리나면 망하는 컴파일러와는 달리, 인터프리터는 일단 삑사리가 날 때까지는 정상적으로 실행해준다. 하지만 이로인해 속도가 더럽게 느리다는 단점이 있어서, 복잡한 프로그램을 만들 때는 선호되지 않는다. 스크립트 언어로 OS 짜는 거 본 사람?[1] 비유하자면 컴파일러가 번역가, 인터프리터가 동시통역사라고 할 수 있다.

지금은 상상하기 힘든 일이지만, 컴파일러 기술이 발달하기 전에는 컴파일 결과로 나온 프로그램의 실행 속도보다 그 프로그램을 그냥 인터프리터로 돌리는 게 빨랐던 때도 있었다. BASIC과 같은 언어들이 그런 시절의 산실이라 할 수 있다. 물론 현 세대의 컴파일러 기술은 더 이상 인간이 손으로 어셈블리 코드를 짜서는 따라잡을 수 없는 수준으로 발전했기에, 현재는 인터프리터와 컴파일된 실행 파일 사이에는 거의 10의 배수 수준의 실행 속도 격차가 존재한다.

정말로 매번 실행할 때마다 코드를 파싱해서 한 줄 한 줄 실행하는 식으로 동작하던 인터프리터도 많았지만, 실행 성능을 올리기 위해서 요즘은 Python이나 Ruby 같은 웬만한 스크립트 언어들도 바이트코드 컴파일 정도는 하고 있다. 좀 더 본격적으로는 Just-in-time 컴파일을 구현하는 경우도 있으며, JavaScriptV8 엔진, PythonPyPy, LuaLuaJIT 등이 좋은 예시이다.

더 보기

주석

<references>

  1. 안드로이드는 달빅 바이트코드로 돌아가기 때문에, 엄밀히 말하면 인터프리터에서 돌아가는 운영체제이다. 그래서 안드로이드가 선천적으로 속도가 느리다...는 5.0부터 ART에서 AOT 컴파일링이 도입되면서 나아지고 있다.