프로그램에 특정 최소 개수의 CPU 코어가 필요한 이유는 무엇입니까?

코어 수가 N 개 미만인 CPU에서 실행될 때 제대로 작동하지 않는 코드 (또는 코드가 아닌 완전한 소프트웨어)를 작성할 수 있습니까? 명시 적으로 확인 하지 않고 의도적으로 실패하지 않은 경우 :

IF (noOfCores <4) 그런 다음 의도적으로 제대로 실행되지 않습니다

게임의 ( Dragon Age : Inquisition ) 최소 시스템 요구 사항을보고 있으며 최소 4 코어 CPU가 나와 있습니다. 많은 플레이어들은 2 코어 CPU 와 2 개의 물리 코어와 2 개의 논리 코어가있는 인텔 코어 i3 에서 EVEN을 실행하지 않는다고 말합니다 . 그리고 그것은 컴퓨팅 능력의 문제가 아닙니다.

내 이해에서 스레드는 수행 할 수 없기 때문에 OS에 의해 CPU와 완전히 분리됩니다.

정리하기 :

나는 NOT "나는 코드에서 CPU 코어의 수를 발견하고 목적에 실패 할 수 있습니까?"질문 ... 그러한 코드는 의도하지 않은 것입니다 (계산 능력이 없어도 프로그램을 실행하기 위해 더 비싼 CPU를 사야합니다). 예를 들어 코드에 4 개의 스레드가 있고 두 개의 스레드가 동일한 물리적 코어에서 실행될 때 (시스템 정보를 명시 적으로 확인하지 않고 의도적으로 실패하지 않음) 요청 합니다.

요컨대, 여러 개의 코어에서 제공되는 추가 컴퓨팅 성능없이 여러 개의 코어가 필요한 소프트웨어가있을 수 있습니까? N 개의 별도 물리적 코어 만 있으면됩니다.

코어 친화력을 부주의하게 사용하여 "사고로"이 작업을 수행 할 수 있습니다. 다음 의사 코드를 고려하십시오.

• 실을 시작하다
• 해당 스레드에서 실행중인 코어를 찾으십시오.
• CPU 선호도를 해당 코어로 설정
• 계산 집약적 인 / 루프를 영원히 시작하십시오.

2 코어 CPU에서 4 개를 시작하면 코어 선호도 설정에 문제가 발생하거나 사용 가능한 코어를 호핑하는 2 개의 스레드와 예약되지 않은 2 개의 스레드가 생깁니다. 어느 시점에 총 몇 개의 코어가 있는지 명시 적으로 묻지 않았습니다.

(장기 실행 스레드가있는 경우 CPU 선호도를 설정하면 일반적으로 처리량이 향상됩니다)

게임 회사가 사람들에게 아무런 이유없이 더 비싼 하드웨어를 구매하도록 강요한다는 생각은 그다지 타당하지 않습니다. 고객 만 잃을 수 있습니다.

편집 : 이 게시물은 이제 33 upvotes를 얻었습니다 . 이것은 교육받은 추측을 기반으로한다는 점에서 상당히 많습니다!

그것은 사람들이 가지고 보인다 DA : 나는 듀얼 코어 시스템에서 심하게 실행하려면 http://www.dsogaming.com/pc-performance-analyses/dragon-age-inquisition-pc-performance-analysis/ 그 분석 하이퍼 스레딩이 켜져 있으면 상황이 크게 개선된다고 언급합니다. HT가 더 이상 명령어 발행 단위 나 캐시를 추가하지 않기 때문에 다른 스레드가 캐시 마구간에있는 동안 하나의 스레드 만 실행할 수 있기 때문에 순수하게 스레드 수에 연결되어 있음을 강력하게 제안합니다.

또 다른 포스터는 그래픽 드라이버를 변경하면 작동 주장 : http://answers.ea.com/t5/Dragon-Age-Inquisition/Working-solution-for-Intel-dual-core-CPUs/td-p/3994141 ; 그래픽 드라이버가 쓰레기와 악의의 비참한 경향이 있다는 것을 감안할 때, 이것은 놀라운 일이 아닙니다. 악명 높은 드라이버 중 하나는 "수정 및 느린"대 "빠른 및 잘못된"모드로 QUAKE.EXE에서 호출 된 경우 선택되었습니다. 드라이버는 명백한 CPU 수에 따라 다르게 동작 할 수 있습니다. 아마도 (추론으로 돌아 가기) 다른 동기화 메커니즘이 사용됩니다. 스핀 락 오용 ?

"잠금 및 동기화 기본 요소의 남용"은 매우 일반적인 버그 소스입니다. (이 글을 쓰는 동안 직장에서보고있는 버그는 "인쇄 작업이 완료 될 때 프린터 설정을 변경하면 충돌"입니다).

편집 2 : 의견은 스레드 기아를 피하려고 시도하는 OS를 언급합니다. 게임에는 스레드에 작업을 할당하기위한 자체 내부 준 Scheduler가있을 수 있으며 그래픽 카드 자체에도 유사한 메커니즘이 있습니다 (이것은 사실상 멀티 태스킹 시스템 임). 그중 하나의 버그 또는 그들 사이의 상호 작용이 매우 높습니다.

www.ecsl.cs.sunysb.edu/tr/ashok.pdf(2008)는 그래픽 카드의보다 나은 스케줄링에 대한 대학원 논문으로, 일반적으로 선착순 스케줄링을 사용한다고 명시되어 있습니다. 비 선점 시스템. 상황이 개선 되었습니까? 아마 아닙니다.

응용 프로그램이 병렬 스레드에서 4 개의 작업을 실행하고 거의 동시에 완료 될 것으로 기대하기 때문에 4 개의 코어가 필요할 수 있습니다.

모든 스레드가 별도의 코어에 의해 실행되고 모든 스레드가 동일한 계산 워크로드를 갖는 경우, 거의 같은 시간에 완료 될 가능성이 높습니다 (그러나 보장되지는 않음). 그러나 두 개의 스레드가 하나의 코어에서 실행될 때 코어가 항상 두 스레드간에 컨텍스트를 전환하므로 타이밍을 예측하기가 훨씬 어려워집니다.

예기치 않은 스레드 타이밍으로 인해 발생하는 버그를 " 경합 조건 "이라고합니다.

게임 개발의 맥락에서, 이런 종류의 문제를 가진 하나의 그럴듯한 아키텍처는 다른 CPU 스레드에 의해 게임의 다른 기능이 실시간으로 시뮬레이션되는 아키텍처 일 수 있습니다. 각 기능이 자체 코어에서 실행되는 경우 거의 동일한 속도로 시뮬레이션됩니다. 그러나 두 가지 기능이 하나의 코어에서 실행되면 두 가지 기능이 나머지 게임 세계의 절반만큼만 시뮬레이션되므로 모든 종류의 이상한 동작이 발생할 수 있습니다.

특정 타이밍으로 실행되는 독립 스레드에 의존하는 소프트웨어 아키텍처는 매우 취약하며 동시 프로그래밍에 대한 이해가 매우 어렵다는 점에 유의하십시오. 실질적으로 모든 멀티 스레딩 API에서 이러한 종류의 문제를 방지하기 위해 스레드를 명시 적으로 동기화 할 수있는 기능이 있습니다.

이러한 "최소 요구 사항"이 게임이 실행되지 않는 아래에있는 것을 나타내는 것은 아닙니다. 훨씬 낮은 가능성은 게임이 허용 가능한 성능으로 실행되지 않는 아래에있는 것을 나타냅니다. 소프트웨어를 기술적으로 실행할 수 있더라도 단일 코어 1Ghz 박스에서 크 래피 성능에 대해 불평하는 많은 고객을 처리하려는 게임 회사는 없습니다. 따라서 그들은 아마도 코어 수가 적은 박스에서 허용 가능한 성능을 제공하는 것보다 열심히 실패하도록 의도적으로 설계했습니다.

게임 성능에서 중요한 측정 기준 중 하나는 프레임 속도입니다. 일반적으로 초당 30 또는 60 프레임으로 실행됩니다. 즉, 게임 엔진은 고정 된 시간 내에 게임 상태에서 현재 뷰를 렌더링해야합니다. 60fps를 달성하려면 16msec 이상이 소요됩니다. 하이 엔드 그래픽을 사용하는 게임은 CPU에 바운드가 제한되어 있으므로 더 높은 품질 (시간이 더 소요됨)을 시도하는 것과이 시간 예산을 유지해야 할 필요성 사이에는 막대한 공짜가 있습니다. 따라서 각 프레임의 시간 예산은 매우 빡빡합니다.

시간 예산이 빡빡하기 때문에 개발자는 이상적으로 하나 이상의 코어에 독점적으로 액세스하기를 원합니다. 또한 세계 예산 계산과 같은 다른 작업은 그렇지 않은 별도의 프로세스에서 발생하는 반면 독점적으로 해당 시간 예산에서 수행해야하는 작업으로 인해 렌더링 작업을 코어에서 수행 할 수 있기를 원할 것입니다. 침입하다.

이론적으로이 모든 것을 단일 코어에 넣을 수는 있지만 모든 것이 훨씬 더 어려워집니다. 갑자기 모든 게임 상태가 충분히 빠르게 이루어지고 렌더링이 가능해 지도록해야합니다. OS가 "스레드 A가 스레드 B의 기능에 관계없이 16msec 내에 X 작업량을 완료해야 함"을 이해할 수있는 방법이 없기 때문에 두 개의 소프트웨어 스레드로 만들 수는 없습니다.

게임 개발자는 새로운 하드웨어를 구입하는 데 관심이 없습니다. 시스템 요구 사항이있는 이유는 저가형 시스템을 지원하는 비용이 그만한 가치가 없기 때문입니다.

절대 잠들지 않는 3 개의 실시간 스레드와 다른 스레드. 코어가 4 개 미만이면 네 번째 스레드가 실행되지 않습니다. 네 번째 스레드가 실시간 스레드를 완료하기 위해 실시간 스레드 중 하나와 통신해야하는 경우 코드는 4 개 미만의 코어로 완료되지 않습니다.

물론 실시간 스레드가 스레드를 잠글 수없는 무언가 (스핀 록과 같은)를 기다리고 있다면 프로그램 설계자가 망쳤습니다.

우선 모든 소프트웨어 스레드는 하드웨어 스레드와 관련이 없으며 종종 혼합됩니다. 소프트웨어 스레드는 프로세스 컨텍스트 내에서 자체적으로 디스패치되고 실행될 수있는 코드 조각입니다. 하드웨어 스레드는 대부분 OS에서 관리하며 일반 프로그램에 대해 이야기 할 때 프로세서 코어로 디스패치됩니다. 이러한 하드웨어 스레드는로드를 기준으로 발송됩니다. 하드웨어 스레드 디스패처는로드 밸런서와 거의 비슷하게 작동합니다.

그러나 게임, 특히 고급 게임의 ​​경우 하드웨어 스레드가 게임 자체에 의해 관리되거나 게임이 하드웨어 스레드 디스패처에게 수행 할 작업을 지시하는 경우가 있습니다. 모든 작업 또는 작업 그룹이 일반 프로그램에서와 같은 우선 순위를 갖지 않기 때문입니다. 드래곤 에이지는 하이 엔드 게임 엔진을 사용하는 하이 엔드 게임 스튜디오에서 나왔기 때문에 "수동"디스패치를 ​​사용하고 코어 수가 최소한의 시스템 요구 사항이된다고 상상할 수 있습니다. 1 개 또는 2 개의 코어 만있는 머신에서 실행중인 3 번째 물리적 코어에 코드를 보내면 모든 프로그램이 충돌합니다.

가상화를 사용하여 물리적보다 많은 가상 코어를 가질 수 있고 소프트웨어가 가상화에서 실행되고 있음을 알지 못하고 대신 많은 물리적 코어를 가지고 있다고 생각하기 때문에 그러한 소프트웨어는 불가능하다고 말합니다.

즉, 항상 N 코어 미만에서 중지되는 소프트웨어를 작성할 수는 없습니다.

다른 사람들이 지적했듯이, 잠재적으로 확인할 수있는 소프트웨어 솔루션이 있습니다. 특히 N 프로세스가 <N 프로세서에서 실행될 때 사용되는 OS 및 코드가 경쟁 조건에 대해 거의 보호되지 않는 경우가 있습니다. 실제 요령은 N 프로세서보다 적은 프로세서에서는 실패하지만 N 프로세서에는 있지만 실패한 프로세서는 N 프로세서보다 작은 경우에는 실패하는 코드입니다.

배경을 생성하거나 NPC 이동을 생성하고 이벤트를 네 번째로 전달하는 세 개의 스레드가있을 수 있습니다. 이벤트를 집계 / 필터링하고 뷰 모델을 업데이트해야합니다. 네 번째 스레드가 코어에서 예약되지 않았기 때문에 모든 이벤트를 가져 오지 못하면 뷰 모델이 올바르게 업데이트되지 않습니다. 이는 산발적으로 만 발생할 수 있지만 이러한 코어는 언제든지 사용할 수 있어야합니다. 이것은 왜 항상 높은 CPU 사용량을 보지 못하지만 게임이 제대로 작동하지 않는지 설명 할 수 있습니다.

나는 여호수아가 결론이 아니라 올바른 길을 가고 있다고 생각합니다.

가능한 한 많이 쓰도록 쓰인 쓰레드가있는 아키텍처를 가지고 있다고 가정 해 보자. 이러한 스레드의 성능을 유지하기 위해 어떤 작업도 제어하지 않으므로 Windows 작업 스케줄러의 지연을 피하고 싶지 않습니다. 4 개 이상의 코어가있는 한 제대로 작동하지만, 그렇지 않으면 심하게 실패합니다.

일반적으로 이것은 좋지 않은 프로그래밍이지만 게임은 또 다른 문제입니다. 모든 하드웨어보다 열등한 디자인 또는 충분히 좋은 하드웨어보다 우월한 디자인 또는 열등한 하드웨어 게임 개발자의 실패 중에서 선택하는 경우 하드웨어가 필요합니다.

Is it possible to write code (or complete software, rather than a piece of code) that won't work properly when run on a CPU that has less than N number of cores?

물론. 실시간 스레드를 사용하는 것은 이것이 가능할뿐만 아니라 작업을 수행하기 위해 원하는 방식 (그리고 종종 유일한 올바른 방법) 인 상황의 좋은 예입니다. 그러나 실시간 스레드는 일반적으로 OS 커널로 제한됩니다. 일반적으로 특정 종류의 하드웨어 이벤트가 정의 된 기간 내에 처리되도록 보장해야하는 드라이버의 경우. 일반 사용자 응용 프로그램에는 실시간 스레드가 없어야하며 Windows 사용자 모드 응용 프로그램에도 스레드가있을 수 있는지 확실하지 않습니다. 일반적으로 운영 체제는 주어진 응용 프로그램이 시스템을 제어 할 수 있기 때문에 사용자 영역에서이를 의도적으로 불가능하게합니다.

사용자 영역 응용 프로그램 관련 : 실행하기 위해 지정된 수의 스레드를 검사하는 것이 반드시 악의적 인 의도라는 가정은 정확하지 않습니다. 예를 들어, 자체적으로 핵심이 필요한 장기 실행 성능 집약적 인 2 개의 작업이있을 수 있습니다. CPU 코어 속도에 관계없이, 다른 스레드와 코어를 공유하는 것은 스레드 전환으로 인해 발생하는 일반적인 처벌과 함께 캐시 스 래싱으로 인해 심각하고 수용 할 수없는 성능 저하가 될 수 있습니다 (이는 상당히 중요합니다). 특히 게임의 경우, 각 스레드마다 하나의 특정 코어에만 선호도가 있도록 각 스레드를 설정 한 다음 2 개의 코어에 선호도가 없도록 다른 모든 스레드를 설정하십시오. 하지만 이렇게하려면

스레드 개수가 코어 수를 초과하는 경우 눈에 띄는 양의 잠금 경합이있는 스핀 락을 사용하는 모든 코드는 (게임과 같은 응용 프로그램의 경우 "작동하지 않음" 이라고 할 수있는 정도로 ) 성능이 뛰어납니다.

예를 들어 4 개의 소비자 스레드를 제공하는 대기열에 작업을 제출하는 생산자 스레드를 상상해보십시오. 코어는 두 가지뿐입니다.

생산자는 스핀 락을 얻으려고 시도하지만 다른 코어에서 실행되는 소비자가 보유합니다. 생산자가 회전하는 동안 두 코어가 잠금 단계를 실행하고 잠금이 해제 될 때까지 기다립니다. 이것은 이미 나쁘지만 얻을 수있는만큼 나쁘지는 않습니다.
불행히도 소비자 스레드는 양자 시간이 끝났으므로 선점되고 다른 소비자 스레드가 예약됩니다. 잠금을 유지하려고 시도하지만 물론 잠금이 수행되므로 이제 두 개의 코어 가 회전하여 발생할 수없는 것을 기다리고 있습니다.
생산자 스레드가 시간 조각의 끝에 도달하고 선취되면 다른 소비자가 깨어납니다. 다시 말하지만, 두 명의 소비자가 잠금 해제를 기다리고 있으며, 양자가 두 번 더 지나기 전에는 발생하지 않습니다.
[...] 마침내 스핀 락을 잡고 있던 소비자가 자물쇠를 풀었습니다. 다른 코어에서 회전하는 사람이 즉시 가져옵니다. 다른 소비자 스레드 일 확률이 75 %입니다 (3 대 1). 즉, 생산자가 여전히 정체 상태에 있을 가능성이 75 % 입니다. 물론 이것은 소비자들도 멈춘다는 것을 의미합니다. 생산자가 요약 작업을하지 않으면 할 일이 없습니다.

이것은 스핀 록뿐만 아니라 어떤 종류의 잠금에서도 원칙적으로 작동하지만, CPU는 아무 것도 달성하지 않으면 서 레코딩주기를 유지하기 때문에 스핀 록과 함께 치명적인 효과가 훨씬 두드러집니다.

위의 것 외에도 일부 프로그래머는 선호도가 첫 번째 코어로 설정된 전용 스레드를 사용하는 훌륭한 아이디어를 가지고 있다고 생각하므로 RDTSC는 모든 프로세서에서 신뢰할 수있는 결과를 제공 할 것입니다 (어쨌든 그렇지는 않지만 일부 사람들은 그렇게 생각합니다).

당신이 무엇을 요구하는지 이해한다면 가능하지만, 그것은 매우, 매우 나쁜 일입니다.

설명하는 표준 예는 여러 스레드로 증가하는 카운터를 유지하는 것입니다. 이를 위해서는 컴퓨팅 성능이 거의 필요하지 않지만 스레드간에 신중한 조정이 필요합니다. 한 번에 하나의 스레드 만 증가 (실제로 읽기, 추가, 쓰기가 뒤 따름)를 수행하는 한 그 값은 항상 정확합니다. 하나의 스레드가 항상 올바른 "이전"값을 읽고 하나를 추가하고 올바른 "다음"값을 작성하기 때문입니다. 동시에 두 개의 스레드를 조치로 가져 오면 둘 다 동일한 "이전"값을 읽고 증분에서 동일한 결과를 얻고 동일한 "다음"값을 씁니다. 두 개의 스레드가 각각 그렇게했다고 생각하더라도 카운터는 효과적으로 한 번만 증가했을 것입니다.

타이밍과 정확성 사이의 이러한 의존성은 컴퓨터 과학이 경쟁 조건 이라고 부릅니다 .

경쟁 조건은 종종 동기화 메커니즘을 사용하여 공유 데이터 조각에서 작동하려는 스레드가 액세스를 위해 정렬되도록하여 피할 수 있습니다. 위에서 설명한 카운터는이를 위해 읽기 / 쓰기 잠금 을 사용할 수 있습니다 .

Dragon Age : Inquisition 의 내부 디자인에 액세스 할 수없는 사람은 누구나 그것이 어떻게 행동하는지에 대해 추측 할 수 있습니다. 그러나 나는 내 자신의 경험에서 본 것들을 바탕으로 갈 것입니다.

프로그램은 조정 된 4 개의 스레드를 기반으로하므로 스레드가 대부분 물리적 코어에서 중단없이 실행될 때 모든 것이 작동합니다. "튜닝"은 코드를 재 배열하거나 전략적인 장소에 수면을 삽입하여 개발 중에 발생하는 경쟁 조건으로 인한 버그를 완화하는 형태로 나타날 수 있습니다. 다시 말하지만, 이것은 모두 추측이지만, 경쟁 조건이 내가 계산하는 것보다 더 많은 방식으로 "해결"되는 것을 보았습니다.

튜닝 된 환경보다 성능이 낮은 환경에서 이와 같은 방식으로 프로그램을 실행하면 코드가 빠르게 또는보다 상황에 맞게 전환 될 수 있기 때문에 타이밍 변경이 발생합니다. 컨텍스트 전환은 물리적 (즉, CPU의 물리적 코어가 논리적 코어가 보유한 작업간에 전환하고 있음)과 논리적 (즉, CPU의 OS가 코어에 작업을 할당하고 있음) 방식으로 발생하지만 둘 중 어느 것과 크게 차이가 있습니다. "예상 된"실행 타이밍입니다. 나쁜 행동을 일으킬 수 있습니다.

경우 드래곤 에이지 : 종교 재판 만드는 간단한 조치를 취할하지 않도록 즉 EA의 잘못, 진행하기 전에 충분한 물리적 코어를 사용할 수있다. 그들은 너무 작은 하드웨어에서 게임을 실행하려고 시도한 사람들로부터 적은 재산 지원 지원 전화와 이메일을 보내고있을 것입니다.

Windows에는이를위한 기능이 내장되어 있습니다. GetLogicalProcessorInformation 함수 는 Windows API에 있습니다. 프로그램에서 호출하여 코어, 가상 코어 및 하이퍼 스레딩에 대한 정보를 얻을 수 있습니다.

따라서 귀하의 질문에 대한 답변은 다음과 같습니다.