stack을 heap대신 stack에 올려서 얻은 성능 이득

제목을 말장난처럼 지어봤다.
다시 풀어서 쓰면
‘stack(자료구조)를 heap대신 stack(stack memory per thread)에 올려서 얻은 성능 이득’
이다.

64비트로 넘어오기 전에 32비트로만 개발하던 시절엔 stack자료구조가 필요한 경우 클래스나 함수형태의 stack 자료구조를 만들지 않았다. 그냥 함수 안에서 인라인 어셈블리로 push,pop명령어를 써넣었다. 그걸로 가변인자 함수도 만들고 그랬다.

64비트로 넘어오면서 인라인 어셈블리를 사용할 수 없게 됐다.
할수 없이 이후로는 stack자료구조를 클래스로 만들어서 사용했다. 나름 군더더기 없게 간결하게 짠다고 짰다.
단 이쪽은 메모리를 heap으로부터 할당해서 사용한다. 따라서 함수의 로컬영역(스레드별 스택) 메모리를 억세스하다가 stack클래스의 메모리를 억세스하게 되면 캐시미스할 가능성이 있어서 좀 찜찜하긴 했다.
그래도 성능 차이 얼마 안나겠지 싶어서 신경 끄고 있었다.
예의 그 8x8x8 복셀오브젝트의 터널찾기 코드 때문에 최적화를 하다보니 이 부분이 신경 쓰여서 결국 stack자료구조 코드를 수정했다.
함수의 로컬 영역(스레드별 스택)에 배열형태로 메모리를 잡고 그걸 stack자료구조에 맵핑하는 방식으로 바꿨다. CUDA에선 어쩔수 없이 이렇게 짜야하는데 그 방식을 CPU코드에도 적용한 것이다.
테스트해보니 릴리즈 빌드 기준 27% 성능 차이가 났다. 27%는 작은거 아닌데. 생각보다 크게 차이 나네.


답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중