플롭 카운팅에 의한 알고리즘 분석은 더 이상 사용되지 않습니까?

수치 분석 과정에서 문제의 크기에 따라 필요한 부동 소수점 연산 (플롭) 수를 계산하여 알고리즘의 효율성을 분석하는 방법을 배웠습니다. 예를 들어, Numerical Linear Algebra에 관한 Trefethen & Bau의 텍스트에는 플롭 카운트에 대한 3D 모양의 그림도 있습니다.

캐시에없는 것을 가져 오기위한 메모리 대기 시간이 플롭 비용보다 훨씬 크기 때문에 "플롭이 비어있다"고 말하는 것이 유행입니다. 그러나 우리는 여전히 최소한 수치 분석 과정에서 학생들에게 플롭을 세도록 가르치고 있습니다. 대신 메모리 액세스를 계산하도록 그들에게 가르쳐야합니까? 새로운 교과서를 작성해야합니까? 아니면 메모리 액세스가 너무 머신별로 시간을 소비합니까? 플롭 또는 메모리 액세스가 병목 현상인지 여부와 관련하여 장기 추세는 무엇입니까?

참고 : 아래 답변 중 일부는 "몇 가지 플롭을 저장하거나 캐시 성능을 향상시키기 위해 구현을 강박 적으로 다시 작성해야합니까?"와 같은 다른 질문에 대답하는 것 같습니다. 그러나 내가 묻는 것은 " 산술 연산이나 메모리 액세스 측면에서 알고리즘의 복잡성을 추정하는 것이 더 유용한가 ?"

내가 할 수있는 (첫 번째 순서) 옳은 일을 내가 전화 알고리즘에 필요한 바이트 플롭의 비율, 봐 생각 . 하자 F가 있어요 X가 최대 플롭 프로세서의 속도,되고 B의 m X 최대 대역폭. 하면 F가 있어요 $\beta$$F_{\mathrm{max}}$$B_{\mathrm{max}}$이면 알고리즘은 대역폭이 제한됩니다. 경우B의mXβ>F가있어요X를, 알고리즘은 한정 플롭이다.$\frac{F_{\mathrm{max}}}{\beta} > B_{\mathrm{max}}$$B_{\mathrm{max}}\beta > F_{\mathrm{max}}$

메모리 액세스 수를 세는 것이 필수적이라고 생각하지만 다음 사항도 고려해야합니다.

• 필요한 로컬 메모리 양

• 가능한 동시성

그런 다음 최신 하드웨어에 대한 알고리즘 분석을 시작할 수 있습니다.

$O(N^4)$$O(N)$$O(N \log N)$$O(N^2)$

더 넓은 관점에서, 알고리즘 성능의 분석은 "모두 포함"해야한다고 생각합니다. 사람들에게 실제 HPC 개발자 및 사용자가되도록 가르치는 경우 실제 프로그래밍 비용이 무엇인지 이해해야합니다. 우리가 프로그래머의 시간을 고려하지 않은 추상 분석 모델. 우리는 단지 플롭 카운트와 알고리즘 효율성보다는 "총 해결 시간"이라는 관점에서 생각해야합니다. 몇 백만 번의 계산을 계획하지 않는 한, 작업 당 1 초의 컴퓨터 시간을 절약 할 수있는 루틴을 다시 작성하는 데 3-4 일의 프로그래머가 소요되는 것이 타당하지 않습니다. 마찬가지로, 1 ~ 2 시간의 컴퓨팅 시간을 절약하기위한 며칠의 투자가 빠르게 효과를 발휘합니다. 이 새로운 알고리즘은 놀랍습니다.

다른 사람들이 지적했듯이 병목 현상이 CPU인지 메모리 대역폭인지에 따라 대답이 달라집니다. 임의 크기의 데이터 집합에서 작동하는 많은 알고리즘의 경우 병목 현상은 일반적으로 데이터 집합이 CPU 캐시에 맞지 않기 때문에 메모리 대역폭입니다.

또한 Knuth는 메모리 액세스 분석이 최신 CPU 파이프 라인 및 분기 예측의 복잡성에 비해 비교적 단순하기 때문에 (캐시 친 화성을 고려하더라도) 시간 테스트를 견뎌 낼 가능성이 높다고 언급합니다.

Knuth는 BDD 를 분석 할 때 TAOCP 의 Volume 4A에서 gigamems 라는 용어를 사용합니다 . 그가 이전 볼륨에서 사용하는지 확실하지 않습니다. 그는 2010 년 연례 크리스마스 트리 강의에서 시간 테스트에 대한 언급을했습니다.

흥미롭게도, 당신은 잘못하고 있음을 보여줍니다. 데이터가 물리적 RAM에 한 번에 맞지 않으면 VM 압력과 같은 요소가 작용하기 때문에 메모리 작업을 기반으로 한 성능 분석조차 항상 간단하지는 않습니다.

알고리즘 비용을 결정하는 방법은 작업하는 "컴퓨팅"의 "수준"과 고려할 문제의 범위에 따라 다릅니다.

캐시 최적화를 생각하면 BLAS 및 유사한 라이브러리와 같은 수치 선형 대수 패키지의 구현과 관련이 있습니다. 따라서 이것은 저수준 최적화에 속하며 특정 문제에 대한 고정 알고리즘이 있고 입력에 충분한 제약 조건이 있으면 좋습니다. 예를 들어, 캐시 최적화는 매트릭스가 충분히 희소 한 것으로 약속 될 경우 켤레 그라디언트 반복의 빠른 구현과 관련이있을 수 있습니다.

반면에 문제의 종류가 넓을수록 실제 컴퓨팅에 대한 예측이 적어집니다 (예를 들어 CG 구현의 입력 행렬이 얼마나 드문 지 알지 못함). 프로그램이 실행될 컴퓨터의 클래스가 넓을수록 캐시 아키텍처에 대한 예측이 줄어 듭니다.

또한 과학적 컴퓨팅 수준이 높을수록 문제 구조를 변경하는 것이 더 적합 할 수 있습니다. 예를 들어, 선형 방정식 시스템에 적합한 전제 조건을 찾는 데 시간을 투자하면 반복 횟수가 크게 줄어들 기 때문에 이러한 최적화는 일반적으로 모든 하위 수준 최적화보다 우선합니다.

결론적으로, 캐시 최적화는 병렬화 및 점근 수의 FLOP 수를 줄여 최적화 할 항목이없는 경우에만 유용합니다.

이론적 인 컴퓨터 과학의 입장을 채택하는 것이 현명하다고 생각합니다. 결국 알고리즘의 복잡성 향상은 기존의 일부 코드 라인의 미세 최적화보다 더 많은 수익을 가져옵니다. 따라서 FLOP 계수는 여전히 선호됩니다.

나는 항상 플롭, 메모리 액세스 또는 당신이 가지고있는 것을 계산하는 것을 거부했습니다. 그것은 당신이 한 일이 꽤 많이 주어 졌을 때 1960 년대의 개념이며, 당신이 한 일만이 알고리즘 최적화에 달려있었습니다. Jacobi 반복의 가우시안 제거를 사용하여 균일 한 xyz 메시에서 유한 요소 문제를 해결해보십시오.

이제이를 최적화하여 몇 번의 플롭을 저장하여 런타임의 10 %를 확보 할 수 있습니다. 또는 멀티 그리드 방법과 최적의 블록 전제 조건을 구현하여 런타임에서 10 배를 달성 할 수 있습니다. 이것이 우리가 학생들에게해야 할 일입니다. 더 복잡한 내부 알고리즘을 찾는 것보다 복잡한 외부 알고리즘이 어떤 이점을 얻을 수 있는지 생각해보십시오. 당신의 상사 (키)는 MHD 계산 과정 에서이 슬라이드를 분명히 지적합니다.

예, 쓸모 없습니다. 플롭 또는 다른 방법에 의한 알고리즘 분석은 현재 문제의 크기를 고려할 때 기계의 추상적 모델만큼 유용합니다. 실제 성능은 구현 및 하드웨어에 따라 달라지며, 후자의 실제 모델에 대한 적용 가능성은 시간이 지남에 따라 감소합니다. 예를 들어 분자 역학과 같은 복잡한 알고리즘의 구현을 더욱 병렬화 할 때 서로 다른 측면이 서로 다른 하드웨어에서 속도를 제한하며 알고리즘 분석은 관측과 아무런 관련이 없습니다. 어떤 의미에서, 유일한 중요한 것은 문제의 하드웨어 유형에 대한 알고리즘의 구현 성능을 측정하는 것입니다.

그러한 추상화는 학습 도구로 유용합니까? 예, 가르치는 데 사용되는 많은 모델과 마찬가지로 모델의 한계에 대한 이해와 함께 배치되는 한 유용합니다. 고전적인 역학은 거리가 좁거나 속도가 큰 스케일에서는 작동하지 않는다는 점을 알고 있다면 괜찮습니다 ...

실제로 질문에 대답하는 것이 아니라 고려해야 할 다른 변수를 더 추가하는 것 : 고려해야 할 것은 프로그래밍 언어의 기능입니다. 예를 들어, 파이썬 sort은 Timsort 알고리즘을 사용합니다. Timsort 알고리즘은 다른 훌륭한 속성 중에서도 비교 횟수를 최소화하도록 설계되었으며, 파이썬 객체의 경우 잠재적으로 느려질 수 있습니다. 반면에 C ++에서 두 개의 부동 소수점을 비교하는 것은 빠르지 만 교환하는 데 비용이 많이 들기 때문에 다른 알고리즘 을 사용 합니다.

다른 예로는 동적 메모리 할당 (파이썬 목록에서는 간단하고 런타임과 개발자 시간 모두에서 빠르다 .append())과 FORTRAN 또는 C가 있습니다. 참조 파이썬은 빠른 FORTRAN보다.