mojang_tommo: It measures the frame time, thus 30 is higher because 1/30 > 1/60 :)
Fps is a bad measure of performance anyway.
Tommaso Checchi: 이건 프레임 시간을 재는 겁니다. 1/30이 1/60보다 크니 30이 더 위에 있는 겁니다.
FPS는 성능을 측정하는 데엔 나쁜 방법은 입니다만.
01. 성능 개선
_Grum: <전략> I've been working this week on optimizing the quad-sorting and eventhough I couldn't really notice the problem on my system until it made a 'worst case chunk' and forced it to update every single change in my position (normally it would update after a block worth of movement). I managed to reduce the impact massively.
When it makes it into the next version you can test that, maybe you will fare better.
Erik Broes: 저는 이번 주에 쿼드 소팅을 최적화하고 있었습니다. '최악의 경우의 청크'를 만들고 제 위치가 변할 때 마다 강제로 업데이트하게 만들기 전에는 (원래는 한 블록 거리를 움직여야 업데이트 됨) 제 시스템에서는 문제를 찾을 수 없었습니다. 저는 그 영향을 크게 줄였습니다.
Dinnerbone: For the next pre, I've changed some video options around. Clouds is now "on/fast/fancy" and there's a new option for entity shadows "on/off"
Nathan Adams: 다음 프리릴리즈에서, 저는 몇 비디오 설정을 바꿨습니다. 구름은 이제 "on/fast/fancy", 그리고 독립체 그림자를 "on/off"하는 새 설정이 있습니다.
Dinnerbone: Uhh, make that "clouds: off/fast/fancy"...
Nathan Adams: 어어... 아까 거기서 "구름: off/fast/fancy"로...
Dinnerbone: The fast/fancy graphics button now only controls leaves transparency and rain particles.
Nathan Adams: 빠르게/화려하게 버튼은 이제 잎의 투명함과 비 파티클만 조종합니다.
03. 설정에 관계 없이 아이템이 3D로 렌더링되게 됨
Dinnerbone: All items now rotate. It was not intentional that they just sit there on fast!
Nathan Adams: 모든 아이템이 이제 돌아갑니다. 빠르게 모드에서 아이템이 가만히 있던 것은 의도한 게 아니었습니다!
04. 버그 수정
- 주민과 거래할 때 이름이 바뀐 아이템을 보통 아이템처럼 취급하는 문제 수정
- 모루 GUI에서 긴 이름을 가진 아이템을 넣으면 마지막 글자가 파란 박스로 바뀌어 보이는 문제 수정
- /summon 할때 Rotation 태그가 먹히지 않는 문제 수정
- F5 키를 누를 때 카메라에 담기지 않던 청크 조각들은 마우스를 움직이기 전까지 보이지 않는 문제 수정
- /execute로 detect를 쓸 때 대상이 다른 차원에 있으면 가짜 좌표를 사용하는 버그 수정
- "짜증나는 버그" 수정
SeargeDP: I think I fixed an annoying bug today. Feels good to finally figure out what the problem was. More details after the update is released.
Searge: 제가 오늘 짜증나는 버그를 고친 것 같습니다. 무엇이 문제였는지 알고 나니 좋은 느낌입니다. 업데이트가 나오고 더 자세히 이야기하겠습니다.
- 서버에서 플레이어가 복제되는 버그 수정
xisumavoid: Found a very easy way to duplicate items on a vanilla server. Needs to be patched
Dinnerbone: Is it duplicating logs by planting saplings?
xisumavoid: Its a way to kill yourself and duplicate all your own items.
Dinnerbone: Yeah that's already fixed for next pre, don't worry!
xisumavoid: 바닐라[각주:2] 서버에서 아이템을 복제하는 정말 쉬운 방법을 발견했습니다. 패치되야합니다
Nathan Adams: 묘목을 심어서 나무를 복제하는 건가요?
xisumavoid: 자기 자신을 죽여서 가지고 있던 아이템을 모두 복제하는 겁니다.
Nathan Adams: 예, 그건 이미 다음 프리릴리즈에서 고쳐졌습니다. 걱정마세요!
이번에 Optifine에 기부를 했습니다.
라기 보다는 그냥 망토를 산 것에 더 가깝겠죠. 서버가 아니니까 문제되지 않을걸
Optifine이 꽤나 필수 모드로 인식되기에, (그럴일이 있겠냐만) 멀티에 정말로 가게 된다면 좋은 룩딸이 되겠다 생각했습니다.
Minecraft 1.8 has so many performance problems that I just don't know where to start with.
마인크래프트 1.8에는 너무 많은 성능 문제가 있어서, 그냥 어디서 시작해야할 지 모르겠습니다.
Maybe the biggest and the ugliest problem is the memory allocation. Currently the game allocates (and throws away immediately) 50 MB/sec when standing still and up to 200 MB/sec when moving. That is just crazy.
아마 가장 크고 흉측한 문제는 메모리 할당일겁니다. 현제 게임이 할당하는 (그리고 바로 버리는) 메모리는, 가만히 서있을 때 초당 50MB에서 움직일 때 초당 200MB까지 올라갑니다. 이건 그냥 미친 겁니다.
What happens when the game allocates 200 MB memory every second and discards them immediately?
게임이 매초 200MB 메모리를 할당하고 바로 버려버리면 어떤 일이 벌어질까요?
1. With a default memory limit of 1GB (1000 MB) and working memory of about 200 MB Java has to make a full garbage collection every 4 seconds otherwise it would run out of memory. When running with 60 fps, one frame takes about 16 ms. In order not to be noticeable, the garbage collection should run in 10-15 ms maximum. In this minimal time it has to decide which of the several hundred thausand newly generated objects are garbage and can be discarded and which are not. This is a huge amount of work and it needs a very powerful CPU in order to finish in 10 ms.
1. 기본 메모리 한계인 1GB (1000MB)와 200MB의 작동 메모리가 있다면, Java에서는 매 4초마다 쓰레기 수집Garbage Collection을 하지 않으면 메모리가 부족해지게 됩니다. 60FPS로 작동될 때, 한 프레임당 약 16ms<밀리초, 1/1000초>정도 걸리게 됩니다. 쓰레기 수집이 거슬리지 않게 되려면, 이 작업을 적어도 10-15ms 안에 끝내야 합니다. 이런 적은 시간에 Java는 수백 수천개의 새로 생긴 오브젝트 중, 무엇이 쓰레기이며 버릴 수 있고 무엇이 버리면 안 되는 건지 정해야 합니다. 이는 정말 많은 작업이고 이를 10ms 안에 끝내려면 매우 뛰어난 CPU가 필요합니다.
2. Why not give it more memory?
Let's give Minecraft 4 GB of RAM to play with. This would need a PC with at least 8 GB RAM (as the real memory usage is almost double the memory visible in Java). If the VM decides to use all the memory, then it will increase the time between the garbage collections (20 sec instead of 4), but it will also increase the garbage collection time by 4, so every 20 seconds there will be one massive lag spike.
2. 더 많은 메모리를 할당하면 안되나요?
마인크래프트에게 4GB의 RAM을 줘 봅시다. 이는 적어도 8GB 이상의 RAM이 있는 PC가 필요합니다. (실제 메모리 사용은 Java에서 보이는 것의 거의 두배에 가깝기 때문) 만약 Java 가상머신이 모든 메모리를 사용하기로 한다면, 쓰레기 수집하는 시간 간격이 (4초에서 20초로) 늘어나겠지만, 이는 또한 쓰레기 수집하는 시간도 4배로 늘리게 됩니다. 그래서 매 20초마다 심한 랙이 나타나게 됩니다.
3. Why not use incremental garbage collection?
The latest version of the launcher by default enables incremental garbage collection (-XX:+CMSIncrementalMode) which in theory should replace the one big GC with many shorter incremental GCs. However the problem is that the time at which the smaller GCs happen and their duration are mostly random. Also they are not much shorter (maybe 50%) than a full scale GC. That means that the FPS starts to fluctuate up and down and there are a lot of random lag spikes. The stable FPS with a lag spike from time to time is replaced with unstable FPS and microstutter (or not very micro depending on the CPU). This strategy can only work with a powerful enough CPU so that the random lag spikes become small enough not to be noticeable.
3. Incremental Garbage Collection을 사용하면 안 되나요? <Incremental Garbage Collection은 조금씩 쓰레기 수집을 하는 방식. 출처>
최신 런처에서는 증분 쓰레기 수집이 기본으로 켜져 있는데 (-XX:+CMSIncrementalMode), 이는 이론상으로는 한번의 커다란 쓰레기 수집<이제부터 GC로 축약>을 여러번의 더 짧은 증분 GC로 대체합니다. 하지만 문제는 이 더 작은 GC가 생기는 타이밍과 걸리는 시간이 거의 무작위라는 겁니다. 게다가 이것들은 원래 커다란 GC보다 그렇게 작지 않습니다 (아마 50% 정도). 즉 FPS가 올라갔다 내려갔다 변동하기 시작하고 수많은 랙이 발생하게 됩니다. 안정적인 FPS에 가끔씩 터지는 심한 랙이, 불안정한 FPS에 작은 (CPU에 따라 그리 작지는 않은) 끊김으로 대체되는 겁니다. 이 전략은 이런 끊김이 알아채지 못하게 짧아지게 해주는, 충분히 강력한 CPU가 있어야만 작동합니다.
4. How did that work in previous releases?
The previous Minecraft releases were much less memory hungry. The original Notch code (pre 1.3) was allocating about 10-20 MB/sec which was much more easy to control and optimize. The rendering itself needed only 1-2 MB/sec and was designed to minimize memory waste (reusing buffers, etc). The 200 MB/sec is pushing the limits and forcing the garbage collector to do a lot of work which takes time. If it was possible to control how and when the GC works then maybe it would be possible to distribute the GC pauses such that they are not noticeable or less disturbing. However there is no such control in the current Java VM.
4. 이게 이전 버전에서는 어떻게 먹혔나요?
이전 마인크래프트 버전은 메모리를 훨씬 덜 잡아먹었습니다. 원본 Notch의 코드(1.3 이전)는 초당 10-20MB의 메모리를 할당해서, 훨씬 관리와 최적화가 쉬웠습니다. 렌더링 그 자체는 초당 1-2MB밖에 안 필요했고, 메모리 낭비를 최소화하도록 디자인되었습니다 (버퍼 재사용 등). 초당 200MB의 메모리 할당은 GC의 한계까지 몰아넣습니다. 만약 GC가 어떻게, 그리고 언제 작동하는지 조종할 수 있다면 이것듯이 덜 눈에 띄게나 덜 거슬리게 만들 수 있을 지 모릅니다. 하지만 현재 Java 가상머신에서는 그런 걸 관리할 수 없습니다.
5. Why is 1.8 allocating so much memory?
This is the best part - over 90% of the memory allocation is not needed at all. Most of the memory is probably allocated to make the life of the developers easier.
- There are huge amounts of objects which are allocated and discarded milliseconds later.
- All internal methods which used parameters (x, y, z) are now converted to one parameter (BlockPos) which is immutable. So if you need to check another position around the current one you have to allocate a new BlockPos or invent some object cache which will probaby be slower. This alone is a huge memory waste.
- The chunk loading is allocating a lot of memory just to pass vertex data around. The excuse is probably "mutithreading", however this is not necessary at all (see the last OptiFine for 1.7).
- the list goes on and on ...
5. 왜 1.8이 이렇게 많은 메모리를 쓰나요?
이게 가장 대단한 부분입니다 - 메모리 할당 중 90%가 넘는 부분은 전혀 필요하지 않습니다. 대부분의 메모리는 아마 개발자의 삶을 더 쉽게 만들기 위해 할당된 걸 겁니다.
- 할당되었다가 몇 ms 뒤 바로 버려지는 수많은 오브젝트가 있습니다.
- 여러 매개변수들(x, y, z)을 사용한 기존 메소드들이 변하지 않는 하나의 매개변수(BlockPos)를 사용하는 것으로 모두 변경되었습니다. 그래서 현재 위치 주위의 또다른 위치를 확인할 때, 새 BlockPos를 할당하거나 (더 느려지겠지만) 무슨 오브젝트 캐시 같은 걸 새로 만들어야 합니다. 이것만으로도 커다란 메모리 낭비입니다.
- 청크 로딩은 점 데이타만 전달하는데에만 엄청난 메모리를 할당하고 있습니다. "멀티쓰레드"로 변명할 수 있는지 모르겠지만, 이것은 전혀 필요한게 아닙니다. (1.7 버전 최신 Optifine을 보세요)
- 이 목록은 이렇게 계속됩니다...
The general trend is that the developers do not care that much about memory allocation and use "best industry practices" without understanding the consequences. The standard reasoning being "immutables are good", "allocating new memory is faster than caching", "the garbage collector is so good these days" and so on.
요즘 유행은 개발자가 메모리 할당에 대해 별 신경쓰지 않고 결과를 이해하지 않은 채 "최고의 산업 관례"를 사용하는 겁니다. 기준 추리는 바로 "변하지 않는immutable 변수는 좋다", "새 메모리를 할당하는 건 캐싱하는 것 보다 더 빠르다", "요즘 GC는 너무 좋다" 등등 같은 겁니다.
Allocating new memory is really faster than caching (Java is even faster than C++ when it comes to dynamic memory), but getting rid of the allocated memory is not faster and it is not predictable at all. Minecraft is a "real-time" application and to get a stable framerate it needs either minimal runtime memory allocation (pre 1.3) or controllable garbage collecting, which is just not possible with the current Java VM.
실제로 새 메모리를 할당하는 건 캐싱하는 것보다 더 빠릅니다 (Java는 동적 메모리에 대해선 C++보다 더 빠릅니다). 하지만 할당된 메모리를 버리는 건 더 빠르지 않고 전혀 예상할 수 없습니다. 마인크래프트는 "실시간Real-Time" 응용프로그램이고, 안정적인 프레임률을 가지려면 최소한의 런타임 메모리 할당을 갖거나(1.3 이전), 관리할 수 있는 GC를 써야합니다 (현재 Java 가상머신에서는 불가능).
6. What can be done to fix it?
If there are 2 or 3 places which are wasting memory (bugs), then OptiFine can fix them individually. Otherwise a bigger refactoring of the Minecraft internals will be needed, which is a huge task and not possible for OptiFine.
6. 고치려면 뭘 할 수 있을까요?
만약 2-3곳에서 메모리 낭비(버그들)가 있다면 OptiFine에서 그것들을 각각 고칠 수 있습니다. 아니라면 마인크래프트 내부를 뜯어고쳐야하는데, 이는 커다란 작업이고 OptiFine으로는 할 수 없는 일입니다.
7. Example
A sample log of GC activity with effective FPS for the GC lag spikes is available here.
- the average rendering FPS is about 50 FPS
- the GC lag spikes have effective FPS of 7-20
- there are 1-2 lag spikes per second caused by GC activity
7. 예시
GC로 인한 랙을 보여주기 위한 GC 활동과 FPS에 대한 영향 로그 샘플을 보시려면 여기로.
- 평균 렌더링 FPS는 약 50 FPS
- GC 랙으로 7-20 FPS정도가 떨어짐
- 초당 1-2개의 랙이 GC 계산으로부터 발생
tldr; When 1.8 is lagging and stuttering the garbage collector is working like crazy and is doing work which has nothing to do with the game itself (rendering, running the internal server, loading chunks, etc). Instead it is constantly cleaning the mess behind the code which thinks that memory allocation is "cheap".
요약; 1.8 버전이 랙이 걸리고 끊기는 건 쓰레기 수집이 어마어마한 작업을 하고 있기 때문이고, 이는 게임 자체 (렌더링, 내부 서버 실행, 청크 로딩 등)와 전혀 무관한 작업입니다. 메모리 할당이 "싸다"고 생각하는 코드가 벌여둔 난장판을, 쓰레기 수집이 계속 치워줘야 합니다.
