스레드가 항상 실행 중이고 들어오는 새 함수 포인터 + 대기열의 데이터에 대한 세마포어를 대기하도록 work_pile 패턴을 사용하고 있습니다. 이제 애플 마케팅 담당자들은 그랜드 센트럴 디스패치 (Grand Central Dispatch)를 부르고 새로운 슬라이스 빵으로 홍보합니다.fine grained multithreading - 작업자 작업은 어느 정도해야합니까?
짧은 태스크를 두 개 더 짧은 태스크로 나누는 것이 유용한 지 알아내는 방법을 알고 싶습니다. 새로운 객체를 큐잉하는 것이 가치가 있는지 판단 할 수있는 규칙이 있습니까?
두 가지 가능한 답 :
나는 두 번째 것을 선호합니다.
어쨌든 두 개의 작업이 항상 순차적으로 진행되고 있다면 (순차적으로) 두 작업이 나뉘어 질 수는 없다고 생각합니다.
벤치마킹은 쉽지 않으며 구현 한 후에 만 할 수 있습니다. 그리고 나는 분할을 조사하기 시작할 때 체크리스트를 갖고 싶습니다. 스레드 정품 인증이 평균적으로 비용이 얼마나 들지 모르겠지만 나노 초 (마이크로 초)가 걸립니까? 만약 내가 알고리즘의 여러 단계를 대기열에 다음 세마포어 카운터 감소 및 뮤텍스가 없다면, 100 사이클 + 캐시 미스 말? – Lothar
필자는 핵심 요소가 CPU/코어 수와 작업 할당 방법이라는 것을 덧붙입니다. 이론은 사용 가능한 코어의 수를 추상화 할 수 있다는 것이지만 벤치마킹만으로 정확하게 질문에 대답 할 수 있다고 확신합니다. – mouviciel
@mouvicel : 벤치마킹의 한계는 단지 특정 질문에 대한 답을 줄 뿐이며 약간 다른 상황에서 최상의 성능을 위해 조정하는 방법에 대한 많은 통찰력을 제공하지 않는다는 것입니다. 이것이 우리가 자동 튜닝에 사용할 수있는 이론적 통찰력을 선호하는 이유입니다. –
멀티 태스킹의 한계는 보유하고있는 코어 수와 동시 알고리즘의 양입니다. 잠금을 포함하여 다양한 유형의 오버 헤드가 동시성의 양을 줄여 멀티 태스킹의 이점을 낮추거나 심지어 역전시킬 수 있습니다. 그것이 독립적이고 장기간에 걸친 작업이있을 때 가장 잘 작동하는 이유입니다. 오버 헤드가 성능 향상을 삼키지 않는 한, 짧은 작업조차 코어로 나눠서 지불하는 것이 좋습니다.
작업 파일 패턴의 배경은 사용 가능한 코어의 수를 추상화 할 수 있다는 것입니다. – Lothar
맞습니다. CPU 바운드 작업의 경우 입력 대기열에서 읽는 n + 1 개의 스레드를 설정할 수 있습니다. 여기서 n은 코어의 수입니다. 입출력 바인딩 (I/O-bound)의 경우에는 더 많이 원할 것입니다. –
좋아, 나는 그것에 대한 더 많은 연구를했고 OS가 풀의 스레드 수에 대한 책임을지고있는 것처럼 들린다. 나는 그것이 편리하다고 생각하지만, 어떻게 그것을 조정할 것인지는 잘 모르겠습니다. I/O 블록이있을 때 n + 1 휴리스틱은 잘못 처리됩니다. –
간단히 대답하면 리소스 + 작업량 + 벤치마킹에 대해 생각해야한다는 것입니다.
여기에 일이 고장날 수있는 몇 가지 방법은 무엇입니까? 작업량이 너무 많아서 쓰레드가 완료되기까지 시간이 오래 걸리므로 다른 쓰레드가 재 할당 (즉, 작업보다 많은 쓰레드)을 기다리고 있습니다.
즉, 간단히 말해서 입력하기 전에 생각해야한다고 말하고 싶습니다. 이미 작동하는 코드가 있다면 그것은 은행에있는 돈과 같습니다. 해당 코드의 생산성을 높이기 위해 더 많은 시간을 투자 할 가치가 있거나 투자 수익 (ROI)이 너무 낮습니까?
GCD에서 찾은 링크는 다음과 같습니다. http://episteme.arstechnica.com/eve/forums?a=dl&f=174096756&x_id=mtid39095 –