더 이상 사용하지 않아야하는 멀티 스레드 및 멀티 프로세서 프로그래밍에 대한 더 이상 사용되지 않는 방법이 있습니까?


36

FORTRAN 및 BASIC의 초기에는 기본적으로 모든 프로그램이 GOTO 문으로 작성되었습니다. 결과는 스파게티 코드 였고 솔루션은 구조화 된 프로그래밍이었습니다.

마찬가지로 포인터는 프로그램의 특성을 제어하기 어려울 수 있습니다. C ++은 많은 포인터로 시작했지만 참조를 사용하는 것이 좋습니다. STL과 같은 라이브러리는 일부 종속성을 줄일 수 있습니다. 더 나은 특성을 가진 스마트 포인터를 만드는 관용구도 있으며 일부 C ++ 버전에서는 참조 및 관리 코드를 허용합니다.

상속 및 다형성과 같은 프로그래밍 방법은 많은 배후에 포인터를 사용합니다 (구조화 된 프로그래밍은 분기 명령어로 채워진 코드를 생성하는 것과 마찬가지로). Java와 같은 언어는 포인터를 제거하고 가비지 수집을 사용하여 프로그래머에 의존하지 않고 동적으로 할당 된 데이터를 관리하여 모든 새 문과 삭제 문을 일치시킵니다.

필자는 세마포어를 사용하지 않는 멀티 프로세스 및 멀티 스레드 프로그래밍의 예를 보았습니다. 그들은 같은 이름을 다른 이름으로 사용하거나 동시 사용으로부터 자원을 보호하는 새로운 방법을 가지고 있습니까?

예를 들어, 멀티 코어 프로세서를 사용한 멀티 스레드 프로그래밍 시스템의 특정 예는 OpenMP입니다. 환경에 포함되지 않는 세마포어를 사용하지 않고 다음과 같이 중요한 영역을 나타냅니다.

th_id = omp_get_thread_num();
#pragma omp critical
{
  cout << "Hello World from thread " << th_id << '\n';
}

이 예제는 http://en.wikipedia.org/wiki/OpenMP 에서 발췌 한 것입니다.

또는 wait () 및 signal () 함수를 사용하여 세마포어를 사용하여 서로 비슷한 스레드를 보호하는 방법은 다음과 같습니다.

wait(sem);
th_id = get_thread_num();
cout << "Hello World from thread " << th_id << '\n';
signal(sem);

이 예제에서는 상황이 매우 간단하고 간단한 검토만으로 wait () 및 signal () 호출이 일치하고 많은 동시성이 있어도 스레드 안전성이 제공됨을 보여주기에 충분합니다. 그러나 다른 알고리즘은 더 복잡하며 여러 스레드에서 호출 할 수있는 복잡한 조건을 가진 여러 함수에 걸쳐 여러 세마포어 (바이너리 및 카운팅)를 사용합니다. 교착 상태를 만들거나 스레드를 안전하게 만들지 못하는 결과는 관리하기 어려울 수 있습니다.

OpenMP와 같은 이러한 시스템이 세마포 문제를 제거합니까?
그들은 다른 곳으로 문제를 옮깁니 까?
더 이상 세마포어를 사용하지 않도록 알고리즘을 사용하여 좋아하는 세마포어를 변환하려면 어떻게해야합니까?


정확히 무슨 소리 야? 당신은 무엇을 보았는가?
svick

4
무례한 의미는 아니지만 처음 세 단락을 제거했을 수 있습니다. 그들은 실제로 당신의 질문에 영향을 미치지 않으며, 그들의 결론에 도달하고 많은 논쟁을 일으킬 것입니다.
dbracey

1
우와, 큰 편집. 나는 대답에 찔렀다. 이 질문은 여전히 ​​GOTO, 포인터, 상속 및 다형성을 통해 돌아 다니지 만 내 대답에서 나는이 문제를 제쳐 놓고 "더 이상 사용되지 않는 관행"문제에 중점을 두었습니다.
스튜어트 마크

답변:


15

더 이상 사용해서는 안되는 동시 프로그래밍 기술과 관행이 있습니까? 나는 yes 라고 말할 것이다 .

오늘날 드문 것처럼 보이는 초기 동시 프로그래밍 기술 중 하나는 인터럽트 기반 프로그래밍입니다. 이것이 1970 년대 UNIX의 작동 방식입니다. UNIX에 대한 라이온스 해설 또는 Bach의 UNIX 운영 체제 설계를 참조하십시오 . 간단히 말해서,이 기술은 데이터 구조를 조작하는 동안 일시적으로 인터럽트를 일시 중단 한 다음 인터럽트를 복원하는 것입니다. BSD의 SPL (9) 매뉴얼 페이지이 코딩 스타일의 예가 있습니다. 인터럽트는 하드웨어 지향적이며 코드는 하드웨어 인터럽트 종류와 해당 하드웨어와 관련된 데이터 구조 사이의 암시 적 관계를 구현합니다. 예를 들어, 디스크 I / O 버퍼를 조작하는 코드는 해당 버퍼로 작업하는 동안 디스크 컨트롤러 하드웨어의 인터럽트를 일시 중단해야합니다.

이 스타일의 프로그래밍은 단일 프로세서 하드웨어의 운영 체제에서 사용되었습니다. 애플리케이션이 인터럽트를 다루는 것은 훨씬 드 was니다. 일부 OS에는 소프트웨어 인터럽트가 있었으며 사람들이 그 위에 스레딩 또는 코 루틴 시스템을 만들려고 시도했지만 그다지 널리 퍼지지 않았습니다. (확실히 UNIX 세계에서는 그렇지 않습니다.) 저는 오늘날 인터럽트 스타일 프로그래밍이 소형 임베디드 시스템이나 실시간 시스템에 국한되어 있다고 생각합니다.

세마포어 는 하드웨어와 관련이없는 소프트웨어 구조이므로 하드웨어 기능에 대한 추상화를 제공하며 멀티 스레딩 및 멀티 프로세싱을 지원하므로 인터럽트보다 앞서 있습니다. 주요 문제는 구조화되지 않았다는 것입니다. 프로그래머는 전체 세마포어와 전체 세마포어가 보호하는 데이터 구조 사이의 관계를 전체 프로그램에서 전 세계적으로 유지해야합니다. 이런 이유로 나는 베어 세마포어가 오늘날 거의 사용되지 않는다고 생각합니다.

또 다른 작은 진전은 데이터가 보호되는 동시성 제어 메커니즘 (잠금 및 조건)을 캡슐화 하는 모니터 입니다. 이것은 Mesa (alternate link) 시스템으로 옮겨 져서 거기에서 Java로 옮겨졌다. (이 Mesa 논문을 읽으면 Java의 모니터 잠금 및 조건이 Mesa에서 거의 그대로 복사되는 것을 볼 수 있습니다.) 모니터는 충분히 신중하고 성실한 프로그래머가 코드 및 데이터에 대한 로컬 추론 만 사용하여 동시 프로그램을 안전하게 작성할 수 있다는 점에서 도움이됩니다. 모니터 내에서.

Java java.util.concurrent패키지 의 라이브러리와 같은 추가 라이브러리 구성이 있으며 여기에는 다양한 동시 데이터 구조 및 스레드 풀링 구성이 포함됩니다. 이것들은 스레드 감금 및 효과적인 불변성과 같은 추가 기술과 결합 될 수 있습니다. Goetz 등의 Java Concurrency In Practice 를 참조하십시오 . 알. 추가 토론을 위해. 불행히도 많은 프로그래머들은 라이브러리 작성자가 무거운 작업을 이미 수행 한 ConcurrentHashMap 과 같은 것을 사용해야 할 때 여전히 잠금 및 조건으로 자체 데이터 구조를 롤링하고 있습니다 .

위의 모든 것은 몇 가지 중요한 특성을 공유 합니다. 전역 적으로 공유되고 변경 가능한 상태에서 상호 작용하는 여러 제어 스레드가 있습니다. 문제는이 스타일의 프로그래밍은 여전히 ​​오류가 발생하기 쉽다는 것입니다. 작은 실수가 눈에 띄지 않게하는 것은 매우 쉬워서 재생산 및 진단하기 어려운 오작동을 초래합니다. 이런 방식으로 큰 시스템을 개발하기 위해 "충분히 신중하고 부지런한"프로그래머는 없을 수 있습니다. 최소한 거의 없습니다. 따라서 가능한 경우 공유 가능한 변경 가능한 상태의 멀티 스레드 프로그래밍을 피해야 한다고 말하고 싶습니다 .

불행히도 모든 경우에 피할 수 있는지는 확실하지 않습니다. 많은 프로그래밍이 여전히 이런 방식으로 수행됩니다. 이것을 다른 것으로 대체하는 것이 좋을 것입니다. Jarrod Robersondavidk01의 답변은 불변 데이터, 함수형 프로그래밍, STM 및 메시지 전달과 같은 기술을 가리 킵니다. 추천 할 것이 많으며 모두 적극적으로 개발되고 있습니다. 그러나 나는 그들이 아직 좋은 구식 공유 가변 상태를 완전히 대체했다고 생각하지 않습니다.

편집 : 여기에 특정 질문에 대한 나의 대답이 있습니다.

OpenMP에 대해 잘 모릅니다. 필자는 수치 시뮬레이션과 같은 병렬 문제에 매우 효과적이라고 생각합니다. 그러나 일반적인 용도는 아닙니다. 세마포어 구조는 매우 저수준으로 보이며 프로그래머가 위에서 설명한 모든 문제와 함께 세마포어와 공유 데이터 구조 간의 관계를 유지해야합니다.

세마포어를 사용하는 병렬 알고리즘이 있다면, 그것을 변환하는 일반적인 기술을 모른다. 객체로 리팩토링 한 다음 주변에 추상화를 만들 수 있습니다. 그러나 메시지 전달과 같은 것을 사용하려면 전체 문제를 다시 개념화해야한다고 생각합니다.


감사합니다. 이것은 훌륭한 정보입니다. 나는 여러분이 언급 한 개념들을 참고하여 더 깊이 탐구 할 것입니다.
DeveloperDon

java.util.concurrent의 경우 +1이며 의견에 동의했습니다. 이는 1.5 이후 JDK에 있었으며 거의 ​​사용되지 않았습니다.
MebAlone

1
이미 존재하는 구조를 롤링하지 않는 것이 얼마나 중요한지 강조했으면합니다. 너무 많은, 너무 많은 버그 ...
corsiKa

"세마포어는 하드웨어와 관련이없는 소프트웨어 구조이기 때문에 인터럽트보다 진보 한 것"이라고 말하는 것이 정확하지 않다고 생각합니다 . 세마포어는 비교 및 스왑 명령 을 구현하기 위해 CPU에 의존 하거나 멀티 코어 변형 입니다.
조쉬 피어스

@JoshPearce 물론 세마포어는 하드웨어 구성을 사용하여 구현 되지만 CAS, 테스트 및 설정, cmpxchng 등과 같은 특정 하드웨어 구성과 무관 한 추상화 입니다.
Stuart Marks

28

질문에 대한 답변

일반적인 합의는 공유 가능한 변경 가능 상태 는 Bad ™이고, 변경 불가능한 상태는 Good ™이며, 기능 언어와 명령형 언어에 의해 반복해서 정확하고 사실임이 입증되었습니다.

문제는 주류 명령형 언어는 이러한 방식으로 작업하도록 설계되지 않았으며 밤새 언어에 대해 변경되지 않습니다. 이것은 비교에 GOTO결함이있는 곳입니다. 불변 상태와 메시지 전달은 훌륭한 솔루션이지만 만병 통치약도 아닙니다.

결함이있는 전제

이 질문은 결함이있는 전제와의 비교를 바탕으로합니다. 그것은 GOTO실제 문제였으며 Intergalatic Universal Language Board of Language Designers and Software Engineering Unions에 의해 어떻게 사용되지 않습니까 ? GOTO메커니즘이 없으면 ASM이 전혀 작동하지 않습니다. 원시 포인터가 C 또는 C ++의 문제이며 일부 스마트 포인터가 만병 통치약이라는 점을 전제와 동일합니다.

GOTO문제가 아니었고 프로그래머가 문제였습니다. 공유 변경 가능 상태도 마찬가지입니다 . 그것은 그 자체로 문제 가 아니며 , 문제 가되는 것은 프로그래머입니다. 경쟁 조건이나 버그 가 전혀없는 방식으로 공유 가변 상태 를 사용하는 코드를 생성 하는 방법 이 있다면 문제가되지 않습니다. 스파게티 코드를 작성 하거나 등가의 구문을 작성하지 않는 것과 마찬가지로 문제도 아닙니다.GOTO

교육은 만병 통치약입니다

바보 프로그래머는 deprecated모든 인기있는 언어가 여전히 GOTO직간접 적으로 구문 을 가지고 있으며 이러한 유형의 구문을 가진 모든 언어에서 올바르게 사용될best practice 때 입니다.

예 : Java에는 레이블이 있으며 try/catch/finally둘 다 GOTO명령문으로 직접 작동 합니다.

내가 이야기하는 대부분의 Java 프로그래머는 immutable실제로 외부 the String class is immutable에서 눈으로 보이는 좀비로 반복하는 것이 무엇 을 의미 하는지조차 모릅니다 . 그들은 키워드를 올바르게 사용하여 클래스 를 만드는 방법을final 모릅니다 immutable. 따라서 변경 불가능한 메시지 사용하는 메시징 전달이 왜 그렇게 큰지, 공유 변경 가능 상태가 왜 그렇게 좋지 않은지 잘 모르겠습니다.


3
+1 훌륭한 답변, 명확하게 작성되고 변경 가능한 상태의 기본 패턴을 정확하게 나타냅니다. IUBLDSEU는 meme가되어야합니다 :)
Dibbeke

2
GOTO는 '제발, 여기서 화염 전쟁을 시작하지 말아주세요. 이 질문은 화염을 발산하지만 실제로 좋은 대답을하지는 않습니다. 함수형 프로그래밍과 불변성에 대한 훌륭한 언급은 훌륭하지만 그 진술에 고기는 없습니다.
Evan Plaice

1
이것은 모순되는 답변 인 것 같습니다. 먼저 "A는 나쁘고 B는 좋다"라고 말한 다음 "바보는 더 이상 사용되지 않습니다"라고 말합니다. 첫 번째 단락에도 같은 내용이 적용되지 않습니까? 대답의 마지막 부분을 "모든 언어에서 올바르게 사용하는 경우 공유 된 변경 가능한 상태가 가장 좋습니다"라고 말할 수는 없습니다. 또한 "증거"는 매우 강력한 단어입니다. 실제로 강력한 증거 가 없으면 사용해서는 안됩니다 .
luiscubal

2
화염 전쟁을 시작하려는 의도는 아니 었습니다. Jarrod가 내 의견에 반응 할 때까지 GOTO는 논란의 여지가 없으며 비유에서 잘 작동한다고 생각했습니다. 내가 질문을 쓸 때, 그것은 나에게 발생하지 않았지만 Dijkstra는 GOTO와 세마포 모두에서 그라운드 제로에있었습니다. Edsger Dijkstra는 저에게 거인처럼 보였고, GOTO에 관한 세마포어 (1965)와 초기 (1968)의 학술 연구로 유명했습니다. Dijkstra의 옹호 방법은 종종 피각적이고 대립적이었습니다. 논쟁 / 대결이 그를 위해 일했지만 세마포어에 대한 가능한 대안에 대한 아이디어를 원합니다.
DeveloperDon

1
많은 프로그램들이 현실 세계에서 변할 수있는 것들을 모델링해야합니다. 오전 5시 37 분에 객체 # 451이 그 순간 실제 세계의 상태를 유지하고 (오전 5시 37 분) 이후 실제 상태가 변경되면 객체의 신원이 실제 사물의 상태는 불변이되거나 (즉, 사물은 항상 오브젝트 # 451로 표시 될 것임), 또는 사물 # 451은 불변이 될 수 있지만 둘다는 아닙니다. 많은 경우에, 신원을 불변으로 만드는 것이 객체 # 451을 불변으로 만드는 것보다 더 도움이 될 것입니다.
supercat

27

학계에서 가장 최근의 분노는 STM ( Software Transactional Memory) 인 것으로 보이며 충분히 똑똑한 컴파일러 기술을 사용하여 프로그래머가 멀티 스레드 프로그래밍의 모든 세부 사항을 프로그래머에게 제공 할 것을 약속합니다. 배후에는 여전히 잠금 및 세마포어이지만 프로그래머는 걱정할 필요가 없습니다. 이 접근법의 이점은 아직 명확하지 않으며 명백한 경쟁자가 없습니다.

Erlang 은 동시성을 위해 메시지 전달 및 에이전트를 사용하며 이는 STM보다 작동하기 더 간단한 모델입니다. 메시지 전달을 사용하면 각 에이전트가 자체 미니 유니버스에서 작동하므로 데이터 관련 경쟁 조건이 없으므로 걱정할 잠금 및 세마포가 없습니다. 여전히 이상한 경우가 있지만 라이브 록 및 교착 상태만큼 복잡하지 않습니다. JVM 언어는 Akka 를 사용 하고 메시지 전달 및 액터의 모든 이점을 얻을 수 있지만 Erlang과 달리 JVM은 액터를 기본적으로 지원하지 않으므로 Akka는 여전히 스레드와 잠금을 사용하지만 사용자는 프로그래머는 그것에 대해 걱정할 필요가 없습니다.

내가 알고있는 다른 모델은 잠금 및 스레드를 사용하지 않는 것은 실제로 다른 형태의 비동기 프로그래밍 인 미래 를 사용 하는 것입니다.

C ++ 에서이 기술을 얼마만큼 사용할 수 있는지 확실하지 않지만 스레드와 잠금을 명시 적으로 사용하지 않는 것을보고 있다면 동시성 관리를위한 위의 기술 중 하나가 될 가능성이 있습니다.


새로운 용어 "털이 많은 세부 사항"은 +1입니다. 롤맨 나는이 새로운 용어에 대해 웃을 수 없다. 이제부터는 "헤어 코드"를 사용할 것 같습니다.
Saeed Neamati

1
@Saeed : 전에 그 표현을 들어 봤는데, 그렇게 드문 일이 아닙니다. 나는 그것이 재미 있다는 것에 동의한다 :-)
Cameron

1
좋은 대답입니다. .NET CLI는 아마도 (잠금과는 대조적으로) 신호를 지원하지만 잠금을 완전히 대체 한 예를 아직 보지 못했습니다. 비동기가 중요한지 잘 모르겠습니다. Javascript / NodeJ와 같은 플랫폼에 대해 이야기하는 경우 실제로 단일 스레드이며 높은 리소스 부하에서 더 우수합니다 (즉, 많은 컨텍스트에서). CPU 집약적로드에서는 비동기 프로그래밍을 사용하면 이점이 거의 없습니다.
Evan Plaice

1
흥미로운 대답은 전에는 선물을 본 적이 없었습니다 . 또한 Erlang 과 같은 메시지 전달 시스템에서 교착 상태라이브 록 을 계속 사용할 수 있습니다 . CSP를 사용하면 교착 상태라이브 록 에 대해 공식적으로 추론 할 수 있지만 그 자체로는 막을 수 없습니다.
Mark Booth

1
Lock free를 추가하고 free list를 기다립니다.
stonemetal

3

나는 이것이 대부분 추상화 수준에 관한 것이라고 생각한다. 프로그래밍에서 종종 더 안전하고 읽기 쉬운 방식으로 일부 세부 사항을 추상화하는 것이 유용합니다.

이 제어 구조에 적용 ifS, forS와도 try- catch블록 이상 단지 추상화입니다 goto들. 이러한 추상화는 코드를보다 읽기 쉽게 만들어주기 때문에 거의 항상 유용합니다. 그러나 여전히 사용해야 할 경우가 있습니다 goto(예 : 직접 손으로 어셈블리를 작성하는 경우).

이것은 메모리 관리에도 적용됩니다. C ++ 스마트 포인터와 GC는 원시 포인터와 수동 메모리 할당 해제에 대한 추상화입니다. 그리고 때로는 이러한 추상화가 적절하지 않습니다 (예 : 실제로 최대 성능이 필요한 경우).

멀티 스레딩에도 마찬가지입니다. 선물이나 배우와 같은 것은 스레드, 세마포어, 뮤텍스 및 CAS 명령어에 대한 추상화 일뿐입니다. 이러한 추상화는 코드를 훨씬 더 읽기 쉽게 만들고 오류를 피하는 데 도움이됩니다. 그러나 때때로 그들은 단순히 적절하지 않습니다.

사용 가능한 도구와 장단점이 무엇인지 알아야합니다. 그런 다음 작업에 대한 올바른 추상화를 선택할 수 있습니다 (있는 경우). 더 높은 수준의 추상화는 더 낮은 수준을 더 이상 사용하지 않으며, 추상화가 적절하지 않은 경우가 항상 있으며 "올드 웨이"를 사용하는 것이 가장 좋습니다.


고마워요, 당신은 비유를 잡으려고합니다 .WRT 세마포어가 대답인지 더 이상 사용되지 않는지에 대해 갈망 할 생각이나 도끼가 없습니다. 더 큰 문제는 더 나은 방법과 세마포어가 중요한 것을 빠뜨리지 않은 것처럼 보이며 전체 멀티 스레드 알고리즘을 수행 할 수없는 시스템에 있습니다.
DeveloperDon

2

네,하지만 당신은 그들 중 일부에 부딪 칠 가능성이 없습니다.

예전에는 좋은 뮤텍스를 작성하는 것이 어려웠 기 때문에 블로킹 방법 (장벽 동기화)을 사용하는 것이 일반적이었습니다. 최신 동시성 라이브러리를 사용하면 병렬화 및 프로세스 간 조정을위한 훨씬 풍부하고 철저한 테스트를 거친 도구 세트가 제공되므로 이러한 점을 여전히 볼 수 있습니다.

마찬가지로, 오래된 관행은 고문 코드를 작성하여 수동으로 병렬화하는 방법을 알아낼 수있었습니다. 이런 형태의 (잠재적으로 잘못되면 잠재적으로 해로운) 최적화는 또한 당신을 위해 이것을 수행하는 컴파일러의 출현, 필요한 경우 루프 풀기, 예측 적으로 분기 수행 등으로 창 밖으로 나갔습니다. 그러나 이것은 새로운 기술이 아닙니다. 시장에서 15 년 이상 근무하고 있습니다. 스레드 풀과 같은 것을 활용하면 어제 정말 까다로운 코드도 피할 수 있습니다.

따라서 더 이상 사용되지 않는 방법은 테스트를 거친 최신 라이브러리를 사용하는 대신 동시성 코드를 직접 작성하는 것입니다.


감사. 동시 프로그래밍을 사용할 가능성이 큰 것 같지만, 규칙적으로 사용하지 않으면 판도라 상자가 될 수 있습니다.
DeveloperDon

2

Apple의 Grand Central Dispatch는 동시성에 대한 생각을 바꾼 우아한 추상화입니다. 대기열에 중점을 둔 것은 겸손한 경험에서 비동기 논리 구현을 훨씬 간단하게 만듭니다.

사용 가능한 환경에서 프로그래밍 할 때 대부분의 스레드, 잠금 및 스레드 간 통신 사용을 대체했습니다.


1

병렬 프로그래밍의 주요 변경 사항 중 하나는 CPU가 이전보다 엄청나게 빠르지 만 그 성능을 달성하려면 멋지게 채워진 캐시가 필요하다는 것입니다. 여러 스레드를 동시에 실행하여 지속적으로 스와핑을 시도하면 거의 항상 각 스레드에 대한 캐시가 무효화됩니다 (즉, 각 스레드가 작동하려면 서로 다른 데이터가 필요함). 느린 CPU에 익숙합니다.

이것이 비동기 또는 작업 기반 (예 : Grand Central Dispatch 또는 Intel의 TBB) 프레임 워크가 더 인기있는 이유 중 하나입니다. 한 번에 코드 1 작업을 실행하여 다음 프레임으로 이동하기 전에 완료합니다. 그러나 각각을 코딩해야합니다. 디자인을 망쳐 놓지 않으려면 각 작업을 약간의 시간이 걸립니다 (예 : 병렬 작업이 실제로 대기 중). CPU를 많이 사용하는 작업은 모든 작업을 처리하는 단일 스레드에서 처리되지 않고 대체 CPU 코어로 전달됩니다. 실제로 멀티 스레드 처리가 진행되지 않는 경우 관리하기가 더 쉽습니다.


Apple 및 Intel 기술에 대한 참조에 감사드립니다. 귀하의 답변은 스레드 대 코어 선호도 관리의 과제를 지적하고 있습니까? 멀티 코어 프로세서가 코어 당 L1 캐시를 반복 할 수 있기 때문에 일부 캐시 성능 문제가 완화됩니까? 예를 들면 다음과 같습니다. software.intel.com/en-us/articles/… 더 많은 캐시 적중률을 가진 4 개의 코어에 대한 고속 캐시는 동일한 데이터에서 더 많은 캐시 누락을 가진 1 개의 코어보다 4 배 이상 빠릅니다. 행렬 곱셈이 가능합니다. 4 개의 코어에서 32 개의 스레드를 임의로 예약 할 수 없습니다. 선호도를 사용하고 32 개의 코어를 가져옵니다.
DeveloperDon

실제로 동일한 문제는 아니지만 코어 선호도는 작업이 코어에서 코어로 바운스되는 문제를 나타냅니다. 작업이 중단되고 새 작업으로 교체 된 경우 동일한 작업이 동일한 코어에서 계속됩니다. 인텔의 말 : 코어 수에 상관없이 캐시 적중 = 빠름, 캐시 미스 = 느림. 나는 그들이 :) AMD의보다는 자신의 칩을 구입하는 당신을 설득하려는 생각
gbjbaanb
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.