나는 항상 "미세 최적화"라는 용어가 다소 모호하다는 것을 알았습니다. 메모리 레이아웃 및 액세스 패턴에 대한 일부 명령어 수준의 변경이 알고리즘 복잡성을 줄이지 않고 핫스팟을 측정하는 전문 기술자로부터 80 배 빠른 결과를 얻는다면 "미세 최적화"입니까? 저에게는 이것이 실제 사용 사례에서 80 배 더 빠른 것을 만드는 "매우 최적화"입니다. 사람들은 그러한 최적화가 미세한 영향을 미치는 것과 같은 것들에 대해 이야기하는 경향이 있습니다.
나는 더 이상 gamedev에서 일하고 있지 않지만 경로 추적과 같은 영역에서 VFX에서 일하고 있으며 복잡한 장면에서 초당 약 5 천만 광선을 처리하는 BVH 및 KD 트리의 많은 구현을 보았습니다. 다중 스레드 평가). 대략 말하면, 다중 스레드 평가에서도 백만 광선 / 초 미만의 광선 추적 컨텍스트에서 BVH를 간단하게 구현하는 경향이 있습니다. Embree를 제외하고는 같은 하드웨어에서 동일한 장면에서 1 억 개 이상의 광선을 처리 할 수있는 BVH가 있습니다.
이는 전적으로 Embree가 200 배 더 빠른 "미세 최적화"(동일한 알고리즘 및 데이터 구조) 때문입니다. 물론 훨씬 더 빠른 이유는 인텔의 개발자가 프로파일 러와 측정에 의존하는 전문가이기 때문입니다. 중요한 부분을 조정했습니다. 그들은 코드를 변경하지 않았고 유지 보수성을 크게 저하시키는 비용으로 0.000000001 % 개선 된 변경 사항을 커밋하지 않았습니다. 이것들은 신중한 손에 적용되는 매우 정확한 최적화였습니다. 초점면에서는 미세하지만 효과면에서는 거시적 일 수 있습니다.
게임 엔진으로 작업하는 상위 수준 또는 하위 수준에 따라 게임의 실시간 프레임 속도 요구 사항이 자연 스럽습니다 (UE 4로 만든 게임조차도 종종 고급 스크립트에서 적어도 부분적으로 구현 됨 (물리 엔진의 가장 중요한 부분은 아니지만) 미세 최적화는 특정 영역에서 실제 요구 사항이됩니다.
매일 우리를 둘러싸고있는 또 하나의 매우 기본적인 영역은 고해상도 이미지를 실시간으로 흐리게 처리하고 어쩌면 우리가 어딘가에서 보았던 전환의 일환으로 OS 효과와 같은 다른 효과를 수행하는 것과 같은 이미지 처리입니다. 이미지의 모든 픽셀을 처음부터 반복하여 이러한 이미지 작업을 구현할 필요는 없으며 일치하는 프레임 속도에서 이러한 실시간 결과를 기대할 수 있습니다. CPU 인 경우 일반적으로 SIMD와 일부 미세 조정을보고 있거나 효과적으로 작성하려면 마이크로 수준의 사고 방식이 필요한 GPU 쉐이더를보고 있습니다.
그렇다면 하드웨어가 향상됨에 따라 더 높은 수준의 언어가 게임 산업을 인수 할 것으로 기대해야합니까?
하드웨어가 발전함에 따라 지침과 기술 (예 : GPU의 물리학), 기술, 고객이보고 싶은 것에 대한 고객의 기대, 경쟁에서 웹 개발자가 이제 WebGL에서 저수준 GLSL 셰이더를 작성하는 경우에도 개발자가 저수준으로 다시가는 방법 (이 특정 종류의 웹 개발은 10 년 또는 2 년 전보다 훨씬 낮은 수준임) GLSL은 매우 저수준의 C와 같은 언어이므로 일부 웹 개발자는 저수준 GPU 쉐이더 작성을 받아 들일 것이라고 생각한 적이 있습니다.
성능이 중요한 영역을보다 높은 수준의 언어로 전환 할 수있는 방법이 있다면 필자가 볼 수있는 소프트웨어와 컴파일러 및 도구에서 더 많은 것을 가져와야합니다. 가까운 미래에 나에게 문제는 하드웨어가 충분히 강력하지 않다는 것입니다. 그것은 우리의 언어로 다시 돌아 가지 않고 변화하고 발전 할 때마다 가장 효과적으로 대화 할 수있는 방법을 찾지 못하는 방법과 더 관련이 있습니다. 가상 하드웨어가 변화하는 속도는 빠른 속도입니다. 왜냐하면 가상 하드웨어가 다음 수십 년 동안 파란 색으로 진전을 멈추었 기 때문입니다.
유감스럽게도 요즘에는 성능이 중요한 영역에서 일할 때 Borland Turbo C DOS 시대에 시작했지만 시작보다 다소 저수준으로 생각해야합니다. 당시에는 CPU 캐시가 거의 존재하지 않았기 때문입니다. 주로 DRAM과 레지스터 였기 때문에 알고리즘 복잡성에 더 집중하고 성능에 큰 영향을 미치지 않고 트리와 같은 링크 된 구조를 매우 간단하게 작성할 수있었습니다. 요즘 CPU 캐시의 하위 수준 세부 사항은 알고리즘 자체만큼이나 내 생각을 지배합니다. 마찬가지로 멀티 스레딩 및 원자 및 뮤텍스, 스레드 안전 및 동시 데이터 구조 등을 생각 해야하는 멀티 코어 머신도 있습니다. 내가 시작했을 때보 다 인간적으로 직관적이지 않습니다.
이상하게도 그것은 지금 나에게 매우 진실 해 보인다. 나는 30 년 전보다 오늘날 하드웨어의 기본 및 저수준 복잡성과 세부 사항에 더 많은 영향을 받고 향수 안경을 벗기 위해 최선을 다하고 있다고 생각합니다. 물론 우리는 여기서 약간의 어셈블리에 대해 이야기하고 XMS / EMS와 같은 까다로운 세부 사항을 처리해야 할 수도 있습니다. 그러나 대부분의 경우 필자는 성능이 중요한 영역에서 작업 할 때 오늘날보다 복잡성과 하드웨어 및 컴파일러 인식이 덜 필요하다고 말했습니다. 우리가 글쓰기처럼 제쳐두면 업계 전체에서 거의 사실로 보입니다.if/else 좀 더 사람이 읽을 수있는 방식으로 진술하고 요즘 일반적인 사람들이 하드웨어의 하위 수준 세부 사항 (여러 코어에서 GPU, SIMD, CPU 캐시 및 컴파일러 / 통역사 / 도서관은 작동합니다).
높은 수준! = 덜 효율적
이 질문으로 돌아 가기 :
그렇다면 하드웨어가 향상됨에 따라 더 높은 수준의 언어가 게임 산업을 인수 할 것으로 기대해야합니까?
나에게 그것은 하드웨어에 관한 것이 아닙니다. 최적화 도구와 도구에 관한 것입니다. 내가 시작했을 때 사람들은 실제로 모든 콘솔 게임을 어셈블리로 작성했으며, 특히 6502를 생성하는 고품질 컴파일러가 없기 때문에 진정한 성능 이점이있었습니다.
C 컴파일러 최적화가 최적화에서 더 똑똑 해짐에 따라 C로 작성된 고급 코드가 다른 분야에서 최고의 어셈블리 전문가가 작성한 코드를 능가하는 수준에 도달하기 시작했습니다 (항상 그런 것은 아님). 그것은 게임을위한 최소한의 코딩을 위해 C를 채택하는 것은 쉬운 일이 아니 었습니다. 그리고 C ++에서도 비슷한 변화가 점차 발생했습니다. 어셈블리에서 C 로의 생산성 향상은 C에서 C ++로가는 것이 아니라 ASM에서 완전히 사소한 게임을 작성하는 게임 개발자의 만장일치 동의에 도달 할 수 있다고 생각했기 때문에 C ++ 채택이 느려졌습니다.
그러나 이러한 변화는 이러한 언어에 대한 옵티마이 저가 크게 (낮은 것은 아니지만 항상 모호한 경우가 있지만) 더 이상 사용되지 않도록 하드웨어가 더 강력 해지지는 않았습니다.
멀티 스레딩이나 GPU, 캐시 미스 또는 그와 같은 것 (특정 데이터 구조는 아닐 수도 있음)에 대한 염려없이 상상할 수있는 최상위 코드로 코드를 작성할 수있는 가상 시나리오를 상상할 수 있다면 옵티마이 저는 인공 지능과 같습니다. 스마트하고 가장 효율적인 메모리 레이아웃을 파악하여 데이터를 정리하고 압축하고, 여기저기서 GPU를 사용할 수 있고, 여기저기서 일부 코드를 병렬화하고, SIMD를 사용하고, 프로파일 링하고 IR을 계속 최적화 할 수 있습니다. 프로파일 러 핫스팟에 응답하면 세계 최고의 전문가를 능가하는 방식으로 성능이 가장 중요한 분야에서 일하는 사람들조차도 그것을 채택하는 것은 쉬운 일이 아닙니다 ... 그리고 그것은 진보입니다. 더 빠른 하드웨어가 아니라 엄청나게 똑똑한 옵티 마이저에서 나옵니다.