지금 64비트가 빨라진게 맞냐 아니냐에 대해서 얘기가 많길래 아주 간단하게 정리해봤습니다
일단 결론부터 말하자면 빨라진게 맞지만,
64비트가 직접적인 요인이 된건 아닙니다.
이 문구는 던파 인겜에서 //ipm을 쳤을 때 나오는건데
불러온지 오래된 이미지를 메모리에서 삭제하는 기준을 표기해둔거라 보심됩니다.
위가 지금 64비트 퍼섭, 아래가 32비트 본섭
퍼섭은 불러온지 60초가 된 이미지를 "오래된 이미지"라 판정하고,
10초마다 이 "오래된 이미지"의 총 용량을 분석해서 1024MB이상 쌓이면 정리를 시작합니다.
본섭은 불러온지 5초가 된 이미지를 "오래된 이미지"라 판정하고,
7초마다 "오래된 이미지"의 총 용량을 분석해서 250MB이상 쌓이면 정리를 시작합니다.
즉 메모리를 비우는 주기가 굉장히 듬성듬성하게 바뀐것을 알 수 있습니다.
이게 64비트랑 무슨 상관이냐? 라고 묻는다면
일단 많은 사람들이 알다시피 32비트 프로그램은 최대 4GB의 메모리를 사용할 수 있지만,
64비트는 사실상 무제한에 가깝게 쓸 수 있죠
던파 클라를 64비트로 전환할 때 개발자들이 메모리 제한을 풀었을텐데
프로그래밍 코드에 "메모리 제한 해제" 이런 직접적인 개념의 코드는 없어요
위에서 본 것처럼 일정 주기마다 메모리를 비우는 "가비지 컬렉션" 개념의 코드를 짜서 메모리가 설계한 메모리 사용량 안에서 굴러가게 만드는 것이 중요
32비트의 조건인 4기가 이하 메모리 사용을 위해서 5초가 지난 이미지를 지워야 했다면,
64비트로 가면서 메모리가 무제한으로 풀리니깐, 사실상 메모리 누수를 막는 수준인 60초로 바꾼거에요
이걸 실제로 자바로 구현해봤습니다
자바는 구동할때 이렇게 임의로 메모리 제한을 걸 수 있습니다
지금 입력값은 10GB로, 사실상 거의 무제한으로 풀어놓은 상태
이 상태로 지금 제작중인 계산기 자바 버전에 모든 에픽을 다 꼴아박고
세트 리스트 만들기 코드를 굴려봤습니다
자바 메모리 사용량이 3.6기가까지 올라갔지만 여튼 잘 굴러갔습니다
걸린 시간은 위 이미지 최하단에 표기된 것 처럼 14.2초정도 걸렸고요
그렇다면 이 메모리 제한을 1GB로 제한하고 굴린다면?
메모리 사용량은 대충 1기가에서 유지되고 있는걸 볼 수 있고
이게 당연한 얘기지만 똑같은 코드에 똑같은 요구사항을 넣었는데
1/4의 메모리만 사용하면서 똑같은 결과를 뽑을리는 없죠
즉, 위 던파의 예시처럼 자바의 메모리 관리 프로그램이 사용하지 않는 메모리를 최적화 하고 있는것
하지만 이 상태로 3분 넘게 있다가 결국 팅겼습니다
OutOfMemory 에러, 즉 메모리 에러고
뒤에 GC 리미트 뭐시기하는데 GC가 바로 메모리 최적화 기능인 가비지 컬렉터를 얘기하는 것
아무리 메모리 최적화 기능이 있어도 완벽하진 않기 때문에 이렇게 팅깁니다.
32비트 클라에 암만 메모리 최적화를 때려박아도 팅기는 이유가 바로 이것
이번엔 메모리 에러가 나지 않는 최소한의 제한만 주고 돌려봤습니다
대충 1.2기가정도 주니깐 에러는 안나오는데
대신 경과 시간이 14초에서 44초로 3배나 오래 걸렸습니다
메모리가 찰 때마다 계~~~속해서 비워줘야 하기 때문에
당연한 얘기지만 시간이 오래걸릴수밖에 없습니다
이게 던파가 지금 프레임이 빨라진 이유라 봅니다
정리하자면,
지금 던파가 32>64비트로 가면서
1. 사용 가능 메모리 제한이 풀려서 팅이 줄었고
2. 메모리 최적화 기능을 빡세게 굴릴 필요가 없어졌고
3. 그래서 최적화를 덜 할 수 있으니 그만큼 속도가 빨라졌고
4. 대신 메모리 사용량이 굉장히 늘어난것
새로고침