[질문] 동적할당이 그렇게 느림? 게임같은 실시간은 진짜 new 아예 안해?

[익명(222.112)]

게임 도는동안은 new 절대 안하고 다 풀에 넣어서 재사용한다는데 참트루임?

[익명(220.79)]

안느리니까 그냥 쓰셈 - dc App

[익명(211.52)]

메모리 할당하는 비용이 크긴 할껄 웹서버도 그래서 처음에 미리 쓰레드풀 할당해놓으니까ㅇㅅㅇ

[익명(61.84)]

쓰레드풀이랑 메모리 할당이랑 무슨 상관임

[익명(211.52)]

쓰레드는 메모리안잡냐… 답답하노ㅋㅋ

[익명(61.84)]

쓰레드에서 메모리를 잡아서 쓰는 건 별도의 문제지

[익명(211.52)]

그게 왜 별도의 문제냐 쓰레드풀의 중요한 존재이유 중 하나가 쓰레드 생성비용을 줄이기 위함인데ㅋㅋ

[익명(61.84)]

그니까 쓰레드 생성 비용이랑 이 글에서 얘기하는 동적할당이 무슨 상관이냐고

[익명(211.52)]

좆도 모르면서 왜케 당당하노… 쓰레드가 메모리 잡는건 컴파일타임이 아니라 런타임에 일어나니까 당연히 동적할당이고 그런 생성비용을 피하고 싶어서 쓰레드풀을 써서 쓰레드 재사용하는건데 ㅅㅂㅋㅋ 어디서부터 설명을 해줘야되노? 쓰레드끼리 정적메모리 영역은 공유하는데 스택메모리랑 레지스터는 따로 잡는거부터 설명해줄까?

[익명(61.84)]

내가 몰라서 물어보겠냐? 운영체제 레벨에서 할당이 일어나는 부분인데 얘가 쓰레드 얘기를 하는 게 아닌데 쓰잘데기 없는 예시를 왜 드냐 이거야. 그리고 쓰레드 할당에 메모리 할당 비용만 들어가나? 그건 그냥 다 같이 묶어서 쓰레드 할당 비용으로 봐야지 오로지 동적할당에 대한 비용이 아니잖아 답답은 건 니야

[익명(211.52)]

아~씨~발~좆븅신같은련아~메모리할당도 씨발~운영체제 레벨에서 할당하지 그럼 씨발 느그애미가 할당해주냐? 그리고 씨발 쓰레드 생성 비용에서 당연히 씨발 메모리 할당비용이 제일 크니까 예시로 들었지요 이런 씨부랄련아 동적할당이 느려서 메모리풀은 사용하는 예시로 쓰레드로 래핑되긴 했지만 생성비용때문에 쓰레드풀이라는 비슷한 방법론을 적용한 대표적인 예시가 있으니 이해하기 쉽게 예로 든거아니야 좆빡대가리새끼야

[익명(61.84)]

뭐라는지 하나도 안 읽힌다. 쓸데없는 예시에 쓸데없는 육두문자까지 붙이는 습관을 봐서 개발자에게 중요한 능력 중 하나인 커뮤니케이션 능력이 떨어지는 친구구나

[익명(211.52)]

그리고 씨발련아 쓰레드생성하고 작업할당하기 전까지는 쓰레드 스케쥴러에 등록만 하고 레지스터랑 메모리만 할당해놓고 주소만 저장해놓으면 되는데 당연히 씨발 생성비용의 대부분이 메모리 할당이지 다른 씨발 거창한 생성비용의 예시가 있으면 좀 알려주면 안되나?

[익명(211.52)]

커뮤니케이션 능력은 이 씨발련아 니가 댓글을 쳐읽어봐라 나는 어쨌든 근거와 논리를 가지고 주장을 하는데 니 새끼는 말꼬리만 쳐잡는데 그게 커뮤니케이션이냐? 쓰레드할당에서 메모리할당이 지배적이라고 생각해서 예시로 들었으니까 그렇지 않은 이유를 설명을 해보라니까? 계속 앵무새마냥 응~달라 이지랄하지말고?

[익명(175.223)]

맥락 이해를 왜 못 하니 쓰레드 예시는 이 글에 적절하지 못 하다니까? 그리고 단순히 메모리 할당 비용 때문에 쓰레드풀을 쓰는 게 아니라 컨텍스트 스위칭 비용이 어마어마하니까 정해진 영역 안에서 놀아라가 핵심인데

[익명(175.223)]

쓰레드 초기 생성 비용이 문제라면 초기화 시점에 스레드 수백개 만들어놓고 쓰면 되겠네 사람들이 그걸 몰라서 쓰레드풀을 쓸까? 쓰레드풀을 쓰는 목적부터 다시 알아봐

[익명(211.52)]

방금까지 쓰레드 할당이랑 메모리 할당이랑 다르다고 자기가 주장해놓고 콕 찝에서 어디가 다른지 좀 알려주세요~ 시전하니까 컨텍스트 스위칭으로 말돌리노 그래서 처음부터 중요한 "존재이유 중 하나" 라고 한건데 병신인가… 그리고 쓰레드 초기 생성 비용이 문젠건 논쟁의 여지없는 사실인데 씨발… 애초에 톰캣 디폴트가 초기생성 25개에 최대 200개나 되는데 서버 규모 좀만 커져도 당연히 처음부터 몇백개씩 잡지… 말도 안되는 소리를 하냐…

[익명(175.223)]

동적 할당 비용만을 위해서 쓰레드풀을 만들어서 쓰는 게 아닌데 마치 그게 쓰레드풀의 존재 이유처럼 말하고 그걸 근거로 동적 할당 비용이 크다고 얘기하는게 비유가 적절하지 못 하다고 얘기하는 것 뿐인데 이렇게 말해도 못 알아먹으면 그냥 얘기를 그만하자. 밑에 쓰레드 활용 질문만 봐도 쓰레드를 얼마나 활용할 줄 아는지 알겠으니

[익명(211.52)]

"존재이유 중 하나"요 이런 씨발련아 개좆같은 새끼 아까부터 반박은 안하고 말꼬리 쳐잡고 인신공격만 하노 쓰레드 수백개 어쩌구 하더니 톰캣 25/200개가 디폴트라니까 지 불리한건 아가리 닥치고

[익명(211.52)]

마치 말못하는 대단한 쓰레드풀의 존재이유가 있는 것처럼 말씀하시는데 그럼 그냥 그걸 설명도 필요없고 딱딱딱 나열만 해도 제가 납득하지 않을까요 예? 전 크게 생성비용/컨텍스트 스위칭 2개밖에 안떠오르는데? 동시처리는 쓰레드 그 자체의 목적이니까(쓰레드풀은 그걸 도와주는거고) 뺀다고 하면?

[익명(211.52)]

그리고 그렇게 아랫댓글을 언급하면서 인식공격하는데 왜 아랫댓글처럼 3줄로 깔끔하게 설명을 못하나? 이해가 안되네ㅋㅋ 나는 게임프로그래밍과 게임에서 메모리관리에 대해서 좆도 모르니까 어쨌든 리스펙하고 질문하고 들은건데 니새낀 왜 명쾌하게 설명도 못하면서 말꼬리를 쳐잡는거임? 1. 쓰레드 생성비용에서 메모리할당을 제외하고 큰 비용이란? 2. 정말 쓰레드풀에서 생성비용이 안중요한 이유임? 3. 쓰레드 몇백개 운운하는데 톰캣은 개인서버로 파기만 해도 디폴트가 25/200개인데? 제발 대답좀 해주면 안되나? 아래에서 존나 잘알더만

[익명(220.118)]

이건 또 뭔데 투기장이 열려있는거냐

[익명(117.111)]

이씨발새끼 하도 뻗대고 인신공격 쳐하길래 서로 핀트가 어긋났나 내가 오개념이 있나 생각해서 검색하고 왔네 씨발 애초에 쓰레드풀은 보통 서버에서 쓰이는 방법론이고 니가 아래에서 잘아는 게임 클라처럼 메모리/쓰레드를 직접 다루는거랑 개념자체가 틀린데 씨발… 상식적으로 클라에서는 무겁고 연속적인 연산을 다루니까 쓰레드가 많이 필요하다기보다 효율적으로 사용해야되는거고 서버에서는 가겹고 동시적으로 많은 요청을 다뤄야 되니까 쓰레드를 많이 만든다음 동시에 요청을 받아놓고 코어가 몇개건 간에 시분할해서 마치 동시에 응답하듯이 작동해야하니까 쓰레드풀이 필요한건데 씨발진짜… 그러니까 쓰레드 수백개가 말이 안되니 어쩌니 하지

[익명(117.111)]

왜 잘모르는 분야에 대해서 존나 아는 척하는지 모르겠네 그것도 인신공격까지 쳐하면서 정작 아래에서도 씹고수 답변은 다른 사람들이 했는데… 상식적으로 메모리/쓰레드를 직접 다루는 게임프로그래밍이라 쓰레드풀이랑 둘 다 존나 잘알수가 있나?

[익명(220.118)]

1. 스레드 많은것도 context switch 비용이 있어서 오버헤드임 / 2.클라는 애초에 무거운 연산이 렌더링이 대부분을 차지하니 잡단위로 끊는게 맞다 / 3. new는 os에 요청해야 하는 비용이 있고 단편화의 문제가 있지만 Low-fragment-heap이 있으면 그렇게까지 큰 오버헤드는 아니다. / 4. 스레드 때놓고 제목에나 집중해라

[익명(220.118)]

클라는 new 그냥 굴리는곳도 많은걸로 암. 서버는 (1. 성능의 일관성을 유지, 2. 예측인원 초과등의 이슈로 OS에서 메모리할당을 실패하면 ㅈ됨) 같은 문제로 인해 풀링하는게 당연함.

[익명(123.254)]

메모리풀은 "매번 할당하는 대신, 동일한 크기의 블록들을 미리 여러 개 할당" 하는 거고 스레드풀은 "매번 스레드 만드는 대신 미리 몇개 만들어서 걔네한테 일을 줌" 이겁니다. 둘 모두 생성/삭제 오버헤드를 풀의 생성/삭제 시점으로 집중하여 프로그램을 안정적으로 만든다는 공통점이 있기는 합니다. 메모리 할당/제거 1만번 할걸 풀 생성 한번으로 퉁치고, 스레드 할당/제거 1만번 할걸 스레드풀에서 스레드 8개 생성하는거로 퉁치고 하는 거죠. 물론 문제의 해결법이 같다는 거지 둘이 무슨 연관이 있는 건 아닙니다. 스레드풀이 메모리풀의 응용인 건 아니에요. 예를 들어 메모리풀 사이즈가 100인데 생성을 101개 한다면 문제가 생기겠지만, 스레드풀 사이즈가 8일 때 스레드풀에 작업 100개 넣는 건 문제가 안되거든요

[익명(117.111)]

번호가 내가 단 번호랑 호응이 안되서 나한테 한 대답인지 아리까리하긴 한데 1. 쓰레드가 잡보다 많으면 메모리가 낭비되는 오버헤드는 있어도 대기 상태인 쓰레드들은 스케쥴링에 큰 영향을 끼치지 않기 때문에 컨텍스트 스위칭 비용이 일어나지 않음. 애초에 컨텍스트 스위칭은 이미 실행중인 쓰레드와 실행될 쓰레드 사이에서 일어남 2. 난 클라 잘 모른다. 3. 무슨 말인진 아는데 이 얘기가 왜 나왔는지 모르겠다 4. 난 제목의 적절한 예시로 쓰레드풀을 든 것임. 동적할당의 비용문제로 미리 생성하는 경우를 언급하려면 class/thread같은 메소드를 끼고 있는 경우가 적절하다고 판단했음. 그렇지 않으면 동적할당을 전부 미리 할당할꺼면 정적할당이랑 뭐가 다른데? 라고 생각이 들기 마련이니까

[익명(220.118)]

그냥 투기장 열렸길래 내 생각 정리해봄. 좋은 정보 고맙다

[익명(117.111)]

쓰레드풀이 메모리풀의 응용이라서 쓰레드풀을 언급한 것은 아님. 동적할당이라는 비용이라는 측면에서 언급한거지. 어쨌든 제목에서 게임에서 new라는 언급이 있으니까 미묘하게 핀트가 어긋나있는건 인정함

[익명(117.111)]

다만 175.223/61.84이랑 투기장에서는 내 생각이 여전히 맞다고 생각함. 쓰레드풀의 중요한 존재 이유 중 하나는 생성 비용이고 그 생성 비용의 가장 큰 부분은 메모리할당비용임. (제목과 본문의 핀트가 어긋났지만) 쓰레드풀이 동적할당의 비용의 예시로 들 수 있다고도 여전히 생각함 그리고 니 댓글은 그냥 투기장 다 읽고 니 생각을 1234로 적었다고 생각하고 읽으니 뭔 말인지 알겠음 1빼고 다 니 말이 맞음ㅇㅇ

[익명(220.118)]

ㅇㅇ 1은 내가 틀렸다고 생각함.

[익명(223.62)]

러슬람 러들러들~

[익명(39.7)]

너는 밥먹을때도 반찬 미리 입에 다쳐넣고 밥만 먹어라 시발새끼야

[익명(118.235)]

이런 애들은 딱봐도 개발 아예 안하거나 국비네

[raker(rakerdam)]

아예 안 하진 않고 최대한 낮은 빈도로 쓰지

[익명(skuld88)]

그렇게 안 느림

[익명(220.118)]

느리진 않은데 리소스를 풀로 사용해야 하는 환경이면 그것도 풀링해야지

[익명(116.121)]

게임에서 성능 저하의 가장 큰 원인은 메모리임

[익명(123.254)]

Heap 영역은 프로세스 내에서 공유됨. malloc 같은 함수는 이 Heap 영역을 관리하는데, 함수를 만들 때 함수가 어떤 환경(할당 크기, 할당 빈도 등)에서 사용될 지 예측할 수 없기 때문에, 메모리 단편화를 줄이기 위한 각종 기법들이 포함되어 있음. 이로 인해 오버헤드가 발생하고, 또 줄이는 거지 아에 없앨 수 있는 건 아님. 게임 같은 경우에서 많은 오브젝트의 생성/삭제를 그냥 malloc/free를 사용해버리면 오버헤드도 크고, 단편화도 생기기 쉬움. 그래서 malloc으로 큰 영역을 잡고, 이 영역 안을 프로그래머가 직접 관리하는 거임. 프로그래머는 자신이 사용할 환경(할당 크기, 할당 빈도 등)을 거의 정확하게 알고 있기 때문에 malloc보다 더 효율적으로 메모리를 관리할 수 있기 때문임

[익명(123.254)]

예를 들어 슈팅게임을 만든다고 가정하고, 게임에 나오는 총알들을 Bullet 객체라고 가정하겠음. 이런 경우에 총알 발사할 때마다 new를 호출하면, 커널모드 전환->커널 내부 동적 할당을 위한 메모리풀 (bin, pool 등)에서 적절한 크기 탐색->만약 없으면 virtualalloc, mmap 등으로 메모리 할당->유저모드 전환->Bullet 생성자 호출 이렇게 될거임 삭제할 때도 비슷하고 반대로 직접 메모리 풀을 짠다고 생각해 보면, 예를 들어 struct BulletPool{bool valid; Bullet v;} 같은 구조체 100개 배열로 만들었다고 해보자 그러면 그냥 Pool에서 valid==False인거 찾기->Bullet 생성자 호출. 이게 끝임

[익명(211.52)]

ㅆㅅㅌㅊ 대답이네 근데 대답이 너무 좋으니까 궁금한게 생김 그럼 게임은 성능때매 멀티프로세싱도 존나 중요한걸로 아는데 메모리풀을 직접 관리하면서 멀티프로세싱도 신경써야함? 은… 생각해보니까 쓰레드마다 역할을 쪼개면 될거 같긴하네 누구는 충돌판정하고 누구는 그래픽연산하고 누구는 서버랑 통신하고 이런 식으로 할 듯?

[익명(61.84)]

그건 하빠리 반쪽자리 스레드 활용법이고 태스크 개념을 넣어서 어떤 작업이든 태스크로 여유 있는 스레드에다가 던지는 게 더 다중 스레드를 효율적으로 사용할 수 있다

[익명(123.254)]

ㅇㅇ 그런 경우에는 메모리풀을 스레드 세이프하게 만들어야 함

[익명(211.52)]

ㅇㅎ 이해했음 메모리풀은 스레드 세이프하게 설계해야 되고 스레드는 특정 태스크 의존적이지 않게 설계한 다음 필요한 태스크를 딱딱 스레드한테 부여해서 처리하는 방식…같은 느낌인가보네

[익명(123.254)]

게임 같은 경우에는 각 연산들 사이에 순서가 중요한 경우가 많다 보니 말한 것처럼 하는 건 어려움 당장에 충돌 판정이 끝나야 화면을 그리든가 할 거 아녀. 그리고 적은 것처럼 스레드들을 기능별로 하나씩 만드는 건 좀 61.84가 말한 것처럼 비효율 적인 방식임. 예를 들어 물리엔진/음악/그래픽 이렇게 3개로 스레드를 나눴다고 생각해 보셈. 이러면 3코어 cpu에서는 효율적으로 돌아가겠지? 그런데 앞으로 cpu를 8코어 16코어 이런식으로 늘려나갈 텐데, 성능 향상이 거의 없어질거임. 기능을 3개로 나눈 것 자체가 일종의 보틀넥으로 작용할 수 있음

[익명(123.254)]

그래서 보통은 작업 던져주면 작업 하고 결과값 주는 스레드 여러 개를 만들고, 걔네한테 일을 던져주는 방식으로 할거임. 이러면 작업 던지기/결과 받기 이런 구조로 인한 오버헤드가 있긴 하겠지만, 기능 3개 나누는 방식보다는 더 효율적으로 코어들을 굴릴 수 있다 보니 전체적인 성능은 향상될거거든

[익명(39.7)]

초창기 게임들에는 싱글 스레드를 사용했는데 게임 규모가 커지면서 성능 문제에 도달했음 - dc App

[익명(39.7)]

그래서 다음으로 나온게 작업별로 스레드를 쪼개서 돌리는거임 그래픽, 물리, 사운드, 기타등등... - dc App

[익명(39.7)]

그런데 얘도 결국 일하는 얘만 일하고, 나머지는 노는 경우가 발생함 그래서 그 다음으로 사용하는게 task/job system 임 - dc App

[익명(39.7)]

각 스레드가 특별한 목적을 띄지 않고, 제네럴하게 작업을 처리하는 구조로 변경됨. 이 때, 게임의 특성 상 작업의 순서가 중요하기 때문에 여러 작업을 선언하고 DAG으로 만든다음 순서가 있으면 순차적으로, 없을경우 병렬적으로 처리하는 방식을 택함 - dc App

[익명(39.7)]

언리얼 Job Thread / Unity Job System 이 위 내용을 구현한 것중 하나임 - dc App

[익명(39.7)]

좋은댓글 15퍼 욕설댓글 85퍼