• Save
Data Oriented Design 얄팍하게 살펴보기
Upcoming SlideShare
Loading in...5
×
 

Data Oriented Design 얄팍하게 살펴보기

on

  • 1,377 views

급하게 만들어서 헛점이 좀 많습니다.

급하게 만들어서 헛점이 좀 많습니다.
조만간 개정된 내용을 다시 올릴 수 있도록 하겠습니다.

Statistics

Views

Total Views
1,377
Views on SlideShare
1,370
Embed Views
7

Actions

Likes
0
Downloads
0
Comments
0

4 Embeds 7

https://si0.twimg.com 2
https://twimg0-a.akamaihd.net 2
https://twitter.com 2
http://cafe.naver.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Data Oriented Design 얄팍하게 살펴보기 Data Oriented Design 얄팍하게 살펴보기 Presentation Transcript

  • Data Oriented Design 살펴보기 김준경 / aka ㅈㄱ
  • 갑자기 웬 DOD?• 이미 2010년 즈음에 소개됐던 내용 – 무려 너티독 느님(Uncharted 2), 다이스 느님(Battlefield 3)들이 쓰셨음 – 사실 큰 바람이 지나간 시기인 거 같기는 함• 이후 실무에서 적용하려는 움직임도 많았음 – 실무에 적용해보려 도전하는 이들이 은근히 보이던데… – 아직까지 크게 부정적인 말이 안보이는 걸 봐선 나름 긍정적• 너도나도 좋다는데 굳이 마다할 필요 없잖아? – 나도 쓰면 좀 빠른 코드가 만들어지려나? – 잉여력 발산…할 곳이 필요했던 건 절대 아님
  • 갑자기 웬 DOD?• 이미 2010년 즈음에 소개됐던 내용 – 무려 너티독 느님(Uncharted 2), 다이스 느님(Battlefield 3)들이 쓰셨음 – 사실 큰 바람이 지나간 시기인 거 같기는 함 이젠 다들 별 관심도 없을듯• 이후 실무에서 적용하려는 움직임도 많았음 – 실무에 적용해보려 도전하는 이들이 은근히 보이던데… – 아직까지 크게 부정적인 말이 안보이는 걸 봐선 나름 긍정적• 너도나도 좋다는데 굳이 마다할 필요 없잖아? – 나도 쓰면 좀 빠른 코드가 만들어지려나? – 잉여력 발산…할 곳이 필요했던 건 절대 아님
  • 갑자기 웬 DOD?• 이미 2010년 즈음에 소개됐던 내용 – 무려 너티독 느님(Uncharted 2), 다이스 느님(Battlefield 3)들이 쓰셨음 – 사실 큰 바람이 지나간 시기인 거 같기는 함 인터넷에• 이후 실무에서 적용하려는 움직임도 많았음 – 실무에 적용해보려 도전하는 이들이 은근히 보이던데… – 아직까지 크게 부정적인 말이 안보이는 걸 봐선 나름 긍정적 (…아닌가?)• 너도나도 좋다는데 굳이 마다할 필요 없잖아? – 나도 쓰면 좀 빠른 코드가 만들어지려나? – 잉여력 발산…할 곳이 필요했던 건 절대 아님
  • 갑자기 웬 DOD?• 이미 2010년 즈음에 소개됐던 내용 – 무려 너티독 느님(Uncharted 2), 다이스 느님(Battlefield 3)들이 쓰셨음 – 사실 큰 바람이 지나간 시기인 거 같기는 함• 이후 실무에서 적용하려는 움직임도 많았음 – 실무에 적용해보려 도전하는 이들이 은근히 보이던데… – 아직까지 크게 부정적인 말이 안보이는 걸 봐선 나름 긍정적• 너도나도 좋다는데 굳이 마다할 필요 없잖아? – 나도 쓰면 좀 빠른 코드가 만들어지려나? – 잉여력 발산…할 곳이 필요했던 건 절대 아님
  • 닥치고 실전• 이미 작업은 진행하고 있었음 – 그런데 작업을 하면 할 수록 의문이 생겨남 – 내가 이해한 내용이 정말 맞는지? – 그리고 정말 적용을 시키면 빠르긴 한 건지?• 이 내용을 토대로 발표를 해보자 – 발표준비를 하면서 개인공부 및 정리 – 이미 아는 사람들한테 이해한 것들에 대한 검증• 테스트 코드 작성 – 이 자리를 빌어서 효율성에 대한 근거 마련
  • 닥치고 실전• 이미 작업은 진행하고 있었음 – 그런데 작업을 하면 할 수록 의문이 생겨남 – 내가 이해한 내용이 정말 맞는지? – 그리고 정말 적용을 시키면 빠르긴 한 건지?• 이 내용을 토대로 발표를 해보자 – 발표준비를 하면서 개인공부 및 정리 – 이미 아는 사람들한테 이해한 것들에 대한 검증• 테스트 코드 작성 – 이 자리를 빌어서 효율성에 대한 근거 마련
  • 닥치고 실전• 이미 작업은 진행하고 있었음 – 그런데 작업을 하면 할 수록 의문이 생겨남 – 내가 이해한 내용이 정말 맞는지? – 그리고 정말 적용을 시키면 빠르긴 한 건지?• 이 내용을 토대로 발표를 해보자 – 발표준비를 하면서 개인공부 및 정리 – 이미 아는 사람들한테 이해한 것들에 대한 검증• 테스트 코드 작성 – 이 자리를 빌어서 효율성에 대한 근거 마련
  • 닥치고 실전• 이미 작업은 진행하고 있었음 – 그런데 작업을 하면 할 수록 의문이 생겨남 – 내가 이해한 내용이 정말 맞는지? – 그리고 정말 적용을 시키면 빠르긴 한 건지?• 이 내용을 토대로 발표를 해보자 – 발표준비를 하면서 개인공부 및 정리 – 이미 아는 사람들한테 이해한 것들에 대한 검증• 테스트 코드 작성 – 이 자리를 빌어서 효율성에 대한 근거 마련
  • 봉껵적인 DOD 소개
  • Q. 게임 개발에서 항상 아쉬운 것?
  • Q. 게임 개발에서 항상 아쉬운 것? 성능아무리 개선돼도 아쉬움이 느껴지는 요소
  • 병목지점
  • 메모리 접근 속도의 향상
  • 메모리 접근 속도의 향상• 메모리의 캐시미스를 줄이자 – CPU는 메모리의 접근을 빠르게 하기 위해 앞으로 사용될 데이터를 예측하고 캐싱 – 캐시미스는 CPU의 예측이 실패한 경우• 어떨 때 예측을 실패하는가? – 일관성 없는 메모리 접근
  • 메모리 접근 속도의 향상• 메모리의 캐시미스를 줄이자 – CPU는 메모리의 접근을 빠르게 하기 위해 앞으로 사용될 데이터를 예측하고 캐싱 – 캐시미스는 CPU의 예측이 실패한 경우• 어떨 때 예측을 실패하는가? – 일관성 없는 메모리 접근
  • 메모리 접근 속도의 향상• 메모리의 캐시미스를 줄이자 – CPU는 메모리의 접근을 빠르게 하기 위해 앞으로 사용될 데이터를 예측하고 캐싱 – 캐시미스는 CPU의 예측이 실패한 경우• 어떨 때 예측을 실패하는가? – 일관성 없는 메모리 접근
  • 메모리 접근 속도의 향상• 메모리의 캐시미스를 줄이자 – CPU는 메모리의 접근을 빠르게 하기 위해 앞으로 사용될 데이터를 예측하고 캐싱 – 캐시미스는 CPU의 예측이 실패한 경우• 어떨 때 예측을 실패하는가? – 일관성 없는 메모리 접근
  • 일관성을 유지하면…?? ?
  • 일관성을 유지하면…?? 예상을 빗나갈 수 없다!! (나얼이횽 미안.. ㅠㅠ)
  • Object-Oriented Programming• 가장 잘 알려진 패러다임• 기계적인 접근보단 사람의 이해 를 고려하게 마련 – 객체를 나눌 때 보통 데이터간 근 접성을 고려하진 않음• 접근 순서를 예측하기가 어려움
  • Data-Oriented Design• 데이터를 종류에 따라 연속 적으로 배열 – 따라서 자연스럽게 업데이트 되는 객체에 일관성이 부여• 참고적으로 DOD != DDD
  • Data-Oriented Design• 데이터를 종류에 따라 연속 적으로 배열 – 따라서 자연스럽게 업데이트 되는 객체에 일관성이 부여• 참고적으로 DOD != DDD ㄴㄴㄴ… 이것과는 다르다. DDD는 데이터를 외부로 빼서 파라미터가 추가되거나 삭제 되더라도 코드상의 변화를 최소화 한다는 개념.
  • 여기에서 의문!! 트리(혹은 그래프) 형태의 구조에서 각 노드를 배열로 만들고,이를 업데이트 한다면 무슨 차이가 있는가?
  • GameObject 예시
  • GameObject 예시
  • 장점• 캐시 활용 – 비슷한 종류의 데이터를 연속적으로 배치 함으로서 다음을 예측하기가 쉬워짐• 모듈화 – 각 종류별 데이터들의 의존성이 높지 않은 형태로 만들 수 있음 – 이후 단점으로도 다시 소개• 병렬화 – 연속적이고 모듈화된 데이터의 병렬처리는 동기화에 대한 걱정이 덜한 편• 테스트 – 예외가 많지 않은 데이터의 특징상 유닛 테스트의 작성이 간편
  • 어떤 효과가 있나?DICE사 발표자료 참고(12P ~ 56P)
  • 여기서 또 의문!!배열로 만들었다고 해서캐시미스가 발생하지 않으리라보장할 수 있나?
  • 여기서 또 의문!!배열로 만들었다고 해서캐시미스가 발생하지 않으리라보장할 수 있나?
  • 여기서 또 의문!!배열로 만들었다고 해서캐시미스가 발생하지 않으리라보장할 수 있나? 이 부분…
  • 안하느니만 못한 것 같은…성능비교 테스트
  • 실제로 굴려보자• 행렬계산의 속도 비교를 통한 효율성 테스트 – 일반적인 4x4 행렬 배열과 16개의 변수를 각각의 배열로 만든 행렬 배열의 연산비교 이런데 쓰라고 있는 DOD가 아닐텐데…
  • 실제로 굴려보자• 행렬계산의 속도 비교를 통한 효율성 테스트 – 일반적인 4x4 행렬 배열과 16개의 변수를 각각의 배열로 만든 행렬 배열의 연산비교 이런데 쓰라고 있는 DOD가 아닐텐데…
  • 내용• 테스트 환경 – Windows 7 SP1 (x64) – Visual Studio 2010 SP1 (Release 모드 + 최적화 옵션 Off)• 설명 – Stack Memory, Heap Memory 배열 각각 테스트 – 4차원 행렬의 곱셈연산 (m = m * m) – Capacity만큼의 행렬을 모두 계산하는 내용을 50번씩 반복 – 시간 체크에는 GetTickCount() 함수 사용
  • 이런 게 서민 코드죠?
  • 이런 게 서민 코드죠?
  • 이런 게 서민 코드죠?이 부분을 각각 Stack Memory, Heap Memory로 구별해서 구현
  • Stack Memory 테스트 (capacity : 10000)
  • Stack Memory 테스트 (capacity : 80000)
  • Heap Memory 테스트 (capacity : 10000)
  • Heap Memory 테스트 (capacity : 80000)
  • Heap Memory 테스트 (capacity : 1000000)
  • 야심차게 준비했지만
  • 결과는 어찌됐던 일단,마무리
  • 문제점• 역시나 쉽게 익숙해지지가 않음 – 습관이 쉽게 어딜 가지 않음 – 기존 코드와 융합시키는데 추가적인 노력이 필요• 데이터를 잘 쪼개놓지 않으면 데이터간의 참 조가 어려워짐 – 잘 쪼개면 문제가 없다지만 그게 아니면 낭패
  • 결론• CPU의 캐시미스는 속도에 악영향을 줄 수 있음 – 그 흔한 OOP의 개념도 다시 검토해볼 필요가 있음 – DOD는 동일한 데이터를 배열화시켜 캐시 성공률을 높임• 좋은 디자인이 항상 좋은 성능을 보여주지는 않음 – 물론 이는 약간은 다른 성격의 시선일 뿐 – 가치 우선순위는 개개인마다 다를 수 있음• 적당한 타협이 필요 – DOD는 성능에 우선순위를 둔 개발방법 – 기존 방식과 DOD의 적절한 비율조절은 필수
  • 참고자료• Introduction to Data Oriented Design by DICE• Multiprocessor Game Loops : Uncharted2 by Naughty Dog• 데이터 중심 디자인 by 친절한티스• 게임코디 연구소 강좌 – [펌] Data Oriented Design by 노코드• Practical Examples in Data Oriented Design by Niklas Frykholm, BitSquid