알고리즘 런타임은 어떤 프로그래밍 영역에서 실제로 중요한 문제입니까?

때때로 사람들은 프로세서 속도와 사용 가능한 메모리 양 때문에 알고리즘 효율성과 런타임이 실제로 큰 문제가 아니라고 말합니다.

그러나 이러한 고려 사항이 여전히 중요한 부분이 여전히 있다고 생각합니다. 염두에 두어야 할 것은 알고리즘 거래인데, 여기서 수천 건의 트랜잭션이 순식간에 수행되어야하고 임베디드 시스템 프로그래밍은 메모리와 전력이 부족한 경우가 많습니다. 이 예제에 대해 맞습니까? 그리고 다른 어떤 영역도 예가 될 수 있습니까?

속도는 항상 요구됩니다. 당신이 맞다고 생각합니다. 다음은 깔끔한 알고리즘이 필요한 몇 가지 예입니다.

1. 암호화

2. 큰 데이터베이스 검색

3. 정렬 및 병합

4. 와일드 카드를 포함한 텍스트 검색 (인덱싱되지 않음)

5. 집중 계산의 수학 문제

6. 시뮬레이션

7. 데이터 마이닝 애플리케이션

8. 생기

9. 일체 포함

10. 컴퓨터 시각 인식

알고리즘 런타임이 그다지 중요하지 않은 경우가 있습니다. 더 강력한 하드웨어로 더 오래 실행되는 알고리즘을 간단히 뚫을 수 있기 때문입니다. 그러나 속도 향상이 필요한 곳이 분명히 있습니다.

일반적으로, 거대한 데이터 세트를 사용하는 것은 문제가 될 것입니다. n이 잘못 조정 된 것을 가지고 있고, 정말로 큰 수를 만들면 문제가있는 것입니다. 나는 당신이 Computational Science 베타 사이트를 방문하고 약간 찔렀다면, 더 빠르고 더 빠른 알고리즘이 필요한 많은 문제를 발견 할 수있을 것입니다. 내가 만난 일부 영역 :

• 특히 복잡한 통계 분석. 비효율적 인 알고리즘과 큰 데이터 세트의 조합은 엄청난 속도 저하를 의미 할 수 있습니다. 일부 연구에서는 이것이 중요하지 않을 수 있지만, 빠른 방향으로 무언가를 시도한다면 어떻게 될까요? "한 달 안에 서버에서 나올 것"은 화학 / 핵 / 생물학적 위협 감시 시스템을 실행할 때 나쁜 일일 수 있습니다.
• 대규모 데이터 세트의 데이터 마이닝
• 많은 변수를 포함한 시뮬레이션.

일반적으로 과학 컴퓨팅은 일반적으로 프로그래밍되는 프로그램의 복잡성이 알고리즘이 느린 경우 (많은 알고리즘이 n을 겪고있는 경우) 심각한 속도 저하의 기회를 생성하는 영역으로 보입니다. 그리고 언급했듯이 금융 응용 프로그램이 있습니다. 밀리 초가 거래에서 돈을 벌거나 잃을 지 여부를 결정할 수있을 때, "충분히 좋은"알고리즘은 더 좋은 일이 있다면 그것을 자르지 않을 것입니다.

때때로 사람들은 프로세서 속도와 사용 가능한 메모리 양 때문에 알고리즘 효율성과 런타임이 실제로 큰 문제가 아니라고 말합니다.

소금 한알과 함께 섭취하십시오. 더 많은 컴퓨팅 성능은 기본적으로 n이 크게 느려지기 전에 n이 훨씬 커질 수 있음을 의미합니다. 대부분의 일상적인 문제에서이 n은 이제 커질 필요가 없습니다. 그러나 알고리즘의 복잡성을 여전히 알고 있어야합니다.

사용 가능한 리소스가 많을수록 나중에 더 많은 데이터를 처리해야 할 수도 있습니다. 현재 10 만 줄의 10MB 로그 파일을 분석해야합니다. 1 년 안에 1,000,000,000 줄의 100GB 로그 파일이있을 수 있습니다. 리소스 양보다 데이터 양이 빠르게 증가하면 나중에 문제가 발생합니다.

사용 가능한 리소스가 많을수록 더 많은 레이어가 쌓입니다. OS, OS 프레임 워크, 써드 파티 프레임 워크, 언어 인터프리터, 마지막으로 자신 만의 툴. 모든 다른 계층에서 불필요한 모든 비 효율성이 증가합니다. 내일 당신의 공구는 더 많은 벨과 호루라기를 가진 새로운 OS에서 실행될 수 있습니다.

따라서 귀하의 질문에 대답하려면 더 많은 데이터를 처리 해야하는 곳 (다른 답변에 주어진 예제)과 최종 도구를 제공하지 않고 다른 도구를위한 또 다른 추상화 계층을 계속 관리해야합니다.

몇 년 전에 n랙에 배열 된 테스트 튜브 를 두 개의 별개의 파티션으로 분류하는 알고리즘을 작성해야했습니다 . 즉, 튜브의 한 서브셋은 '선택'되었고 나머지는 '선택되지 않았습니다'. 결과적으로 랙이 없습니다. 여기에는 '선택된'튜브와 '선택되지 않은'튜브가 모두 있습니다 (압축과 같은 추가 요구 사항이 있음). 각 랙에는 최대 100 개의 튜브가 있습니다.

이 알고리즘은 제약 실험실에서 튜브 정렬 로봇을 구동하는 데 사용되었습니다.

원래의 사양이 나에게 주어 졌을 때 우리는 유용성이 현명하다고 생각하기 때문에 2000 분의 튜브를 정렬하기 위해 1 분의 계산 시간 영역에 할당되었습니다. 로봇 자체가 느리기 때문에 모든 가능한 조합에서 움직임의 수가 최소화되어야한다는 요구가있었습니다 .

암시적인 가정은 튜브의 수에 따라 복잡성이 기하 급수적 일 것이라는 가정이었습니다. 그러나 알고리즘 설계 작업 을 수행하는 동안 튜브의 최적 분할을 수행 한 랙 수가 빠른 O(n)알고리즘 이 있음을 발견했습니다 n. 그 결과 알고리즘 정렬 시간이 즉각적이므로 사용자가 정렬 작업을 구성함에 따라 정렬 디스플레이가 실시간으로 업데이트됩니다.

나에게 모든 변경 후 1 분 동안 앉아 있고 즉각적으로 반응하는 GUI를 갖는 것의 차이점은 기능적으로 충분한 소프트웨어와 사용하기 편리한 소프트웨어 사이의 차이였습니다.

다른 영역으로는 많은 종류의 실시간 신호 처리, 피드백 제어 시스템, 석유 탐사 디컨 볼 루션, 비디오 압축, 광선 추적 및 영화 프레임 렌더링, 가상 현실 시스템, 높은 프레임 속도가 경쟁 우위에있는 게임, 스마트 폰 및 기타 많은 수의 CPU 사이클이 사용자의 배터리 수명을 더 빨리 소비하는 모바일 장치 앱.

Top-500 슈퍼 컴퓨터를 구축 한 이후에는이 문제를 극대화 할 수있는 연구원들의 목록이있을 수 있으며, 더 많은 컴퓨팅 파워 또는 더 나은 알고리즘으로 어떤 문제를 해결할 수 있기를 바라는 대기자 명단이있을 가능성이 매우 높습니다. (암을 해독하기 위해 일부 단백질을 접습니다.)

내 생각 같은 검색 엔진 구글 과 빙은 복잡한 알고리즘이 사용되는 가장 큰 지역 중 하나이며, 그들은 사용자에게 더 많은 유틸리티를 가져 관련성 (랭킹 페이지) 결과를 가속화하는 핵심 역할을한다.

우리는 효율적인 알고리즘을 사용하고 있기 때문에 알고리즘 효율성은 현재 주요 관심사가 아닙니다. O (n!) 알고리즘을 사용하면 모든 종류의 하드웨어에서 느려집니다.

데이터의 양이 증가함에 따라 알고리즘 복잡성이 점점 더 중요 해지고 있습니다. 다행히도 일반적인 프로그래밍 문제 (주로 검색 및 정렬)에 대한 효율적인 일반 솔루션은 거의 모든 현대 프로그래밍 언어의 표준 라이브러리에 포함되어 있으므로 일반적으로 프로그래머는 이러한 것에 대해 크게 걱정할 필요가 없습니다. 단점은 많은 프로그래머들이 후드에서 무슨 일이 일어나고 있는지와 그들이 사용하는 알고리즘의 특성이 무엇인지 전혀 모른다는 것입니다.

많은 응용 프로그램이 제대로 스트레스 테스트를 거치지 않아 특히 문제가되고 있습니다. 사람들은 작은 테스트 데이터 세트에 적합한 코드를 작성하지만 수천 배 더 많은 데이터에 직면하면 코드가 정지합니다. 데이터 세트가 커지면 열 개의 레코드에서 잘 작동하는 항목이 빠르게 폭발합니다. 실제 예 : 어떤 범주와도 연결되지 않은 항목을 정리해야하는 코드는 더 이상 3 단계 중첩 루프 (O (n ^ 3))를 사용했습니다. 테스트 데이터베이스에 10 개의 레코드 만 있으면 1000 개의 검사가 가능하며 완벽하게 수행 할 수 있으며 눈에 띄는 지연이 발생하지 않습니다. 그러나 프로덕션 데이터베이스는 약 1000 개의 행으로 빠르게 채워졌으며 갑자기 코드가 매번 10 억 건의 검사를 수행합니다.

따라서 : 아닙니다. 모든 종류의 깔끔한 알고리즘을 구현할 때의 장단점을 알 필요는 없으며 자신이 직접 발명 할 필요는 없지만 일반적인 알고리즘에 대한 기본 지식이 필요합니다. 강점과 약점은 언제, 언제 사용하지 않느냐에 따라 알고리즘 복잡성의 영향에 대해 알고 있어야하므로 어느 수준의 복잡성이 수용 가능한지 결정할 수 있습니다.

어떤 응용 프로그램 도메인이 런타임에 민감한 지에 대한 질문은 아닙니다. 어느 곳에서나 모든 프로그램은 최소한의 성능을 발휘하여 사실상 가치가 없습니다. 알고리즘 복잡성의 요점은 입력 크기가 증가함에 따라 어떻게 달라지는가입니다. 즉, 속도가 특히 중요한 영역은 현재 문제 크기뿐만 아니라 규모 의 순서를 넘어서 확장해야하는 영역 입니다.현재 문제 크기의. 프랑스 거주민의 세금 응용 프로그램을 처리하는 경우 작업이 클 수 있지만 인구 규모 또는 한 레코드를 처리하는 복잡성이 10 배 또는 100 배 증가 할 가능성은 낮습니다. 당신은 지금 계속 일할 것입니다. 당신이 인터넷 볼륨에서 벗어 무언가를 만들려고한다면, 알고리즘의 복잡성이 핵심입니다 : 더 선형 이상 또는 로그 - 선형 입력 크기에 따라 달라집니다 어떤 것 매우 빠르고 훨씬 더 비싼되고, 결국 프로세서 속도는 할 수 없습니다 성장에 발 맞추어 라.

필자의 분야 (경로 추적, 컴퓨터 애니메이션, 입자 시뮬레이션, 유체 역학, 이미지 처리 등을 다루는 VFX)에서 알고리즘 복잡성은 기본입니다. Linearithmic 시간보다 열악하게 작동하는 것은 수백만 개의 정점, 다각형, 복셀, 입자, 텍셀에 일반적으로 도달하는 입력에 대해 합리적인 시간에 완료 할 수있는 방법이 없습니다. 특히 많은 것들이 초당 몇 번 완료 해야하는 경우 실시간 대화식 피드백.

그럼에도 불구하고, 일반적으로 동료들 사이에서 논의 할 때 알고리즘 복잡성에 대한 강조는 강력하지 않습니다. 아마도 당연하고 다소 "기본적"인 것으로 여겨지기 때문일 것입니다. 일반적으로 경로 추적기를 작성하는 경우 로그 시간 이상으로 작동하고 볼륨 볼륨 계층과 같은 데이터 구조가 독자에게 구현하기에 친숙하고 비교적 사소한 것으로 가정합니다. 나는 숙련 된 동료조차도 멀티 스레딩과 SIMD가 알고리즘보다 중요하다고 말하면서도 버블 정렬의 병렬화를 많이 기대할 수 있다고 생각하지 않습니다. 그는 우리가 합리적인 알고리즘을 적용한다고 당연한 것으로 생각했기 때문에,

요즘에는 자주 익숙한 알고리즘을 많이 사용하여 CPU 캐시, SIMD 레지스터 및 명령어, GPU 및 다중 코어와 같은 하드웨어의 기본 특성을보다 잘 활용하는 데 중점을 둡니다. 예를 들어, 인텔은 익숙한 오래된 BVH를 가져 와서 "레이 패킷"이라는 개념을 생각해내는 새로운 방법을 고안했습니다. 기본적으로 재귀적인 트리 탐색으로 여러 개의 코 히어 런트 광선을 한 번에 테스트합니다. SIMD 명령 및 레지스터를 통해 광선 / AABB 및 광선 / 삼각형 교차에 대해 광선을 동시에 테스트 할 수 있다는 사실을 제외하고는 복잡성과 오버 헤드가 많이 있습니다.

컴퓨터 그래픽에서 매우 기초적인 내용 인 catmull-clark subdivision과 비슷한 것입니다. 그러나 오늘날 경쟁력이 높고 효율적이며 매우 효율적인 것은 Charles Loop가 대중화하고 나중에 Pixar가 채택한 Gregory Patches를 사용하여 CC 세분화를 근사화하는 GPU 구현입니다. 보다 간단한 CPU 구현은 이제 알고리즘 복잡성 측면에서 대체 된 것이 아니라 GPU에서 잘 작동하는 것으로 대체 되었기 때문에 이제는 더 이상 사용되지 않습니다.

그리고 그것은 요즘 하드웨어의 기본 특성과 상대적으로 독립적 인 방식으로 최고의 알고리즘을 제시하지 못하는 많은 과제입니다. 공간 인덱스가 아닌 계층 적 세분화 방식을 사용하여 90 년대에 캐릭터 및 기타 소프트 바디에 애니메이션을 적용하기위한 충돌 감지를 크게 가속화하는 새로운 가속 구조를 제공함으로써 실제로 업계에 발을 디,습니다. 구인을 제공하지만 요즘 인상적인 CPU 캐시와 여러 코어 및 프로그래밍 가능한 GPU를 갖기 오래 전에 게시 한 이후로 더 이상 인상적이지 않습니다. 요즘에는 크게 변경된 결과로 완전히 다른 접근법을 사용합니다. 기본 하드웨어.

한때 알고리즘이 일반적으로 O (n)에서 실행되는 문제에 부딪 쳤지 만, 드물고 극히 드문 상황에서는 O (n ^ 3) 시간이 필요합니다. "희귀 한"상황은 유효한 이름의 파일을 포함하는 디렉토리였습니다. 한 운영 체제이지만 다른 운영 체제에는 없습니다.

아무도 문제가 발생하지 않았습니다. 그런 다음 한 고객이 전략적으로 O (n ^ 3) 사례에 해당하는 파일의 이름을 지정했으며 몇 개의 파일이 있으면 시스템이 사실상 정지했습니다. 그 결과 알고리즘을 변경해야했습니다.

언급되지 않은 세 가지가 더 있습니다.

1) 많은 실시간 전략 게임. 위치를 공유 할 수없는 유닛이있는 것을보십시오. 대규모 그룹이 제한된 지형을 통과 할 때 길 찾기에 어떤 일이 일어나는지보십시오. 사용 가능한 CPU 전원이 충분하지 않기 때문에 아직 심각한 문제가없는 게임을 만나지 못했습니다.

2) 많은 최적화 문제. (편집 :이 답변을 쓴 후 하나를 쳤습니다. 나의 목표는 모든 노드가 연결 경로의 최소 무게로 연결되도록 중복 경로를 제거하는 것이 었습니다. 내 가지 접근 방식은 가지 치기를 더 많이 움직일 때까지 꽤 잘 작동했습니다. 그 루틴에, 나는 그것이 2 ^ n이라는 것을 깨달았습니다. 이제는 때때로 약간 최적이 아닌 결과를 생성 할 수 있지만 n ^ 2입니다.)

3) 많은 양의 데이터에 대해 실시간으로 작동해야하는 것. DVD를 고려하십시오 : 일반적으로 4.7gb에서 2 시간 분량의 비디오를 얻습니다. 동일한 해상도의 일반적인 비디오 파일을 고려하십시오. 2 시간 분량의 비디오는 일반적으로 1GB 미만으로 제공됩니다. 그 이유는 DVD 사양이 내려 졌을 때 더 현대적인 형식을 충분히 빨리 해독 할 수있는 합리적인 가격의 DVD 플레이어를 만들 수 없었기 때문입니다.

일반적으로 슈퍼 컴퓨터 ( 가장 큰 컴퓨터 목록)에서 실행되는 모든 응용 프로그램이 적합합니다. 이것들은 다양하지만 물리 시뮬레이션은 큰 하위 클래스입니다.

• 물리 시뮬레이션 :
  • 일기 예보
  • 기후 시뮬레이션
  • 폭발하는 별 등의 시뮬레이션
  • 폭발 핵의 시뮬레이션
  • 자동차 / 비행기 / 기차 등의 공기 역학적 시뮬레이션
  • ...
• 전파 망원경 데이터에서 이미지 계산
• 생물학적 응용 :
  • DNA 서열을 가진 것들 (나는 정말로 그것들에 속하지 않습니다)
  • 단백질 폴딩과 같은 생화학 물질
  • 신경 세포가 정보를 처리하기 위해 함께 작동하는 방법의 시뮬레이션
  • 생태계와 같은 다른 복잡한 상호 작용의 시뮬레이션
  • ...
• ...

이것들은 저의 머리 주제 중 가장 중요한 것이지만 다른 수퍼 컴퓨터의 목록을 읽고 이들 각각이 그러한 거대한 기계 없이는 불가능한 어떤 종류의 계산을 가능하게하도록 만들어 졌음을 깨달으십시오.

그리고 실제로 이러한 머신이 필요하다는 것을 알게 되면 애플리케이션 속도를 10 % 향상시켜 비용을 절감 할 수 있습니다 . 이러한 코드를 최적화하면 이러한 시스템에서 얻을 수있는 결과의 양이 직접 증가합니다.