동일한 아키텍처의 새로운 프로세서에 대해 엔진을 최적화해야하는 이유는 무엇입니까?

새로운 프로세서 세대가 출시되면 대부분의 웹 사이트에서 게임 엔진과 프로그램을 새 하드웨어에 맞게 최적화해야한다고보고합니다. 왜 그런지 잘 모르겠습니다. 프로세서에는 일반적으로 어떤 종류의 명령어 세트를 사용하는지 정의하는 아키텍처가 있습니다. 오늘날 우리 모두가 사용하는 것은 amd_x86_64입니다. 모든 프로세서가 동일한 아키텍처를 사용하는 경우 프로그램이나 컴파일러를 업데이트해야하는 이유는 무엇입니까? 머신 코드 실행을 최적화하는 새로운 프로세서의 파이프 라인에는 분명히 기능이 있지만 아키텍처가 변경되지 않은 경우 머신 코드 자체를 변경해야하는 이유는 무엇입니까?

hardware cpu

— 살 베이라
소스

의견은 긴 토론을위한 것이 아닙니다. 이 대화는 채팅 으로 이동 되었습니다 .

— Josh

"필요"는 잘못된 말과 진실보다 마케팅입니다. 예를 들어, Windows 가 특정 새로운 CPU 생성을 지원 해야 하거나 Windows 7의 경우와 달리 원칙적으로 완벽하게 작동 하는 것과 같은 방식 입니다. 필요 이상으로 3-4 % 더 많은 전력을 사용하는 것을 제외하고는 Ryzen과 함께 사용할 수 있습니다. 이 튜닝은 CPU에서 조금 더 꽉 쥐고 최대 값에 가까워 지려고합니다. 실제로 일정이 다르고 몇 가지 새로운 명령을 사용하여 검색되지 않은 예에서 전체 1-2 %를 얻을 수 있습니다.

— 데이먼

두 프로세서가 동일한 작업을 수행 할 수 있다고해서 두 프로세서에서 동일한 성능을 갖는 것은 아닙니다.

— Mehrdad

Stack Overflow : mtune은 실제로 어떻게 작동합니까?

— Marc.2377

답변:

동일한 아키텍처의 다른 세대 가 다른 명령어 세트를 가질 수 있기 때문 입니다.

예를 들어, 스트리밍 SIMD 확장 은 아마도 가장 잘 알려진 x86 명령어 세트 일 것입니다. 그러나 아직 하나의 x86 아키텍처에도 불구하고 SSE, SSE2, SSE3 및 SSE4가 있습니다.

이러한 각 세대에는 특정 작업을보다 빠르게 수행 할 수있는 새로운 명령이 포함될 수 있습니다. 게임과 관련된 예는 내적 제품 지침 일 수 있습니다.

따라서 게임 엔진이 이전 세대의 아키텍처 용으로 컴파일 된 경우이 새로운 지침을 지원하지 않습니다. 마찬가지로 최신 지침에 맞게 엔진을 최적화해야 할 수도 있습니다. 예를 들어 SSE4 는 배열 데이터를 처리하는 내적 (dot) 제품 명령어를 지원합니다. 이 새로운 지침을 활용할 수있는 최적화는 데이터 레이아웃을 배열로 변경하는 것입니다.

— 막시무스 미니 무스
소스

@ Panzercrisis-편집 제안에 감사드립니다. 분명히 : 원래 질문은 자신의 코드가 아니라 엔진 코드에 관한 것이기 때문에 "자신의 코드를 최적화하십시오"는 좋은 편집 제안이 아닙니다. 그러나 "최적화"라고 말했을 때 나는 "엔진 코드 최적화"를 의미한다는 것을 분명히해야한다는 것을 강조 했으므로 그것을 채택하도록 편집했습니다.

— Maximus Minimus

막시무스의 대답은 정확합니다. 다른 이야기를 드리겠습니다.

하드웨어는 새로 도입 된 지침에 관계없이 코딩 방식을 변경해야하는 방식으로 변경됩니다.

캐시 양을 늘리거나 줄이면 캐시 최적화 / 캐시 무효화 문제에 대해 걱정할 필요가 없습니다. 캐시가 많을수록 작은 데이터로 인해 성능 문제가 발생하지 않고 데이터가 연속되도록하는 데 집중할 수 있습니다. 캐시가 적다는 것은 이것이 문제가 될 수 있음을 의미하며, 캐시가 매우 적다는 것은 데이터 구조가 크면 중요하지 않습니다.
새로운 수준의 캐시는 더 큰 데이터 세트 (L1, vs L2, vs L3 vs L4)를 구성하는 방법에 대해 더 많이 생각해야한다는 것을 의미합니다.
코어가 많을수록 멀티 스레드 응용 프로그램을 개선하는 방법과 멀티 프로세스 환경에서 응용 프로그램이 어떻게 확장되는지 생각해야합니다.
클럭이 빠르다는 것은 시스템의 병목 현상으로 CPU 계산 속도를 생각하는 것보다 메모리 대기 시간을 생각해야한다는 의미입니다.
시스템의 FPU 수는 더 이상 코어 당 정수 ALU 수와 더 이상 일치하지 않을 수 있습니다 (AMD에는 이와 같은 아키텍처가 있거나 있음).
연산을 계산하는 데 걸리는 클럭 사이클 수는 감소 또는 증가했습니다.
사용 가능한 레지스터 수가 변경되었습니다.

이들 모두는 동일한 ISA를 가진 이전 하드웨어의 기본 아키텍처에 대해 가정하거나 긍정적으로 평가 한 프로그램에 매우 실질적인 성능 영향을 미칩니다.

— opa
소스

"캐시 수준이 증가하거나 감소하면 캐시 일관성에 대해 걱정할 필요가 없습니다."-거의 모든 CPU가 캐시 일관성입니다. 허위 공유를 의미합니까? 거의 모든 CPU $ 라인보다 거의 항상 64 B ...

— Maciej Piechotka

Maciej는 캐시 일관성에 대한 진술을 방금 들었습니다. :) 아마도 "캐시 최적화"또는 무언가를 의미했을 것입니다. 캐시 일관성은 N 개의 독립적 인 캐시 가있는 경우에도 시스템이 메모리에 대해 일관된 메모리보기를 소프트웨어에 투명하게 유지할 수있는 기능입니다 . 이것은 크기와 완전히 직교합니다. TBH의 진술은 실제로는 관련이 없지만 귀하의 답변 (특히 5 및 6 포인트)은 허용되는 IMO보다 질문을 더 잘 해결합니다.

— 마가렛 블룸

"현대 인텔 및 AMD CPU에서 오늘날처럼 동일한 시간이 걸리는 곱셈은 더하기보다 더 많은 시간이 걸리는 것과 같습니다."사실이 아닙니다. 파이프 라인 아키텍처에서는 대기 시간 (결과가 준비 될 때)과 처리량 (사이클 당 할 수있는 횟수)을 구별해야합니다. 최신 인텔 프로세서의 처리량은 4이고 대기 시간은 1입니다. 곱하기 처리량 1과 대기 시간 3 (또는 4)이 있습니다. 이것들은 각 아키텍처에 따라 변경되고 최적화가 필요한 것들입니다. 예를 들어 pdep인텔에서는 1주기가 걸리고 Ryzen에서는 6주기가 걸리므로 Ryzen에서는 사용하지 않을 수 있습니다.

— Christoph

@Clearer 우리가 여기서 CPU에 대해 이야기하고 있다는 것을 알고 있지만 GPU에 대해 프로그래밍 한 적이 있습니까? 동일한 코드는 실제로 CUDA의 하드웨어 기능 을 고려하기 위해 실제로 수행해야하는 성능에서 매우 다른 결과를 생성합니다 . CUDA에서 무언가를 코딩하는 방법에서 캐시 크기 (공유 메모리, 관리되는 L1 캐시)를 실제로 고려해야합니다.

— opa

@ 크리스토프가 맞습니다. 연결하는 벤치 마크는 배열에 대한 루프 c[i] = a[i] OP b[i](즉, 작업 당 2 개의로드 및 1 개의 저장소)에 대한 것이므로 계산 강도가 매우 낮기 때문에 시간이 메모리 대역폭에 의해 지배됩니다. 배열 크기는 L1D에 맞으면 IDK로 표시되지 않습니다. (gcc4.9 -Ofast 루프를 자동 벡터화했을 가능성이 높으므로 복잡한 정수 코드의 일부로 일반 스칼라 연산 비용을 측정하지도 않습니다). 이 페이지의 첫 번째 줄은 중요합니다. 유용한 피드백에 따르면 이러한 조치 중 일부에 심각한 결함이 있음이 밝혀졌습니다. 주요 업데이트가 진행 중 입니다.

— Peter Cordes

새로운 명령어 지원과 같은 중대한 변화 외에도 마이크로 프로세서 제조업체는 성능을 개선하기 위해 지속적으로 설계를 수정하고 있으며, 모든 새로운 설계는 각 명령어 나 기술에 대해 서로 다른 상대 성능을 가질 수 있습니다 . 어쩌면 Model X에 대해 신중하게 최적화 된 분기없는 코드를 작성했을 수도 있지만 Model Y에는 분기없는 버전의 코드에 대한 잘못된 예측 페널티를 줄이는 개선 된 분기 예측기가 있습니다 (이는 다른 곳에서 사용할 수있는 레지스터를 해제합니다) . Model Y는 대기 시간이 긴 특정 명령어의 병렬 처리를 지원하므로 이제 해당 명령어의 언롤 된 루프로 처리량이 향상되고 Model X에서는 짧은 시퀀스가 더 좋습니다.

모든 문제는 여러 가지 방법으로 해결 될 수 있으며 모든 프로그램은 최적화 시점부터 상호 교환 및 리소스 할당 모음입니다. 해당 자원의 가용성이나 해당 자원의 관점에서 특정 코드 조각의 비용이 약간만 변경 되더라도 하나의 코드 또는 다른 코드에 실질적인 성능 이점을 제공하는 계단식 효과를 가질 수 있습니다. 업그레이드 된 칩 "더 모든 것을"경우에도, 얼마나 많은 더 각 물건의 균형을 스윙 할 수 있습니다.

— 홉스
소스