**그냥 개인적인 감상임**
STL의 컨테이너가 느리다느니 일반 c코드는 느려서 인라인 어셈을 써야 한다느니.. 이런거 솔까 왠만한데선 뻘짓인 경우가 많음
어떤 프로그램이냐에 따라서 뭐 지 멋대로 변할 수도 있겠지만 일반적으로 전체 성능에 졸라 많은 영향을 주는 요소는
알고리즘(이게 병맛이면 뭘해도 느림) >>>>>>>>>>>>>>> 네트워크 i/o(본딩하고 지랄해봐야 200MB/s넘기기 힘듬) >>>>>>>> 디스크 i/o(레이드 및 ssd난리쳐도 램보다는 어떻게든 느림) >>>>>>> 인메모리상에서 메모리 관련 처리 >>>>>>> systemcall 최적화류 >>>>>>> 인라인어셈이나 modular 대신 bitwise를 쓴다든지 하는 지엽적인 것들
난 시스템프로그래밍을 주로 하는데.. 앵간하면 디스크 i/o 수준에서 이미 성능이 어떻게 될지 판가름 됨.
그 밑의 것들은 생산성이 허락하는 한 발로 짜도 티도 안남
미안 다 아는 얘기지? 책에 많이 나오잖아.
그러니까 알고리즘 개선과 io를 줄이는 것에 대해서 생각하자. 컨테이너는 그냥 STL쓰고.
과학계산 알고리즘과 게임 엔진은 예외로 하자.
프로그래밍 얘기:
puts(\"더러운 c... 컨테이너도 없는 무식한 언어!\");
STL의 컨테이너가 느리다느니 일반 c코드는 느려서 인라인 어셈을 써야 한다느니.. 이런거 솔까 왠만한데선 뻘짓인 경우가 많음
어떤 프로그램이냐에 따라서 뭐 지 멋대로 변할 수도 있겠지만 일반적으로 전체 성능에 졸라 많은 영향을 주는 요소는
알고리즘(이게 병맛이면 뭘해도 느림) >>>>>>>>>>>>>>> 네트워크 i/o(본딩하고 지랄해봐야 200MB/s넘기기 힘듬) >>>>>>>> 디스크 i/o(레이드 및 ssd난리쳐도 램보다는 어떻게든 느림) >>>>>>> 인메모리상에서 메모리 관련 처리 >>>>>>> systemcall 최적화류 >>>>>>> 인라인어셈이나 modular 대신 bitwise를 쓴다든지 하는 지엽적인 것들
난 시스템프로그래밍을 주로 하는데.. 앵간하면 디스크 i/o 수준에서 이미 성능이 어떻게 될지 판가름 됨.
그 밑의 것들은 생산성이 허락하는 한 발로 짜도 티도 안남
미안 다 아는 얘기지? 책에 많이 나오잖아.
그러니까 알고리즘 개선과 io를 줄이는 것에 대해서 생각하자. 컨테이너는 그냥 STL쓰고.
과학계산 알고리즘과 게임 엔진은 예외로 하자.
프로그래밍 얘기:
puts(\"더러운 c... 컨테이너도 없는 무식한 언어!\");
뻘뻘뻘글
오호오호스크랩
뻘글 아니야... 리소스(비트맵이건 3D데이터건 로딩할 데이터가 수십메가가 되는경우) IO를 읽고 메모리로 넣고 큐에 보낸다음 큐에서 그걸 fread하는것처럼 처리하는 기술(Game Programming gems라는 책에 참고..)을 쓰면 하드디스크 엑세스의 단점을 보완할 수 있지...
실제로 게임하다보면 하드 불들어올때 게임이 버벅일때 많았을꺼야... 메모리 부족으로 인한 스와핑이건, 실시간 스레딩에 의한 디스크io건... bus속도땜시 버벅이는건 물리적이라 어쩔 수 없으니... 디스크에서 뭘 읽을때에 대한 성능향상은 항상 고민해 보는게 좋아..
STL 컨테이너가 느리다는 사람들은 정말 이해 안될때가 좀 많더라
디스크에서 어떻게 읽어서 캐슁을 잘 할까는 io의 위쪽 알고리즘 얘기가 되고.. 결국은 bus에서 바틀넥이 걸리는 구조로 컴퓨터가 동작하니까 티 안나는 곳에서 최적화 하려고 삽질할 필요가 적다는 얘기죠
kukyakya// 동감. 인메모리 연산은..진짜 다른 io들에 비하면 너무너무 빨라서 빅오레벨에서 발리는거 아니면 티도 거의 안나고. 티가 확 나면 그때 고치면 될 뿐이고.
kukyakya// 나도 동감...