현재 업계 시나리오에서 멀티 스레딩이 얼마나 중요한지 궁금해졌습니다.
퍼포먼스를 수행하는 타사 코드에서 성능이 나오지 않지만 자체적으로 성능이 중요한 성능 핵심 분야에서는 CPU 관점에서 중요도가 높은 순서로 고려하는 경향이 있습니다 (GPU는 내가 얻은 와일드 카드입니다) 들어 가지 않음) :
- 메모리 효율성 (예 : 참조 지역).
- 알고리즘
- 멀티 스레딩
- SIMD
- 기타 최적화 (예 : 정적 분기 예측 힌트)
이 목록은 전적으로 중요도에 근거한 것이 아니라 유지 관리에 미치는 영향, 얼마나 직접적인지 (사전 더 고려할 가치가있는 경우), 목록에있는 다른 사람과의 상호 작용 등과 같은 많은 다른 역학에 근거합니다.
메모리 효율
알고리즘보다 메모리 효율성 선택에 놀랐을 것입니다. 메모리 효율성이이 목록에있는 4 개의 다른 모든 항목과 상호 작용하기 때문이며,이를 고려하면 종종 "구현"범주가 아닌 "디자인"범주에 있기 때문입니다. 기억력 효율성을 이해하려면 종종 목록에있는 4 가지 항목을 모두 고려해야하고 다른 4 가지 항목 모두도 메모리 효율성을 고려해야하기 때문에 약간의 닭고기 나 달걀 문제가 있습니다. 그러나 그것은 모든 것의 중심에 있습니다.
예를 들어, 선형 시간 순차 액세스 및 등 시간에 일정한 시간 삽입을 제공하는 데이터 구조가 필요하고 작은 요소에 대해서는 그 밖의 어떤 것도 필요하지 않은 경우, 여기서 도달하려는 순진한 선택은 링크 된 목록이됩니다. 그것은 메모리 효율성을 무시하고 있습니다. 혼합에서 메모리 효율성을 고려할 때,이 시나리오에서는 확장 가능한 배열 기반 구조 또는 연속 된 노드 (예 : 노드에 128 개의 요소를 저장하는 노드)와 같이 또는 서로 연결된 것과 같이보다 연속적인 구조를 선택하게됩니다. 풀 할당자가 지원하는 링크 된 목록 이들은 알고리즘 복잡성이 동일하지만 극적인 이점을 가지고 있습니다. 마찬가지로, 우리는 종종 메모리 효율성 때문에 열등한 알고리즘 복잡성에도 불구하고 병합 정렬보다 배열의 빠른 정렬을 종종 선택합니다.
마찬가지로 메모리 액세스 패턴이 너무 세분화되고 흩어져서 가장 세밀한 수준의 코드로 잠금을 설정하는 동안 허위 공유의 양을 최대화하면 효율적인 멀티 스레딩을 가질 수 없습니다. 따라서 메모리 효율성은 효율성 멀티 스레딩을 배가시킵니다. 스레드를 최대한 활용하기위한 전제 조건입니다.
목록의 위의 모든 단일 항목은 데이터와 복잡한 상호 작용을하며 데이터가 표현되는 방식에 초점을 맞추는 것은 궁극적으로 메모리 효율성의 맥락에 있습니다. 위의 모든 하나는 부적절한 데이터 표현 또는 액세스 방법으로 병목 현상이 발생할 수 있습니다.
메모리 효율성이 중요한 또 다른 이유는 전체 코드베이스에 적용 할 수 있기 때문 입니다. 일반적으로 사람들이 여기저기서 약간의 작업에서 비효율이 축적된다고 생각할 때 프로파일 러를 가져와야한다는 신호입니다. 그러나 지연 시간이 짧은 필드 나 매우 제한된 하드웨어를 다루는 필드는 프로파일 링 후에도 할당, 복사 및 할당 방식에있어 비효율적 인 코드베이스에서 명확한 핫스팟 (시간이 어디에나 분산되어 있음)을 나타내지 않는 세션을 실제로 찾을 수 있습니다. 메모리에 액세스합니다. 일반적으로 이것은 전체 코드베이스가 코드베이스 전체에 적용되는 완전히 새로운 표준 세트로 이어질 수있는 성능 문제에 취약 할 수있는 유일한시기이며, 메모리 효율성은 종종 그 중심에 있습니다.
알고리즘
정렬 알고리즘의 선택은 정렬하는 데 몇 개월이 걸리고 정렬하는 데 몇 초가 걸리는 거대한 입력 사이의 차이를 만들 수 있기 때문에 이것은 상당히 주어진 것입니다. 적어도 1,000,000 개의 코어 머신 (어떤 경우에는 메모리가 효율성이 더욱 중요해질 것입니다).
그러나 내 개인 목록의 최상위에 있지는 않습니다. 분야에서 유능한 사람은 절두체 컬링을 위해 가속 구조를 사용하는 것을 알고 있기 때문에 알고 있습니다. 예를 들어 알고리즘 지식에 포화되어 있으며 접두사 기반 검색을위한 기수 트리는 유아용 물건입니다. 우리가 작업하는 분야에 대한 이런 종류의 기본 지식이 없기 때문에 알고리즘 효율은 확실히 최고가 될 것입니다. 그러나 종종 알고리즘 효율은 사소합니다.
또한 일부 분야에서는 새로운 알고리즘을 개발해야 할 수도 있습니다 (예 : 메시 처리에서는 이전에는 없었거나 다른 제품의 유사한 기능 구현이 독점적 인 비밀이며 종이로 출판되지 않았기 때문에 수백 개를 발명해야했습니다) ). 그러나 문제 해결 부분을 지나서 올바른 결과를 얻을 수있는 방법을 찾고 효율성이 목표가되면 실제로 얻는 유일한 방법은 데이터 (메모리)와의 상호 작용 방식을 고려하는 것입니다. 메모리 효율성을 이해하지 못하면 새로운 알고리즘은 더 빠른 속도로 만들기위한 불필요한 노력으로 불필요하게 복잡해질 수 있습니다. 단순하고 우아한 알고리즘을 생성하기 위해 메모리 효율성을 조금 더 고려하는 것이 필요할 때였습니다.
마지막으로, 알고리즘은 메모리 효율보다 "구현"범주에 더 많은 경향이 있습니다. 초기에 사용 된 차선책 알고리즘을 사용하더라도 후시를 개선하기가 더 쉽습니다. 예를 들어, 열등한 이미지 처리 알고리즘은 종종 코드베이스의 한 곳에서 구현됩니다. 나중에 더 좋은 것으로 바꿀 수 있습니다. 그러나 모든 이미지 처리 알고리즘이 Pixel차선의 메모리 표현 을 가진 인터페이스에 연결되어 있지만이를 해결하는 유일한 방법은 여러 픽셀이 표시되는 방식 (단 하나가 아님)을 변경하는 것입니다. SOL을 위해 코드베이스를 완전히 다시 작성해야합니다.Image인터페이스. 정렬 알고리즘을 대체 할 때도 같은 종류의 작업이 필요합니다. 일반적으로 구현 세부 사항이며 정렬되는 데이터의 기본 표현을 완전히 변경하거나 메시지를 전달하는 방식에 따라 인터페이스를 다시 디자인해야 할 수도 있습니다.
멀티 스레딩
멀티 스레딩은 하드웨어 특성에 따라 마이크로 레벨 최적화를 수행하기 때문에 성능 측면에서 어려운 문제이지만 하드웨어는 실제로 그 방향으로 확장되고 있습니다. 이미 32 개의 코어를 가진 피어가 있습니다 (4 개만 있습니다).
그러나 뮬리 스레딩은 소프트웨어 속도를 높이기 위해 목적을 사용하는 경우 전문가에게 알려진 가장 위험한 마이크로 최적화 중 하나입니다. 경쟁 조건은 본질적으로 매우 결정적이지 않기 때문에 가능한 가장 치명적인 버그입니다. (아마도 디버깅 컨텍스트 외부에서 가장 불편한 시간에 개발자의 컴퓨터에서 몇 개월에 한 번만 나타날 수 있습니다). 따라서 멀티 스레딩과 관련된 버그는 가장 신중한 테스트조차도 쉽게 레이더 할 수 있기 때문에 유지 보수성 및 코드의 잠재적 정확성에 대한 부정적인 부정적인 영향을 미쳤습니다.
그럼에도 불구하고 그렇게 중요 해지고 있습니다. 현재 보유하고있는 코어 수를 고려할 때 메모리 효율성 (때로는 수백 배 더 빨라질 수 있음)과 같은 것을 능가하는 것은 아니지만, 점점 더 많은 코어를보고 있습니다. 물론 100 코어 머신을 사용하더라도 스레드 효율성은 일반적으로 불가능하기 때문에 메모리 효율성을 목록의 최상위에두고 있습니다. 프로그램은 이러한 머신에서 수백 개의 스레드를 사용할 수 있지만 효율적인 메모리 표현 및 액세스 패턴 (잠금 패턴과 연결됨)이 여전히 부족합니다.
SIMD
SIMD는 레지스터가 실제로 더 넓어지고 더 넓어 질 계획이기 때문에 조금 어색합니다. 원래 64 비트 MMX 레지스터와 4 개의 SPFP 연산을 동시에 병렬 처리 할 수있는 128 비트 XMM 레지스터가있었습니다. 이제 우리는 병렬로 8 개가 가능한 256 비트 YMM 레지스터를보고 있습니다. 그리고 16 비트를 병렬로 허용하는 512 비트 레지스터에 대한 계획이 이미 마련되어 있습니다.
이것들은 멀티 스레딩의 효율성과 상호 작용하고 증가 할 것입니다. 그러나 SIMD는 멀티 스레딩만큼 유지 관리 성을 떨어 뜨릴 수 있습니다. 이와 관련된 버그가 교착 상태 또는 경쟁 조건만큼 재생산 및 수정이 반드시 어려운 것은 아니지만 이식성이 어려우며 모든 사람의 컴퓨터에서 코드를 실행할 수 있는지 (및 하드웨어 기능에 따라 적절한 지침을 사용하여) 어색한.
또 다른 것은 오늘날 컴파일러가 일반적으로 전문가가 작성한 SIMD 코드를이기는 것은 아니지만 순진한 시도를 쉽게이기는 것입니다. 그것들은 우리가 더 이상 수동으로 할 필요가 없거나 적어도 본질적으로 또는 직접 어셈블리 코드를 작성하는 것에 대해 수동으로하지 않아도 될 정도로 향상 될 수 있습니다 (아마도 약간의 사람의 안내).
그러나 벡터화 처리에 효율적인 메모리 레이아웃이 없으면 SIMD는 쓸모가 없습니다. 우리는 하나의 스칼라 필드를 와이드 레지스터에로드하여 하나의 연산 만 수행합니다. 이러한 모든 항목의 핵심은 메모리 레이아웃에 대한 의존성이 진정 효율적입니다.
다른 최적화
이것들은 종종 단어가 알고리즘 중심을 넘어서 성능에 미미한 영향을 미치는 변화를 제안한다면, 우리가 요즘 "마이크로"라고 부르기를 제안하는 것입니다.
분기 예측을 최적화하기 위해 종종 알고리즘 또는 메모리 효율의 변화가 필요합니다. 예를 들어 정적 예측을위한 힌트 및 코드 재 배열을 통해서만 시도되는 경우, 그러한 코드의 최초 실행 만 향상시키는 경향이있어 효과가 의심스러운 경우 종종 무시할 만하지 않습니다.
성능을 위해 멀티 스레딩으로 돌아 가기
어쨌든 성능 컨텍스트에서 멀티 스레딩이 얼마나 중요합니까? 내 4 코어 머신에서는 이상적으로 5 배 더 빨라질 수 있습니다 (하이퍼 스레딩으로 얻을 수있는 것). 코어가 32 개인 동료에게 훨씬 더 중요합니다. 그리고 앞으로 몇 년 동안 점점 더 중요해질 것입니다.
매우 중요합니다. 그러나 메모리 효율성이 부족하여 잠금을 거의 사용하지 않고 허위 공유 등을 줄이기 위해 문제가 발생하는 경우 많은 스레드를 던지는 것은 쓸모가 없습니다.
성능 이외의 멀티 스레딩
멀티 스레딩이 단순한 처리량의 의미에서 항상 성능을 향상시키는 것은 아닙니다. 때로는 가능한 처리량 비용으로도로드 밸런싱을 통해 사용자의 응답 성을 향상 시키거나 사용자가 완료 될 때까지 기다리지 않고 더 많은 멀티 태스킹을 수행 할 수 있습니다 (예 : 파일을 다운로드하는 동안 계속 탐색).
이러한 경우, 멀티 스레딩은 하드웨어를 최대한 활용하는 것이 아니라 사용자 엔드 디자인에 관한 것이기 때문에 메모리 효율이 더 높은 최고 수준으로 올라갈 것을 제안합니다. 인터페이스 디자인과 그러한 시나리오에서 전체 코드베이스를 구성하는 방식을 지배하는 경우가 많습니다.
방대한 데이터 구조에 액세스하는 타이트한 루프를 단순히 병렬화하지 않을 경우 멀티 스레딩은 실제로 하드 코어 "디자인"범주로 이동하고 디자인은 항상 구현보다 우선합니다.
따라서 이러한 경우 멀티 스레딩을 미리 고려하는 것이 메모리 표현 및 액세스보다 훨씬 중요하다고 말하고 싶습니다.