윈도우의 메모리 단?편화 문제 해?결방?법?

[공기역학(experimenter)]

대충시작점 (Github)

https://youtu.be/wB74q02x_P0

성능이야기출처(42:20부터 대충 10분동안)

영상의 메모리풀 구현은 좀 앞부분

windows는 LFH라는것을 이용해 쪼꼬들은 대충 new박아도 성능 ㅍㅌㅊ하대 ㅇㅇ

메모리풀 구현은 의외로 걍 간단히 해도 성능 오조오억배 빨라지는듯 ㅇㅇ

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[공기역학(experimenter)]

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[공기역학(experimenter)]

[ㅇㅇㅇ(175.223)]

꼴랑 c하나 하면서 그런것도 해결 못하고 무능한 자식들

[공기역학(experimenter)]

[우물안개구리(lastpenguin)]

https://github.com/lastpenguin/MemoryPool/tree/master/Project_C/Library%20Public%20Version/Core%20Library%20BETA%202.0

[우물안개구리(lastpenguin)]

내꺼랑 비교해보지 않을래?

[공기역학(experimenter)]

오랜만에보니까 의외로 읽히네 근성문젠듯

[공기역학(experimenter)]

오 락프리

[공기역학(experimenter)]

님아 Interlocked도 락인데 왜 락프리인건지 앎?? 대기시간 엄청 짧아서 그런건가 어셈까보면나옴?

[우물안개구리(lastpenguin)]

interlock 계열 함수들은 어셈수준에서 명령어 하나고, 원자성 보증

[공기역학(experimenter)]

오....

[우물안개구리(lastpenguin)]

그리고 이 경우는 프로파일링 하면서 맞춰서 락 만들고 그런거임

[우물안개구리(lastpenguin)]

혹시 소스 보고 그런거면 거기 용어 진지하게 그대러 받아들임안댐, 절반은 술코딩하면서 내맘대러 정의함

[공기역학(experimenter)]

ㅇㅋ ㅋㅋ

[우물안개구리(lastpenguin)]

그런데 LFH랑 성능으로 비빌려면 구현이 간단치는 않음 멀티스레드 사용전제로 해야하고, 성능이 우선이라고 부가적으로 소모되는 메모리 마구 낭비할 수도 없음

[ㅇㅅㅇa(218.234)]

너도 현업이야? 역시 현업은 무서운 애들이 많네

[공기역학(experimenter)]

[우물안개구리(lastpenguin)]

진지하게 메모리풀 적용하려고 하면 언제 시간날때 내꺼도 한번 돌려봐 주면 고맙겠음,, 적용이 어렵지는 않을 것임... allocator 상속하거나 new delete define 해서 함 대니까

[공기역학(experimenter)]

[우물안개구리(lastpenguin)]

그리고 사족으로 메모리풀에서 가상메모리를 뱉잖앙, 그런데 실제 주소가 물리적메모리에 연결되는건 그 주소를 읽거나 쓸때인데, 내기억으로 한번에 처리단위가 4kb 인가 64kb인가 그럼, 그런데 이게 메모리풀이 new 요청시 주소를 하나 퉤 뱉는거보다 오래걸림. 그래서 메모리 오브젝트 단위를 연결리스트 형식으로 메모리풀 구현하면 망하는거거고.

[우물안개구리(lastpenguin)]

그래서 비교 성능테스트할때는 받은 주소를 건드려야 공정한 것임. 메모리풀의 반응속도도 중요하지만, 어떤종류의 메모리풀은 는 더많은 주소들이 실제 메모리에 연결하는(상대적으로 오래걸리는) 작업을 더 많이해서 반응이 느려도 사용하는 과정까지 합치면 비슷할수도 있지

[공기역학(experimenter)]

64KB일거임 VirtualAlloc 2번째인자 단위 보면 ㅇㅇ 연결리스트 형식은 캐시미스문제 아님? 크기는 내부적으로 더 할당해두던가 할거같은데

[우물안개구리(lastpenguin)]

아 그렇게 말하니 기억난당, virtualalloc 예약 단위가 64kb 실제 할당이 4kb

[우물안개구리(lastpenguin)]

virtualalloc 에서 예약&커밋 다해도, 진짜는 그 메모리에 뭔가를 첨 하려할때 오래걸림, 이때 실제 물리 메모리 링크하는 걸로 알고 있음

[공기역학(experimenter)]

거기까진 잘 몰겠네 예약 커밋 분리 가능하게 해놓고 그걸 연결하지 않을 필요가 있나 싶은데 나중에 함 봐봄 ㄳ

[우물안개구리(lastpenguin)]

만약에 메모리풀에서 거대한 메모리를 잽아두고 이걸 사용자가 원하는 유닛크기로 나눠 모두 연결리스트 형식을 취하면, 메모리풀 반응이 너무 늦어짐

[우물안개구리(lastpenguin)]

응 ㅃㅃ

[공기역학(experimenter)]

ㅃㅃ

[공기역학(experimenter)]

생각해보니까 예전에 걍 new 1GB같은거 했을때도 예약으로만 잡혀서 작업관리자에서 봤을때 램 사용량 안 증가하고 memset 0 조졌을때 쭉 증가한거랑 관련있는듯

[공기역학(experimenter)]

그럼 성능 증가시키려면 맨 처음 풀 생성할때 비용 증가시키던가 fifo 쓰면 되겠네 ㅇㅇ

[우물안개구리(lastpenguin)]

풀에서 일정사이즈 단위의 청크 관리할때, 주소를 starr, end, current 만 가지구 new 요청시 current 만 움직여 가며 주소 하나 뱉는거지, 이럼 페이지폴트 없이 반응빠름. delete 로 인한 반납시는 뒤죽박죽 ㅇ오니 어쩔수 연결리스트로 관리하고, 청크하나 원래대로 꽉차면 첨방식으로 가거나 os에 반납하거나. .

[우물안개구리(lastpenguin)]

이게 내가 고민끝에 한 최종 방식임

[우물안개구리(lastpenguin)]

이게 가장 성능에서 큰 비중인데 사용자가 쓸때 4kb만 페이지폴트일으키냐 아님 풀에서 엄청크게 할꺼냐 차이 , 메머리풀의 반응속도, 이거 말고 다음으러는 lock 의 비중이 큰데, 일단 싱글스레드에서만 써도 큼.. 그래서 TLS동원하고 임계구역 구역 잘 나누고 ...

[공기역학(experimenter)]

g_tls_index는 한번 설정되면 계속 고정인거같은데 sFN_TLS_Get은 항상 같은거 리턴하는거아님?? 자고 일어나서 다시 봐볼게요 ㅇㅅㅇ;;