아래에 글이 있길래 짤막하게 이야기해보자면..
1. 프로파일링을 통해 병목지점을 파악한다. 높은 확률로 반복문 내부다.
2. 기존 코드들은 높은 확률로 단일스레드에 맞춰 짜여져 있다
3. 소스코드를 읽고 공유자원을 먼저 제거한다
4. 코어의 개수만큼 스래드를 쪼갠다. 만약 12코어고 반복문이 120번 돈다면 각 코어가 10번씩 반복문이 돌게하면 되도록 만든다(그 이상으로 쪼개면 불필요한 문맥교환 생김)
5. 결과가 리스트 등의 자료구조로 병합되어야 하는 경우라면 병합시에 락을 걸어준다. 데이터 경합을 방지하기 위해서.
6. 결과의 순서가 보장되어야 하는 경우라면 별도의 정렬 알고리즘을 준비한다.
생각보다 자잘하게 할 일이 많았던 것 같습니다.
더 좋은 방법이라거나 경험이 있으시면 공유해 주시면 좋을 것 같습니다.
ㅈㄴ 어려워보인다 ㄷㄷ 어떤 분야에서 일하길래 직접 멀티스레드 다룸?
해보면 별거없어요. 하나하나 따져보면 다 단순한 개념이랑 이유라서..
대단한 일 하는 사람은 아니고, 공장 노동자입니다. 서류작업 자동화 요청이 있는데, 여러가지 이유로 연산 수행속도가 너무 길기 때문에 최적화 작업할 일이 자주 생깁니다.
락 해서 얻는 성능 손해보다 멀티스레딩으로 얻는 이점이 더 많죠?
네. 그런 경우에만 해야하고, 락이 없는게 제일 베스트이긴 한데, 제가 작업할 때는 그런 상황이 잘 안나오더라구요. 최대한 적게 거는 방법은 고민해봐야 하는 것 같습니다.
저기서 락 하나 잘못되면 ㄹㅇ 좆됨
4가 뜬금 없네 얼마나 대용량인 비슷한 테스크 처리하길래 스레드 개수 팍올림?
그래픽 연산하는 부분이었는데, 최적화전 처리속도는 정확히 기억안나고 처리시 메모리가 4기가 이상 올랐던 기억은 납니다. 지금은 케이스마다 다르지만 무조건 절반 이상은 속도 개선이 되어서 한 건당 10초쯤 걸립니다.
그런걸 써야지 스레드 최적화 대상이 중요한거 알면서 그걸 누락하면 어캄..
말씀해 주신대로 어지간하면 안쓰는게 좋기는 합니다.. 결국 소스코드 전체를 모니터링하고 손봐야 하는거라 생각만큼 간단치가 않더라구요.
극한의 최적화 테스트해보고 싶으면 cpu affinity도 할당해보고 thread priority도 올려보고 여러개 해보셈 떠있는 프로세스에 따라 천차만별일테니 동일 환경 구축하는거 명심하고