c++ function call overhead가 많이 줄었다고 해도 최적화 수준에서 너무 차이난담
방금 3 차원 point 클레스 만들고 operator overloading해서 pure c랑 단순 사칙연산 비교했는데 너무 느리담...
너무 특수 케이스를 비교해서 그런가..?? inline 하고
lazy evaluation 적용해도 느린 것 같음
방금 3 차원 point 클레스 만들고 operator overloading해서 pure c랑 단순 사칙연산 비교했는데 너무 느리담...
너무 특수 케이스를 비교해서 그런가..?? inline 하고
lazy evaluation 적용해도 느린 것 같음
클래스로 구성했다면 static 이 아닌경우 this 포인터가 딸려가게 되고, 모든 멤버 변수에 this 를 통한 참조가 이루어지잖아.
그래서 느려지는거임.
클래스로 구성할때도 static 하게 잘 설계하면 꽤 비슷하게 맞출 수 있음유. 근데 그러면 편의성이 소거되지.
난 그래서 virtual 선언도 조심함. 그러면 주소 하나씩 밀려나잖. 메모리 사용량 늘어나고 느려짐. 물론 이건 속도 critical 한 영역 한정.
정말 정말 성능 중요한 곳이라면 static 하게 잘 구성하고 확장 문법 안쓰는게 좋음. 아니면 니 말처럼 c only 로 구현하든지. 근데 그렇게까지 쥐어짜서 만드는것 보다 간단하게 만들어 놓고 나중에 필요한 부분에 최적화 하는게 훨~~~ 재사용성 좋을거염. 시간도 절약되고.
근데 operator overloading말고 그냠 member 참조하면 속도가 똑같음 그건 왜그런거지? 최적화?
ㅇㅇ
물리 계산에 쓸 거라 속도 개중요함 특이 point 사이의 distance 연산
첫째는 최적화, 두번째는 테스트 환경 문제.
사실 core 하나가 처리할수 있는 명령어는 클럭당 1개가 아니잖아.
파이프라인과 스칼라 라는 버퍼 안에 여러개의 명령이 들어갈수 있는거지.
그래서 비효율적 코드도 비슷한 성능이 나오는 경우가 있어. 그건 테스트 환경의 차이.
만약 코어 구석구석을 병렬화해서 가속화할수 있는 명령어 조합에선 성능차가 나게 되지.
단순히 함수와 연산자 오버로딩의 관계에서 나타나는 성능 차이라면 컴파일러가 얼빵하다로 보는게 맞음.
그럼 왜 operator가 inline되면 결국 lazy evaluation 했을땐 그냥 member참조람 같은건데 왜 그걸 최적화 몬할까?? 그냥 intuituion 없이 profile 맨날 해볼수도 없고
그럼 수많은 point 사이의 collision 처리 같은걸 하게 되는것 같은데 그렇다면 영역분할이 중요함.
앗 동문서답했다 리프쓰느는동안 너무 많음 리플이 달렸담
컴파일러가 알아먹냐 못먹냐는 수학적으로 동일한 엔트로피를 갖냐 아니냐의 차이가 아니라 그냥 구현이 덜된거임유
그리고 단순 충돌 처리 같은 경우는, 거리구하는 식보다, 거리^2 판단이 더 유리할거임.
sqrt( dx^2 + dy^2 ) 보다 dx^2 + dy^2 가 나을거라는거.
상대비교는 되니깐
domain 나눠서 병렬하 하는 것은 할 생각인데 그래도 각 연산의 속도는 빠를수록좋잖암 호호 어렵다낵내가 컴과 전공이닐니라..
전공이 아니라 응 맞아 그래서 수학 함수는 많이 걸르지 그런식으로 너무 비싼 함수들이야
군집 충돌의 경우엔 캐시 활용이 중요함. 클러스터링도 잘해야해.
LOD 개념도 익혀두렴.
Level of Detail
MipMap 같은것도.
근데 정말 성능 중요하면 그런건 GPGPU 쓰는게 나을텐뎅.
응 neighbor list 같은 것도 쓰려공 근데 machine architecture 지식이 많이 부족한 것같아 그런 수치 테크닉보다
응 CUDA 확장도 생각하고 있엄좋은 조언이네
카페에 오면 부동소수점을 O(N) radix sort하기 위한 예제소스가 있어.
http://cafe.daum.net/codeinside/b8FO/65
미안한데 무슨 의미지? 카페?
거리에 대해 정렬해야 할 때는 이걸 쓸 수 있을거야.
아 밑읳리플을 지금 봤다
부동소수는 정상적으론 radix sort 가 불가능한데 작은 연산으로 특정 서수화 해서 정렬가능하게 한 경우지.
14000개 이상의 데이타의 정렬에선 radix 가 거의 짱먹으니까.
고맙네 좋은거 많이 알았네
근데 충돌은 아니라 많이 쓰일 지 모르겠다 하지만 응용할 수 있겠지 thanks!
My pleasure.
collision 이든, tessellation 이든, path finding 이든, 특정 시점기준으로 거리를 판단해야 할때 피치못하게 정렬이 필요한 경우가 있을거야.
정렬이 필요없게 만드는게 제일 좋긴 해.
카페는 저녁에 채팅방이 거의 활성화 되어 있으니까 모르는건 와서 채팅으로 물으면 돼
고맙네 많이 배워야겠다