그런 최적화 기능이 컴파일러에 구현될 의무가 있는 지는 모르겠지만,
설령 구현된다치더라도 architecture 에 따라 불가능할 경우가 많을 것 같고요.
어디에 있느냐에 따라 access latency 가 생길 수는 있습니다.
최적화 얘기가 나와서 말인데,
[bushi@rose local]$ cat l1.c
int test(int a)
{
int b = 2, c = 3, d = 4;
return (a + b) * c + d;
}
int main()
{
return test(1);
}
[bushi@rose local]$
[bushi@rose local]$ cat l2.c
int test(int a)
{
int b = 2, c = 3, d = 4;
int e, f, g;
e = (a + b);
f = e * c;
g = f + d;
return g;
}
int main()
{
return test(1);
}
[bushi@rose local]$
스택 프레임을 새로 잡는 것은 스택의 크기와 무관하게 그냥 stack pointer를 프레임 크기만큼 빼주는 (혹은 bottom-up 방식의 stack이라면 더해주는) 걸로 끝입니다. 즉 스택의 크기와 무관하게 기계어 명령어 두세 개로 끝납니다.
그렇다면 그렇다고 스택 크기와 성능은 완전히 무관하냐? 하면 그런 것은 아니고...
1. 스택이 크면 클수록 메모리 상에서 자주 사용되는 지역변수의 위치가 서로 멀리 떨어지게 됩니다. (즉 f가 g를 부르고 g가 h를 부르면 f의 지역변수와 h의 지역변수 사이 거리가 늘어나겠죠.) 따라서 data cache locality가 나빠집니다. 즉 예전에는 자주 사용되는 지역변수를 담기 위해 cache line이 다섯 개로 충분했다면 이제 50개로 늘어날 수가 있습니다.
2. 스택이 진짜 크다면 (일반적인 PC 기준으로 수백 K 정도?) 시스템의 메모리 요구량이 늘어납니다. 그러면 당연히 메모리를 제공하기 위해 가상메모리 일부를 디스크로 swap-out해야 하고... 어쩌구 저쩌구... 성능이 느려지겠죠. 즉 쉽게 말해 "컴퓨터가 버벅거린다"라는 현상이 일어납니다. 물론 요즘 PC에서 프로세스 하나로 눈에 확 보이는 차이를 내려면 스택을 수백 M는 잡아야 하겠지만, 시간을 재서 비교한다면 훨씬 작은 스택 크기에서도 유의미한 성능 차이가 나올 수 있겠죠.
이상은 스택에 잡는 자동변수를 초기화하지 않을 때 얘기고, 물론 얘들을 잡을 때마다 초기화한다면 초기화 비용은 초기화하는 변수의 사이즈에 비례해서 늘어납니다. (덩치 큰 자동배열을 잡고 0으로 초기화한다든지 하는 건 성능 면에서 완전 삽질. 그 함수가 자주 불린다면 다른 방법을 강구해 보세요.)
* 그리고 저 위에 bushi님이 "runtime에 allocation이 되지 않는다"라고 하신 말은 무슨 뜻인지 잘 이해가 안가네요... -.-
run-time 에 allocation
run-time 에 allocation 되지 않으므로 allocation latency 는 존재하지 않습니다.
OTL
어디선가 주어들은 이야기입니다...
컴파일러에 옵티마이징옵션주면...
지역변수 몇개까지는 스택에 저장하지 않고
레지스터를 이용한다고 합니다.
그래서 지역변수 갯수를 줄이라는 말을 들은적 있습니다.
없음
그런 최적화 기능이
그런 최적화 기능이 컴파일러에 구현될 의무가 있는 지는 모르겠지만,
설령 구현된다치더라도 architecture 에 따라 불가능할 경우가 많을 것 같고요.
어디에 있느냐에 따라 access latency 가 생길 수는 있습니다.
최적화 얘기가 나와서 말인데,
[bushi@rose local]$ cat l1.c int test(int a) { int b = 2, c = 3, d = 4; return (a + b) * c + d; } int main() { return test(1); } [bushi@rose local]$ [bushi@rose local]$ cat l2.c int test(int a) { int b = 2, c = 3, d = 4; int e, f, g; e = (a + b); f = e * c; g = f + d; return g; } int main() { return test(1); } [bushi@rose local]$[bushi@rose local]$ gcc -O2 -S l1.c [bushi@rose local]$ gcc -O2 -S l2.c [bushi@rose local]$ diff -u l1.s l2.s --- l1.s 2008-10-09 03:34:36.000000000 +0900 +++ l2.s 2008-10-09 03:34:38.000000000 +0900 @@ -1,4 +1,4 @@ - .file "l1.c" + .file "l2.c" .text .p2align 4,,15 .globl test [bushi@rose local]$의미 있는 중간 결과를 담을 그릇은 명시적으로 코딩해 주는 편이 더 인간적이라고 배웠습니다.
마지막으로,
gcc 의 경우는 매우 자주 반복적으로 접근할 것으로 예상되는 놈을 위해
특별히 register 라는 지시자(?)를 준비해두고 있습니다.
코더가 컴파일러에게 요청하는 겁니다.
"어지간하면 이놈 좀 신경 써 줬으면 좋겠는데"
[bushi@rose local]$ cat i1.c int main() { int i; for (i=0;i<1000000;i++) i++; return i; } [bushi@rose local]$ [bushi@rose local]$ cat i2.c int main() { register int i; for (i=0;i<1000000;i++) i++; return i; } [bushi@rose local]$최적화 옵션이 없더라도, 최선을 다해 신경 써 줍니다.
x86 은 보기 힘드니 arm 으로 해보죠.
[bushi@rose local]$ /opt/host/arm-2007q1/bin/arm-none-linux-gnueabi-gcc -S i1.c -o i1.s [bushi@rose local]$ /opt/host/arm-2007q1/bin/arm-none-linux-gnueabi-gcc -S i2.c -o i2.s [bushi@rose local]$ [bushi@rose local]$ /opt/host/arm-2007q1/bin/arm-none-linux-gnueabi-gcc -O2 -S i1.c -o i1_O.s [bushi@rose local]$ /opt/host/arm-2007q1/bin/arm-none-linux-gnueabi-gcc -O2 -S i2.c -o i2_O.s [bushi@rose local]$ [bushi@rose local]$ diff -u i1.s i2.s --- i1.s 2008-10-09 04:02:36.000000000 +0900 +++ i2.s 2008-10-09 04:02:38.000000000 +0900 @@ -8,7 +8,7 @@ .eabi_attribute 26, 2 .eabi_attribute 30, 6 .eabi_attribute 18, 4 - .file "i1.c" + .file "i2.c" .text .align 2 .global main @@ -21,19 +21,19 @@ add fp, sp, #0 sub sp, sp, #12 @ lr needed for prologue - mov r3, #0 - str r3, [fp, #-8] + mov r2, #0 + str r2, [fp, #-8] b .L2 .L3: ldr r3, [fp, #-8] add r3, r3, #1 str r3, [fp, #-8] - ldr r3, [fp, #-8] - add r3, r3, #1 - str r3, [fp, #-8] -.L2: ldr r2, [fp, #-8] + add r2, r2, #1 + str r2, [fp, #-8] +.L2: ldr r3, .L6 + ldr r2, [fp, #-8] cmp r2, r3 ble .L3 ldr r3, [fp, #-8] [bushi@rose local]$ [bushi@rose local]$ diff -u i1_O.s i2_O.s --- i1_O.s 2008-10-09 04:03:10.000000000 +0900 +++ i2_O.s 2008-10-09 04:03:16.000000000 +0900 @@ -8,7 +8,7 @@ .eabi_attribute 26, 2 .eabi_attribute 30, 2 .eabi_attribute 18, 4 - .file "i1.c" + .file "i2.c" .text .align 2 .global main [bushi@rose local]$OTL
오~ 새로운 정보네요^.^
당장 가서 다른 소스로 해봐야겠네요...
없음
내공이 대단 하십니다.
저두한번 테스트 해봐야 겠습니다.
...
스택 프레임을 새로 잡는 것은 스택의 크기와 무관하게 그냥 stack pointer를 프레임 크기만큼 빼주는 (혹은 bottom-up 방식의 stack이라면 더해주는) 걸로 끝입니다. 즉 스택의 크기와 무관하게 기계어 명령어 두세 개로 끝납니다.
그렇다면 그렇다고 스택 크기와 성능은 완전히 무관하냐? 하면 그런 것은 아니고...
1. 스택이 크면 클수록 메모리 상에서 자주 사용되는 지역변수의 위치가 서로 멀리 떨어지게 됩니다. (즉 f가 g를 부르고 g가 h를 부르면 f의 지역변수와 h의 지역변수 사이 거리가 늘어나겠죠.) 따라서 data cache locality가 나빠집니다. 즉 예전에는 자주 사용되는 지역변수를 담기 위해 cache line이 다섯 개로 충분했다면 이제 50개로 늘어날 수가 있습니다.
2. 스택이 진짜 크다면 (일반적인 PC 기준으로 수백 K 정도?) 시스템의 메모리 요구량이 늘어납니다. 그러면 당연히 메모리를 제공하기 위해 가상메모리 일부를 디스크로 swap-out해야 하고... 어쩌구 저쩌구... 성능이 느려지겠죠. 즉 쉽게 말해 "컴퓨터가 버벅거린다"라는 현상이 일어납니다. 물론 요즘 PC에서 프로세스 하나로 눈에 확 보이는 차이를 내려면 스택을 수백 M는 잡아야 하겠지만, 시간을 재서 비교한다면 훨씬 작은 스택 크기에서도 유의미한 성능 차이가 나올 수 있겠죠.
이상은 스택에 잡는 자동변수를 초기화하지 않을 때 얘기고, 물론 얘들을 잡을 때마다 초기화한다면 초기화 비용은 초기화하는 변수의 사이즈에 비례해서 늘어납니다. (덩치 큰 자동배열을 잡고 0으로 초기화한다든지 하는 건 성능 면에서 완전 삽질. 그 함수가 자주 불린다면 다른 방법을 강구해 보세요.)
* 그리고 저 위에 bushi님이 "runtime에 allocation이 되지 않는다"라고 하신 말은 무슨 뜻인지 잘 이해가 안가네요... -.-
원 질문자가 예로
원 질문자가 예로 든,
두번째 코드의 b 때문에 실행 때 할당 건수가 늘어나서 시간지연이 생기지 않느냐에 대한 답입니다.
제 댓글이 아니라 질문을 이해 못하신 것 같은데요.
OTL
댓글 달기