[1회차] 가상메모리와 JAVA와 C의 속도 차이

가상 메모리란? (Virtual Memory)

 

모든 프로세스는 자신만의 가상 주소 공간을 가지고 있으며, 32비트/64비트 프로세스는 각 비트 수에 맞게 최대 4GB/16GB의 주소 공간을 가진다. 

모든 프로세스들은 자신만의 주소 공간을 가지기 때문에, 특정 프로세스 내에서 쓰레드가 수행될 때 해상 쓰레드는 프로세스가 소유하고 있는 메모리에 대해서만 접근이 가능하다. 다른 프로세스에 의해 소유된 메모리는 숨겨져 있으며, 접근이 불가능하다. 따라서, 어떠한 주소에 무엇을 저장하면, 다른 프로세스 역시 그 주소에 다른 것을 저장할 수 있으며 이 주소들은 독립되어 있는 것이다.

 

즉, 가상 메모리는 한마디로 프로세스의 logical memory와 physical memory를 분리하기 위해 생겨난 것이다.

따라서 logical memory가 physical memory보다 커지는 것을 가능하게 할 수 있다.

 

-> 가상메모리란 한정된 물리 메모리 한계를 극복하고자, 디스크와 같은 느린 저장장치를 활용해 애플리케이션들이 더 많은 메모리를 활용할 수 있게 해주는 것이 가상 메모리이다.

 

Java는 왜 C보다 느릴까?

 

더 통제되는 프로그래밍 언어는 컴파일러가 최적화할 가능성을 더 열어준다. 그래서 모든 코드를 손으로 최적화 할 것이 아니라면, 전체적으로 컴파일러는 더 좋은 성능을 보여줄 것이다.  그러나 이런 결과를 가져다 주기 위해서 애초에 프로그래밍 언어는 컴파일러에게 최적화의 가능성을 열어줄 수 있게 만들어 졌어야 했다. 자바는 이런 방법으로 만들어지지 않았다. 그래서 컴파일러가 얼마나 똑똑해지건 간에 java는 C의 속도를 절대 따라잡지 못한다.

 

그러나 자바가 C보다 빠른 경우는 전형적인 벤치마크를 할 때이다. 피보나치 넘버를 계산하거나, 벤치마크를 돌려야 한다면 자바가 C보다 느릴 이유가 없다. 모든 계산이 한 클래스 안에서 이뤄지고 기본형(int, double) 데이터만 다룬다면 자바는 C를 따라잡을 수 있다.

 

프로그램에 오브젝트를 사용하는 순간부터 자바는 최적화 할 가능성을 잃어버린다. 이유들은 다음과 같다.

 

1. 모든 오브젝트는 힙에 할당된다.

자바는 int, double같은 기본 자료형만 stack에 할당하고, 모든 오브젝트는 힙에 할당된다.

Identity semantic을 가지는 큰 오브젝트들의 경우에는 문제가 안된다. 그러나 성능을 저하시키는 주요 이유는 단순 값만 들고 있는 Value semantics의 작은 오브젝트들의 경우이다. (예를 들어 이터레이터의 경우)

 

2. 메모리 사용량의 증가

 

3. 디테일을 다루는 컨트롤의 부재

 

결론적으로, 자바가 고성능 소프트웨어에 적합하지 않다는 것을 의미하지만, 배우기 쉽고 관대하고 이용하기 쉬운 방대한 라이브러리가 있어서 작거나 중간 정도의 크의 프로그램을 만드는 데 적당하다.