동적할당 해제( heap 을 사용 )는 비용이 엄청나지만,
한 번만 시행된다면 그 뒤는 cache 나름이지.
아래 말했던 지도에서 데이타 영역을 다시 보면
[ static ][ heap ][ dynamic ]
순서로 만들어진다. 여기서 windows 시스템은 컴파일러 설정을 바꾸지 않는한 dynamic 영역을 1MB 로 잡는다.
즉 1MB 를 초과하는 배열 선언 같은게 안된다. int[ 1메가 / sizeof( int ) ] 정도 크기가 한계란거지.
반면 linux 환경에서는 stack 영역을 기본적으로 꽤 크게 잡아준다.
어찌되었든 가장 광활한 영역은 대개의 경우 heap 이다. ( 중요 )
그리고 캐시효율이나 디버깅의 편의를 위해서 stack 위치를 앞으로 옮기는 경우도 있다.
만약 니가 static 배열이나 전역변수를 선언한다면,
그것은 static 영역에 쌓이게 된다.
그리고 함수 안의 지역변수들은 dynamic 영역을 사용하게 되지.
그 말은 니가 지역변수만 사용한다면 캐시가 지역변수의 stack 쪽에 머무를 가능성이 있지만,
외부 함수를 call 하는 과정에서 그 외부함수가 내부적으로 사용하고 있는 정적 메모리에 접근한다든지,
전역 변수에 접근하면 기본적으로 2 페이지가 캐싱되어야 한다.
거기다 동적 할당까지 쓰게 되면 heap까지 세페이지가 캐싱되어야 하겠지.
거기다 크기가 64KB 보다 커지면 페이지수가 늘어나기 시작한다.
L1, L2, L3 로 가면서 크기는 커지지만 속도는 떨어지고,
L2 를 넘을때 극도로 취약해 진다.
L3 까지 캐시가 이루어지지 않으면 너의 데이타는 CPU 에 근접한 속도가 아닌 마더보드의 RAM 클럭에 근접한 속도로 떨어지게 된다.
뭐 그런거지.
즉 가능하면 처리에 사용될 데이타는 한 곳에 클러스터링 하는게 현명한 방법이고,
모든 함수는 고유의 stack 을 사용하니까,
지역변수가 합리적인 선택이다. ( 크기가 허용되지 않는다면 어쩔수 없쥐 )
하지만 stdio 든 iostream 이든 니가 라이브러리를 가져다 쓴다면, static 으로 잡아 놓은 공간이 없을 순 없기 땜에,
stack ( 지역변수 ) > static ( 전역변수 ) > heap ( 동적할당 ) 순으로 성능이 나뉜다고 보면 된다.
하지만 좀 큰 규모의 프로그램을 만들다 보면 객체를 스택에 생성하는게 벅차게 되고,
( 스택 사용량을 확보해 줘야 함수의 콜 단계를 깊게 할 수 있으니 )
차라리 모든 객체를 힙에 생성하게 강제하는 시스템들이 나오는거지
( VCL, .Net - Delphi, C++Builder, C# 등등 )
오홍 그렇구나 - dc App
전역 지역 동적일줄 알았는데 아니었구나.
램이야 다 램이지... 반복적 행위에 의해서 캐시접근에 의한 성능차이가 생기는것.
오우 윈도우에서 최대 배열 선언 크기 있는 건 몰랐네요
stack 1MB 가 기본설정이라 자연스럽게 한계가 되는것. 스택을 키울수도 줄일수도 있지. 그래서 쓰레드를 아주 많이 만들어야 하는 경우는 줄인다.
선언할때의 시간만 보면 안되고 실제 사용할때의 시간도 봐야되는거네요. 자바때 배워서 모든 객체가 힙에 생성되는게 기본인줄 알았는데 그것도 아니고...
와 이분 글 쓴거마다 내공이 장난이 아닌게 느껴지네요. 많이 배우고갑니다