•
7월 16일 토요일
•
크래프톤 정글 1기 임용식
들어가며
•
전공지식들과 손끝으로 작성해내는 능력 간의 간극이 있는 경우가 많다
•
추상화가 많다는건, 개발 속도는 빨라지더라도 자신만의 입맛으로 다듬을 수 없다
IT & CSAPP
캐시히트 극대화
•
메모리는 최대한 재사용하고, 연속적으로 구성하도록 해야한다
◦
공간적 지역성
◦
시간적 지역성
•
연결리스트 → 배열로 변경하면 캐시히트 증가
•
Aos(Array of Structs) → SoA(Struct of Arrays)
•
ECS Architecture : Entity Component System
◦
객체(엔티티)를 최소한의 기능단위(컴포넌트)로 분해
◦
매 프레임 업데이트(시스템) 시 캐시 히트를 극대화
◦
→ 데이터 지향 프로그래밍(DOP)
▪
OOP도 추상화가 잘되고 재사용하기가 좋은 패러다임인 것은 맞지만, OOP가 항상 정답은 아니다
해싱,캐싱,배칭
•
데이터 재사용은 어떻게 할 수 있을까요? → 할당한 뒤 해제를 안 하면 됩니다
◦
할당된 데이터를 재사용합니다
◦
매 프레임마다 인스턴스를 지우는게 아니라 재사용하는 형태
•
Pooling
◦
객체(리소스)를 해제하지 않고 활성화 상태만 변경하며 재사용하는 것
◦
할당된 리소스는 풀 안에서 대기
◦
이때 풀 안의 객체들은 서로 구분될 필요가 없음
•
해시테이블은 O(1)의 시간복잡도로 조회가능 : 해싱을 이용해 캐싱을 모방 가능
◦
해시는 분류(Classify)에 특히 매우 유용
•
SIMD(Single Instruction Multiple Data)
•
메모리 풀링과 할당자
RB트리, 말록 랩 이거 공부하라는 의도는 알겠는데 어따 쓰나요?
◦
메모리 단편화, 캐시 미스, 페이지 폴트
◦
할당 해제가 빈번하게 수행 → 스택 할당자
▪
메모리 단편화, 페이지 폴트 발생이 전혀 없음
◦
동일한 객체가 많이 할당 → 풀 할당자
◦
단편화 유발 가능성 → 작은 메모리 할당자
▪
메모리 단편화 : 대부분 작은 할당에 의해 발생
▪
작은 할당이 많은 경우 : 작은 메모리 할당자를 사용(풀 할당자의 집합 형태로 구현)
OSTEP
메모리 관리 정책
•
Copy-On-Write
◦
OS는 연산과 데이터의 정합성을 요구할 때 메모리를 갱신
•
활성 리소스 최소화를 통해 관리 복잡도를 낮추고 약간의 성능 이득 기대
◦
커스텀 할당자들과 함께 구현됨(new/delete X)
스핀락과 락프리
•
PintOS의 첫번째 통곡의 벽
◦
busy-wait은 스레드가 ‘대기하지 않음’
→ 자원소모 증가, 동시 작업 불가
◦
Mutex는 스레드가 ‘대기’
→ 자원소모 없음, 스케쥴링 가능
•
PintOS의 또다른 통곡의 벽
◦
시스템 콜
▪
비용이 큼
▪
그럼 뮤텍스는 항상 좋은게 맞나?
◦
Busy-wait의 비용이 더 저렴하다면, 뮤텍스보다 busy-wait을 사용하는게 낫다
결론
•
항상 좋은 방법은 없다. 상황에 맞는 최선의 방법을 고려할 것
•
현재 상황은 ‘프로파일링’으로 알아내야한다
•
‘최선의 방법’은 정글 커리큘럼으로 습득 가능하다