과학 소프트웨어는 얼마나 최적화해야합니까?

상당한 계산 리소스가 필요한 응용 프로그램의 경우 과학적 결과를 제공하거나 합리적인 시간에 "획기적인"달성을 위해서는 고성능이 중요한 요소가 될 수 있습니다.

소프트웨어 개발자가 애플리케이션 최적화에 얼마나 많은 시간과 노력을 투자해야합니까? 사용 된 주요 기준은 무엇입니까?

대부분의 경우 알고리즘 개선은 최적화 개선보다 더 큰 차이를 만듭니다. 알고리즘은 또한 저수준 최적화보다 이식성이 뛰어납니다. 필자의 조언은 캐시 재사용을위한 메모리 레이아웃, 과도한 복사 또는 통신 방지, 파일 시스템을 깔끔하게 처리하고 부동 소수점 커널이 벡터화에 충분한 세분성을 갖도록하는 일반적인 모범 사례를 따르는 것입니다. 때때로 이것은 충분히 큰 "피크"에 도달하기에 충분합니다 (이 작업의 경우).

중요하다고 생각하거나 프로파일 링을 통해 중요하다고 생각되는 작업에 대한 성능 모델을 항상 스케치하십시오. 그런 다음 성능 모델을 사용하여 고도로 조정 된 구현이 제공 할 수있는 것을 추정 할 수 있습니다. 속도 향상이 그만한 가치가 있다고 판단한 경우 (다른 작업에 비해) 최적화를 수행하십시오.

아마도 가장 어려운 과제는 API를 변경하지 않고도 나중에 최적화 할 수 있도록 높은 수준의 중요하고 (많은 코드가 이러한 선택에 의존한다는 의미에서) 인터페이스 및 데이터 구조를 설계하는 것입니다. 특정 최적화 및 일반적인 지침과 달리 경험을 제외하고 이것을 가르치는 방법을 모르겠습니다. 성능에 민감한 오픈 소스 소프트웨어를 사용하면 도움이됩니다. API 결정과 마찬가지로 문제 공간을 이해하는 것이 중요합니다.

"최적화"를 어떻게 정의 하시겠습니까? 더 나은 알고리즘 또는 계산 모델 개발에서 수동 튜닝 어셈블러 사용에 이르기까지 전체 스펙트럼이 있습니다.

내 의견과 경험에 따르면, 낮은 컴퓨터 성능은 중간 컴퓨터 어딘가에 있습니다. 알고리즘이 반드시 새로운 것은 아니며 기본 아키텍처에 대한 이해가 반드시 구체적 일 필요는 없습니다. 예 :

• 아키텍처가 SIMD를 지원한다는 것을 알고 있다면 계산을 재구성하여 짧은 벡터로 작업을 작성할 수 있습니다.
• 아키텍처가 멀티 코어 컴퓨터라는 것을 알고 있다면 계산 작업을 서로 방해하지 않는 개별 하위 작업으로 분류하고 병렬로 실행하십시오 (하위 작업의 DAG 생각). ,
• 기본 아키텍처에 GPU가있는 경우 데이터를 잠금 단계로 행진하는 스레드 그룹으로 계산을 재구성 할 수있는 방법을 생각하십시오.
• 기타...

SIMD, 병렬 처리 및 GPU와 같은 위의 모든 기능은 많은 저수준 지식 없이도 액세스 할 수 있지만,이를 쉽게 활용할 수있는 알고리즘의 장점 만 제공합니다.

나는 지금까지 제시된 모든 답변에 동의합니다 ... 코드 최적화의 간과 한 가지 측면 인 품질 기대를 다루고 싶습니다.

코드 최적화 문제는 일반적으로 사용자가 더 큰 문제를 해결하려고 시도하고 사용자의 요구 / 예상을 충족시키기에 코드가 부족한 경우에 발생합니다. 코드 최적화에 투자해야하는 시간은이 기대를 충족시키기위한 요구에 달려 있습니다. 경쟁 우위에 대한 중요한 요구가있는 경우 (예 : 다른 사람보다 먼저 뜨거운 주제에 대한 연구 마무리 및 게시) 상당한 시간을 투자 할 가치가 있습니다.

물론 얼마나 많은 시간을 투자해야하는지, 얼마나 빨리 필요한지, 코드를 얼마나 이식 할 수 있는지에 달려 있습니다. 종종이 두 가지 요구가 서로 상충되므로 최적화를 시작하기 전에 어느 것이 더 중요한지를 결정해야합니다. 이식성이 좋을수록 코드의 높은 수준의 설계 변경 (알고리즘 / 데이터 구조)에 더 의존해야합니다. 코드가 더 빨리 수행되기를 원하는 경우 특정 머신에 특정한 낮은 수준의 최적화 (예 : 코드 / 컴파일러 / 런타임 최적화)로 조정해야합니다.

실행 속도를 얻는 데 많은 인 월 지출 (그리고 항상 신화적인 :-) 지출에 대한 (비용) 분석을해야합니다. 이 소프트웨어를 몇 번이나 사용할지, 그리고 얼마나 많은 사람들이 이득을 평가할 수 있는지 알아 내야합니다.

경험과 마찬가지로 경험상 유명한 80/20 규칙이 있습니다. 언젠가는 몇 퍼센트 (또는 적은)의 러닝 타임을 얻기 위해 점점 더 많은 시간을 소비하지 않습니다. 그러나 분석해야합니다.

그리고 위의 포스터에 진심으로 동의합니다 .API를 잘 생각하고 많은 변경이 필요하지 않으며 코드를 이식 가능하고 유지 관리 할 수 ​​있는지 확인하십시오 (작성한 알고리즘을 다시 분석해야한다는 점을 생각하십시오) 10 년 전에 최적화 됨). 그리고 좋은 프로그래밍 실습과 표준 라이브러리를 사용하십시오. 누군가가 이미 응용 프로그램에 가장 효율적인 알고리즘에 대해 생각한 것은 합리적입니다.

도널드 크 누스 (Donald Knuth)를 인용하자면 : "조기 최적화는 모든 악의 근원"입니다. 따라서 코드를 프로파일 링하십시오.

몇 가지 추가 조언 :

1. 작동중인 프로그램을 최적화하기 전에 코드의 무결성을 유지하는 데 도움이되는 일련의 테스트 사례가 있는지 확인하십시오. 더 이상 잘못된 결과를 얻는 데 아무런 의미가 없습니다.
2. 최적화로 코드를 읽을 수 없게 만드는 경우 최소한 주석 형식으로 원본 버전을 유지하지만 컴파일 타임과 런타임에 대체 버전으로 선택하는 것이 좋습니다. 문제와 기계가 발전함에 따라 최적화 요구 사항이 변경 될 수 있으며, 원래 코드는 5 년 후에 수행 할 최적화의 시작점이 될 수 있습니다.
3. 최적화 된 버전이 최소한의 영향을 미치는 것으로 판명되었지만 코드의 가독성, 보편성이 떨어지거나 안정성이 떨어지면 원래 버전으로 돌아갑니다. 당신은 당신이 얻는 것보다 더 많은 것을 잃습니다.