라이브러리의 inline 함수 사용

프로그래밍 일반에 관한 포럼입니다.

Moderator: 류광

Locked
tomatowax
Posts: 464
Joined: 2005-01-17 12:22
Contact:

라이브러리의 inline 함수 사용

Post by tomatowax »

안녕하세요 TomatoWAX 입니다.

갑자기 항상 사용하던 inline 에 의문이 들어서 질문하게 되었습니다.

static library 혹은 dynamic library 에서 inline 함수는 어떻게 처리되는지 궁금합니다.

1. Static(혹은 Dynamic) Library 에서 .inl 에 정의된 함수들은 항상 inline 이 보장되나요?
1-1. 여기서 inline 의 보장이란 처음 Library 가 제작될 때 inline 으로 안되고 Library 에 포함되는지 여부와
1-2. Library 에 포함되지는 않았지만 실제로 어플리케이션에서 컴파일 시 inline 이 안되는 이슈 둘 다 궁금합니다.

2. Static(혹은 Dynamic) Library 에서 .cpp 에 정의된 함수들 중 간단한 함수가 자동으로 inline 이 될 수 있을까요? 보통 일반 어플리케이션 제작시에는 컴파일러 옵션에 따라 그렇게 된다고 들었습니다만 이것이 일반 라이브러리 (헤더와 .lib) 구성에서도 가능한 이야기인지 궁금합니다.

3. Static(혹은 Dynamic) Library 에서 .inl 의 사용에 대해 어떻게 생각하시나요?

구글에 쳐보니 애매한 답들이 검색되어 질문하게 되었습니다.
관련 링크를 던져주셔도 좋습니다. :)

ps. 사실 크로스 플랫폼 제작하면서 Java 나 다른 언어의 경우 .inl 을 사용하지 않기에 소스의 균일화를 위해 .inl 을 사용하지 않는 것이 좋겠다는 생각도 듭니다만, 각 고유의 언어에 따라 특성이 있는데 그 특성을 잘 이용하는 것이 좋겠다 싶어서 inline 에 대해 더 잘 알아두려고 합니다.
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Re: 라이브러리의 inline 함수 사용

Post by mastercho »

TomatoWAX wrote:안녕하세요 TomatoWAX 입니다.

갑자기 항상 사용하던 inline 에 의문이 들어서 질문하게 되었습니다.

static library 혹은 dynamic library 에서 inline 함수는 어떻게 처리되는지 궁금합니다.

1. Static(혹은 Dynamic) Library 에서 .inl 에 정의된 함수들은 항상 inline 이 보장되나요?
1-1. 여기서 inline 의 보장이란 처음 Library 가 제작될 때 inline 으로 안되고 Library 에 포함되는지 여부와
1-2. Library 에 포함되지는 않았지만 실제로 어플리케이션에서 컴파일 시 inline 이 안되는 이슈 둘 다 궁금합니다.

2. Static(혹은 Dynamic) Library 에서 .cpp 에 정의된 함수들 중 간단한 함수가 자동으로 inline 이 될 수 있을까요? 보통 일반 어플리케이션 제작시에는 컴파일러 옵션에 따라 그렇게 된다고 들었습니다만 이것이 일반 라이브러리 (헤더와 .lib) 구성에서도 가능한 이야기인지 궁금합니다.

3. Static(혹은 Dynamic) Library 에서 .inl 의 사용에 대해 어떻게 생각하시나요?

구글에 쳐보니 애매한 답들이 검색되어 질문하게 되었습니다.
관련 링크를 던져주셔도 좋습니다. :)

ps. 사실 크로스 플랫폼 제작하면서 Java 나 다른 언어의 경우 .inl 을 사용하지 않기에 소스의 균일화를 위해 .inl 을 사용하지 않는 것이 좋겠다는 생각도 듭니다만, 각 고유의 언어에 따라 특성이 있는데 그 특성을 잘 이용하는 것이 좋겠다 싶어서 inline 에 대해 더 잘 알아두려고 합니다.
1.번
라이브러리에 인라인 함수로 되어 있는것은 말 그대로 인라인 처리되는 함수일겁니다
(만약 라이브러리 불가라면 인라인 함수를 포함하는 cpp쪽에 구현이 생기겠죠 ,
lib,dll 라이브러리와는 별개로 , 템플릿 라이브러리 같은 , 헤더용? 라이브러리가 되지않을까 싶습니다)

보장이 안된다면 라이브러리를 사용하는 방식에 문제가 있을거 같네요
[예를 들어 뻔히 인라인 구현을 나두고 라이브러리에 똑같은 함수가 있는지 찾는것도 이상하고
있다에도 구현이 두개기때문에 링크에러든 다른 에러든 내겠죠]

다만 인라인 할수 없는 함수들은 라이브러리를 만들때 에러를 내주지 않을까 싶습니다

인라인 함수내의 static 변수는 대표적인 인라인 불가 함수인데 확인해보지 않앗지만
이건 라이브러리를 만들때 컴파일러가 에러를 내주던거 워닝을 줄거 같네요 ...


2.번
인라인은 컴파일타임때 이루어지는데 , 라이브러리는 링크타임에 되므로 라이브러리 구현의 인라인은 불가능할거 같습니다



3. inl 은 헤더 함수에 정의 된것과 똑같다고 생각됩니다 (헤더 파일에 같이 include 되죠)굳이 그걸 나누는것은
정의 부분을 다른곳에 두므로써 cpp 사용하는 것 처럼 선언과 정의를 따로 관리 하고 싶을때 이용하는것뿐입니다

컴파일러가 따로 inl 이라는 확장자 개념을 인지하는건 아니기때문에 헤더에 직접 구현된것과
다를게 없다고 생각됩니다
tomatowax
Posts: 464
Joined: 2005-01-17 12:22
Contact:

Post by tomatowax »

mastercho 님 답변 감사드립니다. :)

일단 3번 질문을 드린 이유는 인라인 함수를 라이브러리 제작시 사용하는 것이 얼마나 효율성을 가져온다고 생각하시는지 라이브러리 개발자/사용자 입장에서의 의견이 듣고 싶어서였습니다~ 개인적으로는 개발자/사용자 상관없이 인라인 함수는 프로그램의 전체 효율을 높여줄 수 있다고 생각하고 사용해왔는데 혹시 이것이 라이브러리 개발에서는 달라질 수 있을 것인가에 대해 완전한 답을 생각해보지 않았기에 질문드리게 되었습니다. 말씀하신대로 inl 파일자체는 h 파일에 선언하는 것과 (보통은) 동일한 효과를 냅니다. 3번 질문 같은 경우는 사실 1번과 2번의 답에 따라 많이 달라질 것으로 생각되는군요.

다음으로 2번. 질문에 구체적인 내용을 덧붙이자면, 보통 inline 함수들은 컴파일 타임에 이루어지는데요 (말씀하신 것처럼요~) 그런데 이게 라이브러리 단에서 cpp 에 정의되었으면 '아무리 간단한 함수라도 무조건 비-인라인화' 되는 것인지에 대한 질문이었습니다. 당연히 inline 이 되었다면 혹은 되려면 h 파일이던 inl 파일이던 빠지는 것이 맞는데, 그렇지 않고 혹시 .lib 에 암묵적으로 포함되어 보다 빠르게 동작하는 것이 가능한지에 대한 질문이었습니다. 그런데 제가 생각해도 참 아이러니한 상황으로^^; 생각되고 당연히 답은 불가능이 맞을 것 같지만 혹시나~ 싶어서 질문드렸습니다. 역시, 라이브러리의 경우는 안되는 시나리오 일까요?

1번에서의 질문은 다음과 같습니다. 함수가 inl 으로 빠지게 되면 일반 어플리케이션의 경우 소스의 크기에 따라 inline 처리가 되고 안된다고 들었습니다. 그런데 라이브러리 제작시에 inl 으로 빼었을 경우 그 함수가 굉장히 긴 소스라면? 이 경우라도 여전히 inline 이 되고 라이브러리를 사용하는 어플리케이션의 '모든 해당 함수 호출부분이' inline 소스로 전환되는지의 질문이었습니다. 이 경우에 속도를 떠나서 강제 inline 화가 되버리면 프로그램의 덩치가 (소스의 크기가) 커질 수 밖에 없기 때문에 정확한 답이 궁금했습니다. 다른 접근으로는 강제 inline 의 경우 작은 inline 이라면 항상 빠른 함수 동작을 보장받을 수 있어서 궁금하구요. mastercho 님 답변으로는 강제 인라인이 된다는 쪽이 강한 것 같은데 제가 지금 덧붙이는 질문의 조건들을 확인해봐도 여전히 같은 답변이신가요?? 만약 그렇다면 라이브러리에서의 inline 은 더욱 신중하게 사용해야 할 것 같아서요. 일반 어플리케이션이라면 컴파일러가 자동으로 분류를 해주니 부담없겠지만 항상 강제 inline 을 보장 받는다면 다른 이야기가 될 것 같습니다.
비회원

inline은 헤더에 구현되기 때문에

Post by 비회원 »

inline은 헤더에 구현되기 때문에 library를 쓰고 말고를 떠나서 include한다면 자동으로 inline화 되지 않을까요?
tomatowax
Posts: 464
Joined: 2005-01-17 12:22
Contact:

Re: inline은 헤더에 구현되기 때문에

Post by tomatowax »

비회원 wrote:inline은 헤더에 구현되기 때문에 library를 쓰고 말고를 떠나서 include한다면 자동으로 inline화 되지 않을까요?
덩치가 큰 함수의 경우 inline 을 만들지 않습니다. 이것은 컴파일러 옵션에 따라 다르다고 하네요. 그런데 강제로 inline 을 만드는 키워드를 붙이지 않는 한 대부분 적당히 최적화를 해준다고 알고 있습니다. 컴파일러가 선택하게 그냥 두는겁니다. 그런데 라이브러리의 경우에는 이미 컴파일이 한 번 된 경우니까 이 경우에는 어떻게 되는지가 궁금한거죠~ (정리하자면 일반 어플리케이션 개발시 헤더에 정의했다고 모두 인라인이 되지는 않습니다.)
비회원

인라인은 템플릿과 같은 느낌일것 같습니다.

Post by 비회원 »

물론 제 생각이지만, 인라인은 템플릿과 같은 구조로 컴파일 되지 않을까 생각됩니다.

인라인 함수 자체가 라이브러리에 포함되지 않고, header에 정의되어 있죠.

템플릿 클래스가 사용되는 시점에 생성되는것과 마찬가지로 라이브러리든 사용하는 실행파일이든 인라인 함수도 사용되는 시점에 포함될것 같습니다.

물론 방금 말하신 인라인 될 수 없는 함수들은 라이브러리 어딘가에 컴파일되어 있겠죠.

결론은 인라인 될 수 있는 인라인 함수들은 라이브러리에 컴파일되어 포함되어 있지 않을거 같네요.
tomatowax
Posts: 464
Joined: 2005-01-17 12:22
Contact:

Re: 인라인은 템플릿과 같은 느낌일것 같습니다.

Post by tomatowax »

답변 감사합니다 비회원님.
비회원 wrote:...
물론 방금 말하신 인라인 될 수 없는 함수들은 라이브러리 어딘가에 컴파일되어 있겠죠.
...
가장 궁금한 것 중 하나가 이 부분인데요.

그렇다면 .inl 에 있어도 라이브러리 (.lib) 어딘가에 컴파일된다는 말씀이신가요? 이게 가능할 경우 mastercho 님이 말씀하신 것 처럼 .inl 에서 다시 정의되어 있음으로 인해 워닝 혹은 링크 에러를 띄워줘야 하는게 아닌가 싶습니다. 경우에 따라 .inl 내의 함수가 어플리케이션 단에서 컴파일러에 의해 재컴파일될 수 있으니까요. 그런데 문제는 아직까지 그러한 경우(에러를 내뿜는 경우)가 한 번도 일어나지 않았다는 점입니다.

그런데 답변을 받으면서 종합적으로 생각해보니... 그냥 심플하게 생각해서 라이브러리 컴파일과 무관하게 .inl 은 어플리케이션 단에서 일반 .inl 와 동일하게 처리가 된다는 점이 맞는 것인가 싶기도 합니다. 이것은 비회원님이 말씀하신 것처럼 inline 내용들이 템플릿처럼 어플리케이션 혹은 라이브러리에서 사용(혹은 호출)할 경우에만 컴파일에 포함된다는 것과 동일하겠구요.

그런데 inl 파일에 있어도 라이브러리 컴파일시에 에러 체크를 해주던데 이건 그럼 단순히 컴파일 오류 체크만 해준다고 봐야 할런지.. 으흠 :?
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Re: 인라인은 템플릿과 같은 느낌일것 같습니다.

Post by mastercho »

TomatoWAX wrote:답변 감사합니다 비회원님.
비회원 wrote:...
물론 방금 말하신 인라인 될 수 없는 함수들은 라이브러리 어딘가에 컴파일되어 있겠죠.
...
가장 궁금한 것 중 하나가 이 부분인데요.

그렇다면 .inl 에 있어도 라이브러리 (.lib) 어딘가에 컴파일된다는 말씀이신가요? 이게 가능할 경우 mastercho 님이 말씀하신 것 처럼 .inl 에서 다시 정의되어 있음으로 인해 워닝 혹은 링크 에러를 띄워줘야 하는게 아닌가 싶습니다. 경우에 따라 .inl 내의 함수가 어플리케이션 단에서 컴파일러에 의해 재컴파일될 수 있으니까요. 그런데 문제는 아직까지 그러한 경우(에러를 내뿜는 경우)가 한 번도 일어나지 않았다는 점입니다.

그런데 답변을 받으면서 종합적으로 생각해보니... 그냥 심플하게 생각해서 라이브러리 컴파일과 무관하게 .inl 은 어플리케이션 단에서 일반 .inl 와 동일하게 처리가 된다는 점이 맞는 것인가 싶기도 합니다. 이것은 비회원님이 말씀하신 것처럼 inline 내용들이 템플릿처럼 어플리케이션 혹은 라이브러리에서 사용(혹은 호출)할 경우에만 컴파일에 포함된다는 것과 동일하겠구요.

그런데 inl 파일에 있어도 라이브러리 컴파일시에 에러 체크를 해주던데 이건 그럼 단순히 컴파일 오류 체크만 해준다고 봐야 할런지.. 으흠 :?
lib 파일에 포함된다는 말씀이 아니라 그 라이브러리를 사용하는 프로젝트쪽 cpp 쪽에 컴파일되어 만들어진다는
말씀 같습니다

template 이 인라인 안될때 처럼말이죠

인라인 함수는 어째거나 lib쪽에는 포함되지 않을거이고
링크시 lib를 참조하진 않을것 같습니다

만약 lib를 참조하는 라이브러리 함수라면 , 인라인은 당연히 될수 없겠고요
비회원

Re: 인라인은 템플릿과 같은 느낌일것 같습니다.

Post by 비회원 »

제가 생각하는 부분입니다.

인라인으로 선언했지만 인라인이 될 수 없는 함수
- 라이브러리에서 인라인 불가능하다고 판단해서 자신의 바이너리에 포함시킵니다. 어플리케이션에서도 (최소한 같은 컴파일러)라면 이 함수를 인라인 함수가 아닌 일반 함수라 판단하고 라이브러리에서 찾을것이라 생각됩니다.

인라인으로 선언했고 인라인이 될 수 있는 함수
- 이 함수는 라이브러리든 어플리케이션이든 명확하게 함수가 정의되어 있지 않고 인라인 함수 원래 정의대로 다른 루틴에 포함되어 있으리라 생각됩니다.

컴파일 오류 체크 부분
- 템플릿 함수 및 클래스도 쓰이지 않는다 하더라도 아주 기본적인 문법적 부분은 검사합니다. 단지 템플릿 인자로 어떤 것이 올지 모르기 때문에 좀 느슨하게 검사하죠. 인라인도 같은 맥락이라고 생각합니다. 인라인은 안 쓰이더라도 일단 명확하게 정의되어 있으니까 검사하는거죠.


아 왠지, C++ 표준 명세를 보고 싶습니다.
비회원

Post by 비회원 »

inline으로 지정된 함수들은 인라인이 되지 않더라도 각각 컴파일시에 unnamed 함수로 처리될것 같네요.

inline big_function()
{
// 예를들면 10만라인-_-
}

big_func_lib.lib
- 컴파일될때 unanmed_blah_big_fuction을 만들어 lib 내부에서 참조할때 참조시킴

big_func_app.exe
- 컴파일될ㅤㄸㅒㅤ big_function()이 인라인이지만 인라인할수가 없어서 big_func_lib.lib하고 별도로
unamed_blah_big_function을 만들어 내부에서 참조함
- big_func_lib.lib을 링크시킬때 따라서 big_function이 2개가 생김 하지만 unamed로 처리해서 컴파일은 문제 없음.


왜 이렇게 생각하나면, 구현이 간단하니까요 :0

어셈블리코드 확인해보면 되는데 귀찮네요.
비회원

Re: 라이브러리의 inline 함수 사용

Post by 비회원 »

일단 인라인 여부는 컴파일러님께서 정하시는 것이니만큼 (키워드를 사용하는 것은 인라인화를 강제하는 것이 아니라 권고하는 것이라고 알고 있습니다...) '보장된다'라고 말하기는 어려울 것 같고, 다만 일반적인 경우 인라인화가 된다면 라이브러리로 만들어 써도 인라인화가 될 것이다... 정도가 아닐까 싶네요.

2번에 대해서는... Interprocedural optimization이 지원되는 VC++에서는 서로 다른 컴파일 단위에 위치한 함수에 대해서도 (인라인 키워드가 없었음에도) 필요한 경우 알아서 인라인화를 시키는 것을 확인했습니다. 다시 말해 링크 타임에서도 인라인화가 일어날 수도 있다는 의미이고... static library라도 크게 다를 이유는 없을 것 같으니 굳이 inline 키워드를 쓰지 않아도 인라인을 통해 성능이 좋아질 수 있는 경우라면 알아서 인라인화가 될 것 같습니다. 어쨌든 인라인 여부는 컴파일러가 결정하는 것이니까요...
비회원

Re: 라이브러리의 inline 함수 사용

Post by 비회원 »

비회원 wrote: 2번에 대해서는... Interprocedural optimization이 지원되는 VC++에서는 서로 다른 컴파일 단위에 위치한 함수에 대해서도 (인라인 키워드가 없었음에도) 필요한 경우 알아서 인라인화를 시키는 것을 확인했습니다. 다시 말해 링크 타임에서도 인라인화가 일어날 수도 있다는 의미이고... static library라도 크게 다를 이유는 없을 것 같으니 굳이 inline 키워드를 쓰지 않아도 인라인을 통해 성능이 좋아질 수 있는 경우라면 알아서 인라인화가 될 것 같습니다. 어쨌든 인라인 여부는 컴파일러가 결정하는 것이니까요...
엄연히 다를텐데요? 이미 다른 환경?에서 컴파일이 끝난 라이브러리를 링크 시키는 것과

같은 프로젝트내에서 컴파일해서 최적화 되어 인라인 되는 것은 다를거 같은데요?

분명 같은 프로젝트내에서 이루어지는 최적화 처리가 이미 라이브러리로 컴파일된것과 같은거라
생각하는건 오류같습니다

단순히 라이브러리의 최적화 옵션이 달라도 뭔가 틀어질거 같지 않나요?
비회원

Re: 라이브러리의 inline 함수 사용

Post by 비회원 »

비회원 wrote:엄연히 다를텐데요? 이미 다른 환경?에서 컴파일이 끝난 라이브러리를 링크 시키는 것과

같은 프로젝트내에서 컴파일해서 최적화 되어 인라인 되는 것은 다를거 같은데요?

분명 같은 프로젝트내에서 이루어지는 최적화 처리가 이미 라이브러리로 컴파일된것과 같은거라
생각하는건 오류같습니다

단순히 라이브러리의 최적화 옵션이 달라도 뭔가 틀어질거 같지 않나요?
글쎄요... 프로젝트라는 개념도 애초에 코드와 컴파일 과정을 관리하기 쉽도록 묶는 것이지, 컴파일 과정에서 추가적으로 뭔가 대단한 작업을 하기 위해 묶는 게 아닙니다. IDE에서 프로젝트를 컴파일하는 것도 따지고 보면 컴파일러 옵션과 컴파일할 파일들을 지정한 뒤 cl.exe에 해당 옵션을 넣고 실행하는 것이고요...

적어도 C++에서 소스를 컴파일하는 과정을 보면 개개 소스 파일을 완전히 독립적으로 목적 코드로 바꾼 뒤 이들을 한꺼번에 링크하는 것이고... 말씀하시는 프로젝트 내에서 따로 인라인화를 하는 작업이 링크 과정이 아니라 컴파일 과정에서 이루어졌다면 VC나 gcc에서 export 키워드를 지원 못할 이유도 없었겠죠. 이 둘은 서로 완전히 똑같은 일이니까요. 말씀하시는 내용은 결국 컴파일 과정에서 각 함수의 정의를 다른 컴파일 단위에도 전부 알린다는 말과 똑같은 것인데, 이는 현재 컴파일러 구조상 구현하기가 상당히 힘든 일입니다.

굳이 틀어지는게 있다면 stdcall과 cdecl과 같이 함수 규약이 어긋나는 정도가 아닌가 싶은데, 이거야 컴파일러 옵션이라기보다는 라이브러리 인터페이스의 문제라고 아닐까 싶고...

추가로, static library를 사용해도 인라인화가 되는 것을 확인했습니다.
비회원

Post by 비회원 »

아, 생각을 해보니 Profile-guided optimization 등을 사용한다면 프로젝트 개념이 의미 있을지도 모르겠군요. 일단 제가 말한 것은 일반론적인 것이었습니다.
비회원

Post by 비회원 »

코드를 만들어서 직접 니모닉을 확인해보시는것이 편리합니다.

단일 inline 함수의 경우
그냥 static함수로 생각하면됩니다. 인라인되지 않으면 다음과 같이 동작합니다.
정적 라이브러리에서는 링크 최적화로 합쳐질 수도 있습니다.
동적 라이브러리에서는 실행부와 dll에 모두 코드가 들어있으나 바이너리 상관관계가 없습니다.
예외 처리된 inline은 linkage됩니다.

so 또는 dll export된 class에서 inline함수의 경우
기본적으로 인라인 함수도 linkage됩니다. 그러므로 인라인 함수를 호출했다고 해서
인라인 되지는 않습니다. 단 실제로 인라인 되는 경우가 있습니다.
class 구성윈 변수 중에 class가 아닌 struct일 때 생성자와 소멸자가 없는
경우와 int, void*와 같은 일반 형일 때 이 변수의 값 또는 포인터를 얻어 올 경우
인라인 될 수도 있습니다.
위와 같은 경우라 해도 virtual인 경우는 class지정 이외에는 모두 linkage됩니다.

주 업무(?)가 코드 최적화라, 자주자주 테스트하는 편인데,
최근에 테스트 한 컴파일러는 msc++ 16.00(/O2/ Ob2 /Oi /Ot /Oy /GL)과
g++ 4.4(-O3 -fexpensive-optimizations -S)였고 모두 비슷하게 동작했습니다.

강제 인라인은.... 뭐니 뭐니 해도 public 변수로. C스타일 프로그래밍으로... -_-;;;
tomatowax
Posts: 464
Joined: 2005-01-17 12:22
Contact:

Post by tomatowax »

안녕하세요 TomatoWAX 입니다.

모두들 많은 답변 감사드립니다.^^

역시 예상대로 Static 과 Dynamic 이 조금 다를 수 도 있나보군요.

그런데 위의 비회원님의 답글을 보니..

경우에 따라 inline 이 되기도 한다고 하셨는데요~

그러면 Library 컴파일시 인라인 된 내용은 그냥 Library 에 풀어져서 포함될테고

어플단에서 컴파일시에 포함되는 인라인은 그냥 어플 기준으로 재작성될 것 같습니다.
(일반 어플 개발 .inl 사용과 동일한 효과를 내겠지요? )

또한 라이브러리에서는 이미 풀어졌기 때문에 (inline 이 되어서) Link 에러도 내지 않는다는 사실 하나 생겼습니다.

그렇다면 여기서요,

어플단에서 받아온 .inl 의 인라인 내용을 바꾸고 다시 컴파일 하게 되면

Library 내에서 풀어져서 포함된 inline 은 바뀐 내용이 적용 안되는 건가요??

Library 에서 inline 이 포함되었는지 아닌지 까지는 어떻게 잘 확인을 못하다보니 질문을 자꾸 올리게 되는군요.

Library 에서 inline 이 안되었다고 한다면 모든 inline 이 어플 기준으로 가니 이해하기 쉽지만

Library 에서 inline 이 풀어져 포함된다고 하면 굉장히 case 를 이해하기 어렵네요.

추가로 위의 비회원님, 코드 최적화를 자주 하신다고 하셨는데요~

인라인을 사용하는 경우 소스 용량이 커짐으로 속도가 느려지는 경우도 있던데

이 경우의 최적화는 어떠한 방법으로 해결하는 것을 추천하시나요? (인라인 제거 or 소스 분할?)
mastercho
Posts: 587
Joined: 2004-05-09 20:37

Post by mastercho »

최적화의 의미로 본다면 라이브러리의 인라인 화는 큰 의미가 없다고 볼수 있습니다
사실 함수 호출 부하는 최적화의 가장 단순하고 미약한 부분이라 볼수 있죠

인라인 함수의 진정한 의미는 최적화시에 , 코드 자체의 제거가 될수 있습니다
인라인 되므로써 공통적으로 사용되는 변수 및 가능한 수많은 명령들 제거가 될수 있겠습니다

STL 같은 경우 그 수많은 코드들이 다양한 최적화 방식으로 코드가 제거 되는데
컴파일러가 사용하는 최적화를 다양하게 이용 했습니다
그리고 거기에 핵심은 인라인입니다 , [ 인라인이 안되면 수많은 컴파일 타임
최적화중 극히 일부만 적용될것입니다 ]

[ 좀더 심화적인 인라인 최적화에 알고 싶으시면 Efficient C++를 참조하실것을 권해 드리고 싶습니다 ]


위에 비회원님이 라이브러리의 인라인화를 테스트 해보셨다고 하니 말씀 드리지만

이미 컴파일이 다 끝난 라이브러리는 , 코드 수준의 컴파일 타임때 이루어지는 최적화에
영향을 못받고 단순히 함수 호출 제거 정도밖에 해주지 못할거 같네요
비회원

Post by 비회원 »

인라인 함수로 고민을 많이 하시는 것같은데,
인라인 함수도 함수라는 거 잘 아시겠죠.

함수 내용이 변경되는 모든 관련 대상이 재컴파일이 필요한건 당연지사.
만약 확인이 안된다면, 단위 함수는 인수로 확인용 템플릿이나 int하나
붙여서 오버로딩 하시구요. 클래스 함수는 클래스 자체를 상속하시고
고치고 자하는 함수를 새로 만들던가 다른 이름으로 만드세요.
또한 실행 대상 코드에서 원 클래스는 사용하지 마시고 상속된 클래스만
사용하세요. 물론 문제가 크지만, 미지의 코드에 대해서 수정을 가하고
싶을 때는 어쩔 수 없습니다. 주로 땜빵할 때 그렇게 많이 하죠 -_-;

하여튼 어지간하면 재컴파일없이 공통 요소에서 사용하는 코드는
건들면 안된다는 겁니다.

필요하다면 어떠한 방법을 써서라도 bypass하는 겁니다. C++의 다형성을
이용해서 최대한 원래에 가까운 조작법이 가능하도록 말이죠.

컴파일 속도 걱정이라면 모든 인라인을 포기하시고 코드화 하세요.
개발 도중에는 동적 라이브러리로 컴파일 시간을 줄이고 release 때는
정적 라이브러리로 링크하시면 됩니다. 물론 링크 시간은 조금 더 걸릴
수도 있지만, 컴파일 제너레이션 보다는 빠를 겁니다. 그리고 링크시
최적화 옵션으로 인라인이 아닌 대상도 인라인 할 수 있니까요. 컴파일러
사양에 따라 다르긴 하지만요.
아니면... precompiled header를.. -_-

사정에 따라 다르겠지만 단순 변수를 리턴하는 경우를 제외하고
분기를 처리하거나 흐름 제어가 들어간 인라인 함수는 그냥 정적 코드화
해도 호출에 대한 부하는 그다지 느리지 않습니다. 거의 의미가 없다고
볼 수도 있습니다. x86에서는 콜링 컨벤션에 따라 다르겠으나
naked 함수를 만들어 보시면 이해가 되시리라 생각합니다.

게임 개발을 생각해보면, directx에서 매 프레임 마다 수백 수천번의
render state의 변경과 primitive 그리기를 가상함수로 처리하고
phys를 이용한다면 모든 물리 연산에 가상함수로 처리해도 우리는
꽤 훌륭한 게임을 만들 수 있지 않나요?

설계상 인라인 개념을 사용하기 어려운 운영 체제 커널도 그렇구요.
컴파일러 개발이 목적이 아니라면 인라인 함수 원칙만 잘 생각해보고
사용하시고 다른 곳에 열정을... 특별히 그걸로 먹고 사는게 아니라면요. -_-
비회원

Post by 비회원 »

http://msdn.microsoft.com/en-us/magazine/bb985575.aspx

여기에 optimization 파트를 보니 cross module inlining이라는 내용이 있군요. 이 내용 같구요. link time code generation이 지원되면서 가능해진 interprocedural optimization 테크닉 중 하나 같습니다.
Locked