소멸자는 그냥 함수임미다. 인라인이 되거나, 안에 알맹이가 없다면 당연히 dead code elimination 으로 마법처럼 사라지게 돼있읍니다. - return 0;
커헠(msca8h)2020-03-08 23:58
답글
물론 is_trivially_destructible_v<T> == true 혹은 컴파일러가 destructor가 redundant하다고 판단한 경우는 그렇죠
예전에 글쓴분이 올리신 move-semantic 관련해서 이어서 별생각없이 던진 댓글이었습니다
가끔 어셈 까보면 move되고 난뒤 valueless-state에 접근을 안하는 상황에서 함수를 안날리는경우를 확인해서요.
글쓴분이 언어마다 어떤상황을 테스트한다고 명시한것도 아니기도 하고 전후사정 없이 위의 댓글자체만으로 misleading한건 인정합니다.
ub(99.199)2020-03-09 00:06
답글
살짝 논지에서 벗어난 rant를 좀 하자면 "컴파일러가 판단하는" RVO(pre C++17 guaranteed RVO), NRVO같은 copy elision, 애매모호하게 표준에 기재되어있던 strict-aliasing rules등의
C++에서 제공하는 implicit한 매커니즘에 뒤통수를 맞은분이 저뿐만이아니라 여럿 있을껍니다.
업계에서 성능이 중요한 hot-path, 타이트한 루프등에서 큰 object를 return하는 함수에서 copy-elision 될까 안될까 무서워서 함수 T get()이면 될걸 아직도 void get(T& Destination_)으로 함수를 작성하고있습니다.
ub(99.199)2020-03-09 01:08
답글
그렇게 성능에 신경을 써야되는곳이면 하나하나 어셈을 까봐야되는거 아니냐, 차라리 assembly로 코드를 짜면 되지 않겠냐 절이싫으면 중이 떠나라 라고 말하면 저같은사람도 할말은 없겠죠.
뭐 저랑 의견은 다르실순 있겠지만 개인적으로 표준에서 no-op destructor from moved object, NRVO같은건 빨리빨리 guarantee를 해줬으면 하는 바램입니다.
컴파일하는데 10몇분넘어가는데 어셈으로 확인을 하는것도 일이고, 확인을 안하고 넘어갔는데 나중에 런타임에서 원하는 성능 안나와서 찾아내서 다시 작성하는것도 일이니까요.
ub(99.199)2020-03-09 01:09
답글
도대체 뭔일을 하길래 그 정도 성능까지도 쥐어째내야되는거요? - return 0;
커헠(msca8h)2020-03-09 01:34
답글
유감스럽게 됐습니다. 만약 SO나 레딧에서 물어보셨다면 흔쾌히 답을 해드렸을거같지만
커뮤니티 특성상 명확한 대답을 드릴수없는점 이해해주실수 있겠습니까?
아시다시피 위처럼 micro-optimize하는 기행들은 scalable한 아키텍쳐, 하드웨어성능, 상황에마다 최적의 data structure, 할당,수거패턴에따른 메모리할당자, CPU-cache 친숙한 memory layout, 바이오스 세팅, os세팅등
이 먼저 제대로 갖춰졌다는 가정하에 의미가 있는 내용입니다.
저정도의 최적화가 필요한곳은 좁은 스펙트럼안에서 유추하실수 있을거같으니 나머지는 상상에 맡기도록하겠습니다. 죄송합니다.
ub(99.199)2020-03-09 07:29
ideal 말하는거?
다믜(damhiya)2020-03-08 22:46
답글
idiomatic = 관용적인 아니냐
다믜(damhiya)2020-03-08 22:49
답글
왠지는 몰라도 Rust쪽에선 elegant 비슷한 의미로 쓰임
ㅇㄹ(rerereq)2020-03-08 22:50
답글
나도 언제 idiomatic 하고 ideal 했갈렸다가 사전 찾아봤었는데, 이 말 들으니까 그냥 착각한건지 아니면 ideal이 들어가도 말이 되는 용래를 어디서 본건지 모르겠네.
다믜(damhiya)2020-03-08 22:55
답글
아 찾아보니 관용이 널리 쓰인다는 의미인듯
ㅇㄹ(rerereq)2020-03-08 22:59
답글
그냥 문맥에서 자연스러운 혹은 실용적인 코드, 빡세게 최적화한 읽기 힘든코드 로 대충 이해함 난
예) 통용되는 모던 c++ vs c스타일 c++코드
글쓴이가 그렇게 의도하고 쓴진 모르겠지만
idiomatic 코드에서 타이트한 루프돌리면 소멸자호출 안하는 러스트가 다이길거같은데 난 이 대결 반댈세
C++도 다 최적화 되자나요
표준이아니라 스트롭스트롭 사진 모셔놓고 절하고 컴파일 하는거 아니면 안없어질확률이 높다는게 학계 정설
꼭 그렇다고만 볼 수 업읍니다 - return 0;
디씨에서 존댓말.. 뭐 왔으니 저도 존댓말을 붙이는게 예의상 도리이니 어떤점에서 그렇다 볼수 없는지 주장에 좀더 살을 붙여주시겠습니까?
소멸자는 그냥 함수임미다. 인라인이 되거나, 안에 알맹이가 없다면 당연히 dead code elimination 으로 마법처럼 사라지게 돼있읍니다. - return 0;
물론 is_trivially_destructible_v<T> == true 혹은 컴파일러가 destructor가 redundant하다고 판단한 경우는 그렇죠 예전에 글쓴분이 올리신 move-semantic 관련해서 이어서 별생각없이 던진 댓글이었습니다 가끔 어셈 까보면 move되고 난뒤 valueless-state에 접근을 안하는 상황에서 함수를 안날리는경우를 확인해서요. 글쓴분이 언어마다 어떤상황을 테스트한다고 명시한것도 아니기도 하고 전후사정 없이 위의 댓글자체만으로 misleading한건 인정합니다.
살짝 논지에서 벗어난 rant를 좀 하자면 "컴파일러가 판단하는" RVO(pre C++17 guaranteed RVO), NRVO같은 copy elision, 애매모호하게 표준에 기재되어있던 strict-aliasing rules등의 C++에서 제공하는 implicit한 매커니즘에 뒤통수를 맞은분이 저뿐만이아니라 여럿 있을껍니다. 업계에서 성능이 중요한 hot-path, 타이트한 루프등에서 큰 object를 return하는 함수에서 copy-elision 될까 안될까 무서워서 함수 T get()이면 될걸 아직도 void get(T& Destination_)으로 함수를 작성하고있습니다.
그렇게 성능에 신경을 써야되는곳이면 하나하나 어셈을 까봐야되는거 아니냐, 차라리 assembly로 코드를 짜면 되지 않겠냐 절이싫으면 중이 떠나라 라고 말하면 저같은사람도 할말은 없겠죠. 뭐 저랑 의견은 다르실순 있겠지만 개인적으로 표준에서 no-op destructor from moved object, NRVO같은건 빨리빨리 guarantee를 해줬으면 하는 바램입니다. 컴파일하는데 10몇분넘어가는데 어셈으로 확인을 하는것도 일이고, 확인을 안하고 넘어갔는데 나중에 런타임에서 원하는 성능 안나와서 찾아내서 다시 작성하는것도 일이니까요.
도대체 뭔일을 하길래 그 정도 성능까지도 쥐어째내야되는거요? - return 0;
유감스럽게 됐습니다. 만약 SO나 레딧에서 물어보셨다면 흔쾌히 답을 해드렸을거같지만 커뮤니티 특성상 명확한 대답을 드릴수없는점 이해해주실수 있겠습니까? 아시다시피 위처럼 micro-optimize하는 기행들은 scalable한 아키텍쳐, 하드웨어성능, 상황에마다 최적의 data structure, 할당,수거패턴에따른 메모리할당자, CPU-cache 친숙한 memory layout, 바이오스 세팅, os세팅등 이 먼저 제대로 갖춰졌다는 가정하에 의미가 있는 내용입니다. 저정도의 최적화가 필요한곳은 좁은 스펙트럼안에서 유추하실수 있을거같으니 나머지는 상상에 맡기도록하겠습니다. 죄송합니다.
ideal 말하는거?
idiomatic = 관용적인 아니냐
왠지는 몰라도 Rust쪽에선 elegant 비슷한 의미로 쓰임
나도 언제 idiomatic 하고 ideal 했갈렸다가 사전 찾아봤었는데, 이 말 들으니까 그냥 착각한건지 아니면 ideal이 들어가도 말이 되는 용래를 어디서 본건지 모르겠네.
아 찾아보니 관용이 널리 쓰인다는 의미인듯
그냥 문맥에서 자연스러운 혹은 실용적인 코드, 빡세게 최적화한 읽기 힘든코드 로 대충 이해함 난 예) 통용되는 모던 c++ vs c스타일 c++코드 글쓴이가 그렇게 의도하고 쓴진 모르겠지만
내 맞워요 그래서 수식어도 이쁘다고 붙여줬음