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

잔글 (문자열 찾아 바꾸기 - "(갈|갤|걀|걜|걸|겔|결|곌|골|괄|괠|괼|굘|굴|궐|궬|귈|귤|글|긜|길|깔|깰|꺌|꺨|껄|껠|껼|꼘|꼴|꽐|꽬|꾈|꾤|꿀|꿜|꿸|뀔|뀰|끌|끨|낄|날|낼|냘|냴|널|넬|녈|녤|놀|놜|놸|뇔|뇰|눌|)
잔글 (문자열 찾아 바꾸기 - "는거" 문자열을 "는 거" 문자열로)
1번째 줄: 1번째 줄:
[[프로그래밍 언어]]로 된 코드를 입력받아, 자기가 그 코드에 적힌 프로그램의 내용을 수행하는 [[컴퓨터 프로그램]]. 마치 해당 프로그래밍 언어가 기계어인 또 다른 컴퓨터처럼 동작한다는 점에서 [[가상 머신]]과 궤를 같이 한다고 볼 수도 있다. 컴파일러와는 달리 코드를 한줄씩 즉석에서 번역하는데, 이로인해 수정이 간단한 등 많은 장점이 있다. 특히 코드 중에 한글자 삑사리나면 망하는 컴파일러와는 달리, 인터프리터는 일단 삑사리가 날 때까지는 정상적으로 실행해준다. 하지만 이로인해 속도가 더럽게 느리다는 단점이 있어서, 복잡한 프로그램을 만들 때는 선호되지 않는다. {{ㅊ| 스크립트 언어로 OS 짜는거 본 사람?}}<ref>안드로이드는 달빅 바이트코드로 돌아가기 때문에, 엄밀히 말하면 인터프리터에서 돌아가는 운영체제이다. 그래서 안드로이드가 선천적으로 속도가 느리다...는 5.0부터 ART에서 AOT 컴파일링이 도입되면서 나아지고 있다.</ref> 비유하자면 컴파일러가 번역가, 인터프리터가 동시통역사라고 할 수 있다.
[[프로그래밍 언어]]로 된 코드를 입력받아, 자기가 그 코드에 적힌 프로그램의 내용을 수행하는 [[컴퓨터 프로그램]]. 마치 해당 프로그래밍 언어가 기계어인 또 다른 컴퓨터처럼 동작한다는 점에서 [[가상 머신]]과 궤를 같이 한다고 볼 수도 있다. 컴파일러와는 달리 코드를 한줄씩 즉석에서 번역하는데, 이로인해 수정이 간단한 등 많은 장점이 있다. 특히 코드 중에 한글자 삑사리나면 망하는 컴파일러와는 달리, 인터프리터는 일단 삑사리가 날 때까지는 정상적으로 실행해준다. 하지만 이로인해 속도가 더럽게 느리다는 단점이 있어서, 복잡한 프로그램을 만들 때는 선호되지 않는다. {{ㅊ| 스크립트 언어로 OS 짜는 거 본 사람?}}<ref>안드로이드는 달빅 바이트코드로 돌아가기 때문에, 엄밀히 말하면 인터프리터에서 돌아가는 운영체제이다. 그래서 안드로이드가 선천적으로 속도가 느리다...는 5.0부터 ART에서 AOT 컴파일링이 도입되면서 나아지고 있다.</ref> 비유하자면 컴파일러가 번역가, 인터프리터가 동시통역사라고 할 수 있다.


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

2015년 5월 2일 (토) 11:17 판

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

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

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

더 보기

주석

<references>

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