JIT 컴파일: 두 판 사이의 차이
편집 요약 없음 |
|||
| (같은 사용자의 중간 판 2개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
Just-in-time compile. | Just-in-time compile. | ||
우리 말로 풀어보면 '적시 컴파일', 즉 적절한 시점에 [[컴파일]] 하는 것을 뜻한다. 보통 [[컴파일]]이라고 하면 프로그램을 만들고 나서 개발자가 [[컴파일러]]를 돌려서 [[기계어]]로 된 실행 파일을 만들거나 중간 파일, 또는 다른 프로그래밍 언어 코드로 변환한다. 하지만 JIT [[컴파일]]은 개발자가 [[컴파일]]을 하는 게 아니라, 사용자가 프로그램을 실행하는 시점에서 [[컴파일]]이 이루어진다. 예를 들어, [[자바]] 프로그램은 컴파일을 하면 바이트코드라는, 하드웨어와 운영체제에 중립인 중간 코드 파일이 만들어진다. 사용자가 이 바이트코드 파일을 | 우리 말로 풀어보면 '적시 컴파일', 즉 적절한 시점에 [[컴파일]] 하는 것을 뜻한다. 보통 [[컴파일]]이라고 하면 프로그램을 만들고 나서 개발자가 [[컴파일러]]를 돌려서 [[기계어]]로 된 실행 파일을 만들거나 중간 파일, 또는 다른 프로그래밍 언어 코드로 변환한다. 하지만 JIT [[컴파일]]은 개발자가 [[컴파일]]을 하는 게 아니라, 사용자가 프로그램을 실행하는 시점에서 [[컴파일]]이 이루어진다. 예를 들어, [[자바]] 프로그램은 컴파일을 하면 바이트코드라는, 하드웨어와 운영체제에 중립인 중간 코드 파일이 만들어진다. 사용자가 이 바이트코드 파일을 실행시킬 때마다 [[기계어]]로 번역되는데, 소스 코드에서부터 [[인터프리트]]하는 방식보다는 빠르지만 그래도 아예 [[기계어]] 실행 파일을 만들어서 실행시키는 것보다는 속도가 느리다는 단점이 있었다. 결국 JIT 컴파일 방식이 도입되어 사용자가 처음 실행할 때 바이트코드를 컴파일해서 [[기계어]] 실행파일로 변환해 놓고 이걸 대신 실행하는 방식으로 바꾸면서 속도를 대폭 향상시키는 효과를 얻었다. 보통 JIT 컴파일은 최초 실행할 때 한번 [[컴파일]]해서 [[기계어]] 파일을 만들어 놓고 그 이후에는 원본의 내용이 바뀌지 않았다면 이전에 [[컴파일]]해 두었던 [[기계어]] 파일을 실행시키는 방식으로 사용된다. | ||
장점이라면 역시 속도. 그때문에 JIT 컴파일이 생겨난 것이기도 하다. 실행할 때마다 기계어 변환 과정이 필요한 인터프리트 방식, 혹은 중간코드 방식에 비해서 속도가 빠를 수밖에 없다. 단점은 프로그램을 처음으로 실행할 때에는 [[컴파일]] 과정 때문에 초기에 실행이 시작되는 속도가 많이 느리며, 소스 코드 혹은 바이트코드 파일과 실행파일 코드가 같이 있기 때문에 용량을 많이 잡아먹게 된다. 소스 코드나 바이트코드가 바뀌었을 경우에 컴파일을 다시 해야 하므로 그 변화 여부를 체크하고 있어야 한다. | |||
[[안드로이드]]도 초기에는 달빅 캐시가 [[자바]] 가상 머신 구실을 하면서 중간 코드 형태로 된 앱 파일을 [[인터프리트]] 방식으로 실행했으나 이후에는 JIT 컴파일 방식을 도입한 ART(Android Runtime) 로 바뀌었다. 사실 ART는 정확하는 JIT 컴파일이 아니라 AOT(Ahead-of-time) [[컴파일]]이다. 즉, 실행 시점에서 [[컴파일]]되는 게 아니라 앱 파일을 설치하는 과정에서 [[컴파일]]이 이루어진다. | |||
소스 코드에서 [[인터프리트]] 하는 방식의 언어도 역시 JIT 컴파일 방식을 사용할 수 있다. 그 대표 예가 [[자바스크립트]]. 원래는 HTML 안에 삽입된, 혹은 별도 파일로 링크된 스크립트를 실행시킬 때마다 [[인터프리트]] 방식으로 돌렸지만 [[파이어폭스]]가 JIT [[컴파일]] 방식을 도입했고 [[구글 크롬]]이 이를 뒤따르면서 어마어마한 속도 향상을 가져옴으로써 AJAX열풍과 함께 [[자바스크립트]] 활용 폭을 엄청나게 넓혔다. 여러 스크립트 언어들이 속도 향상을 위해서 이런 전략을 채용하고 있다. | |||
2019년 6월 17일 (월) 20:03 기준 최신판
Just-in-time compile.
우리 말로 풀어보면 '적시 컴파일', 즉 적절한 시점에 컴파일 하는 것을 뜻한다. 보통 컴파일이라고 하면 프로그램을 만들고 나서 개발자가 컴파일러를 돌려서 기계어로 된 실행 파일을 만들거나 중간 파일, 또는 다른 프로그래밍 언어 코드로 변환한다. 하지만 JIT 컴파일은 개발자가 컴파일을 하는 게 아니라, 사용자가 프로그램을 실행하는 시점에서 컴파일이 이루어진다. 예를 들어, 자바 프로그램은 컴파일을 하면 바이트코드라는, 하드웨어와 운영체제에 중립인 중간 코드 파일이 만들어진다. 사용자가 이 바이트코드 파일을 실행시킬 때마다 기계어로 번역되는데, 소스 코드에서부터 인터프리트하는 방식보다는 빠르지만 그래도 아예 기계어 실행 파일을 만들어서 실행시키는 것보다는 속도가 느리다는 단점이 있었다. 결국 JIT 컴파일 방식이 도입되어 사용자가 처음 실행할 때 바이트코드를 컴파일해서 기계어 실행파일로 변환해 놓고 이걸 대신 실행하는 방식으로 바꾸면서 속도를 대폭 향상시키는 효과를 얻었다. 보통 JIT 컴파일은 최초 실행할 때 한번 컴파일해서 기계어 파일을 만들어 놓고 그 이후에는 원본의 내용이 바뀌지 않았다면 이전에 컴파일해 두었던 기계어 파일을 실행시키는 방식으로 사용된다.
장점이라면 역시 속도. 그때문에 JIT 컴파일이 생겨난 것이기도 하다. 실행할 때마다 기계어 변환 과정이 필요한 인터프리트 방식, 혹은 중간코드 방식에 비해서 속도가 빠를 수밖에 없다. 단점은 프로그램을 처음으로 실행할 때에는 컴파일 과정 때문에 초기에 실행이 시작되는 속도가 많이 느리며, 소스 코드 혹은 바이트코드 파일과 실행파일 코드가 같이 있기 때문에 용량을 많이 잡아먹게 된다. 소스 코드나 바이트코드가 바뀌었을 경우에 컴파일을 다시 해야 하므로 그 변화 여부를 체크하고 있어야 한다.
안드로이드도 초기에는 달빅 캐시가 자바 가상 머신 구실을 하면서 중간 코드 형태로 된 앱 파일을 인터프리트 방식으로 실행했으나 이후에는 JIT 컴파일 방식을 도입한 ART(Android Runtime) 로 바뀌었다. 사실 ART는 정확하는 JIT 컴파일이 아니라 AOT(Ahead-of-time) 컴파일이다. 즉, 실행 시점에서 컴파일되는 게 아니라 앱 파일을 설치하는 과정에서 컴파일이 이루어진다.
소스 코드에서 인터프리트 하는 방식의 언어도 역시 JIT 컴파일 방식을 사용할 수 있다. 그 대표 예가 자바스크립트. 원래는 HTML 안에 삽입된, 혹은 별도 파일로 링크된 스크립트를 실행시킬 때마다 인터프리트 방식으로 돌렸지만 파이어폭스가 JIT 컴파일 방식을 도입했고 구글 크롬이 이를 뒤따르면서 어마어마한 속도 향상을 가져옴으로써 AJAX열풍과 함께 자바스크립트 활용 폭을 엄청나게 넓혔다. 여러 스크립트 언어들이 속도 향상을 위해서 이런 전략을 채용하고 있다.
