두 알고리즘을 비교하기 위해 런타임 대신 비교를 사용하는 이유는 무엇입니까?


19

몇 개의 CS 연구 논문에서 두 알고리즘의 효율성을 비교하기 위해 실제 컴퓨팅 시간 자체가 아닌 알고리즘의 총 키 비교 수가 사용됩니다. 두 프로그램을 모두 실행하고 알고리즘을 실행하는 데 필요한 총 시간을 계산하여 어느 것이 더 나은지 비교할 수없는 이유는 무엇입니까?


어서 오십시오! 그런 논문이 대부분 런타임을 사용하지 않기를 바랍니다 . 그러나 특히 응용 프로그램이 많은 커뮤니티와 고려되는 시스템이 매우 복잡한 경우에는 일부 작업이 필요하다는 것을 알고 있습니다.
Raphael

답변:


14

이것은 실제로 몇 가지 방법론적이고 실용적인 답변이있는 깊은 문제입니다. 알고리즘 에 대해 알고 싶다고 가정합니다 . 주어진 입력에서 주어진 시스템에서 어떤 알고리즘이 더 잘 작동하는지 알고 싶다면 런타임을 측정하십시오. 주어진 알고리즘에 대한 컴파일러의 품질을 비교하려면 런타임을 측정하십시오. 알고리즘에 대해 배우려면하지 마십시오.

먼저 런타임을 사용하는 것이 좋지 않은 이유를 몇 가지 설명하겠습니다.


  1. 하나의 언어와 하나의 컴퓨터에서 하나의 컴파일러를 사용하여 측정 한 일반 런타임은 구성 요소를 변경해도 의미가 거의 없습니다. 경우에 따라 일부 컴파일러 최적화를 트리거하지만 다른 알고리즘에서는 그렇지 않기 때문에 동일한 알고리즘을 약간 다르게 구현해도 다르게 수행 될 수 있습니다.
  2. 예측
    따라서 일부 입력에 대한 몇 가지 런타임이 있습니다. 다른 입력의 런타임에 대해 무엇을 알려 줍니까? 일반적으로 아무것도 없습니다.
  3. 중요성
    일반적으로 모든 입력 (일부 크기)을 벤치마킹하지 않으므로 알고리즘을 비교할 수있는 기능이 즉시 제한됩니다. 테스트 세트가 최악의 경우를 트리거하고 다른 알고리즘의 최고를 트리거했을 수 있습니까? 또는 입력이 너무 작아 런타임 동작을 나타내지 않을 수도 있습니다 .
  4. 계량
    측정 런타임을 측정하는 것은 쉽지 않습니다. JIT가 있습니까? 경합이 있었습니까? 즉 알고리즘이 실행되지 않은 시간을 세고 있습니까? 다른 실행 (다른 알고리즘의), 특히 동시 프로세스 및 캐시에 대해 정확히 동일한 머신 상태를 재현 할 수 있습니까? 메모리 대기 시간은 어떻게 처리됩니까?

나는 이것이 런타임이 알고리즘을 비교하는 끔찍한 척도이며 알고리즘 런타임을 조사하기위한 일반적인 추상 방법이 필요하다는 것을 확신 해주기를 바랍니다.

질문의 두 번째 부분으로 넘어갑니다. 왜 우리는 비교 또는 유사한 기본 연산을 사용합니까?

  1. 분석적 견인 성
    공식적인 분석을 원한다고 가정 할 수 있어야 합니다. 개별 진술을 계산하는 것은 매우 기술적이며 때로는 어려운 경우도 있습니다. 그럼에도 불구하고 어떤 사람들은 그것을한다 (예 : 크 누스). 런타임 을 지배 하는 명령문 만 계산하는 것이 더 쉽습니다. 같은 이유로, 우리는 종종 최악의 런타임을 조사 만합니다 (상한).

  2. 지배
    선택한 작업 런타임을 지배 합니다. 그렇다고해서 단어 크기의 정수를 정렬 할 때 Quicksort와 같은 비교는 명확하지 않습니다. 그러나 그것들은 가장 자주 실행 되므로, 그것들을 계산함으로써 알고리즘에서 가장 많이 실행 된 부분이 얼마나 자주 실행되는지 계산합니다. 결과적으로 점근 적 런타임은 지배적 인 기본 작업의 수에 비례합니다. 우리가 비교 만 계산하더라도 Landau 표기법과 "런타임"이라는 단어를 사용하는 것이 편한 이유입니다.

하나 이상의 작업을 계산하는 것이 유용 할 수 있습니다. 예를 들어, 일부 Quicksort 변형은 다른 것보다 더 많은 비교를 수행하지만 스왑은 적습니다 (평균).

가치있는 것을 위해, 모든 이론을 다 수행 한 후 이론이 만든 예측이 올바른지 확인하기 위해 런타임을 다시 방문 할 수 있습니다. 그렇지 않은 경우 이론은 실용적이지 않으며 확장되어야합니다. 메모리 계층 구조는 가장 중요하지만 기본 분석에서는 누락 된 것 중 하나입니다.


1
공식적인 분석에도 한계가 있음을 명심하십시오. 예를 들어, 균일하지 않은 입력 분포의 평균 사례는 종종 다루기 힘든 경우가 많습니다.
Raphael

10

이는 알고리즘을 실행하는 데 걸리는 총 시간이 다른 요인과 함께 실행되는 하드웨어에 의존하기 때문입니다. 하나는 Pentium 4에서 실행되고 다른 하나는 Core i7에서 실행되는 경우 두 알고리즘을 비교하는 것은 신뢰할 수 없습니다. 이뿐 만 아니라 동일한 컴퓨터에서 둘 다 실행했다고 가정 해 봅시다. 둘 다 같은 시간의 프로세서 시간을 가지고 있다는 말은 무엇입니까? 다른 프로세스가 알고리즘 중 하나의 프로세스보다 우선 순위가 높은 경우 어떻게됩니까?

이를 극복하기 위해이 전체 시간과 분리하여 알고리즘의 확장 정도를 기준으로 비교합니다. 연구 논문에 O (1) 또는 O (n ^ 2)와 같은 표기법이있을 수 있습니다. Big O 표기법을 참조하려면 약간 더 읽어야 할 수도 있습니다 .


1
또한 실제 실행 시간은 알고리즘을 실행하는 데 사용되는 실제 입력의 크기와 내용에 따라 다릅니다.
이토 쓰요시

7

다른 답변은 기본 연산 수로 런타임을 분석하는 이유를 설명하기 때문에 비교 가 많은 (전체는 아님) 정렬 알고리즘의 올바른 지표 인 몇 가지 이유를 설명 하겠습니다 .

  • 많은 정렬 알고리즘의 경우, 비교 횟수가 실행 시간을 지배합니다. 즉, 최소한 다른 기본 연산만큼 많은 비교가 수행됩니다.
  • 비교는 비싼 작업입니다. 정렬 루틴이 라이브러리에서 어떻게 구현되는지 생각해보십시오. 정렬 함수에는 요소 배열과 두 요소를 비교하는 함수에 대한 포인터가 전달됩니다. 일반적으로 비교 함수가 실행되기를 호출하고 기다리는 것은 "내부"작업보다 비쌉니다. 이 기능은 사용자가 제공하므로 최적화하기가 더 어렵습니다
  • (이것은 어떤 사람들에게는 좋은 이유 일 수도 있고 아닐 수도 있습니다) 시퀀스를 정렬하기에 충분하고 필요한 비교 횟수에 대해 흥미로운 것을 말할 수 있습니다 . 우리는 최악의 경우와 다양한 분포에 대해 평균적으로 이것을 수행하는 방법, 심지어 알려지지 않은 분포에서 추출 된 iid 아이템에서 실행되는 최적으로 수렴하는 알고리즘을 설계하는 방법을 알고 있습니다 ( 자기 개선 알고리즘 ). 우리는 일부 비교가 무료로 제공 될 때 이것을 수행하는 방법을 알고 있습니다 ( 부분 정보로 정렬 )

1) "최소한의 다른 기본 연산만큼 많은 비교가 수행됩니다"-상수 요인까지만 가능합니다. 2) "비교는 비용이 많이 드는 작업입니다"-일반적인 설정을 가정합니다. 정수 정렬 (일반적으로 분석)의 경우 스왑은 일반적으로 더 비쌉니다.
Raphael

확실한. op는 일반적으로 알고리즘 분석에 대해 혼란스러워 보였고 일정한 요인을 가져오고 싶지 않았습니다. 나는 일반적인 설정에 대해 이야기하고 있다는 사실이 설명에서 명확하다는 것을 희망합니다. 표준 라이브러리의 정렬 루틴은 정수 정렬이 아닙니다
Sasho Nikolov

또한 op saw가 작성한 논문은 특수 정수 정렬 알고리즘에 관한 것이 아니며, 비교할만한 사람은 아무도 없습니다.
Sasho Nikolov

@Raphael 작은 정수를 정렬하는 것은 실제로 일반적인 문제가 아닙니다. 세계에서 진행되는 대부분의 정렬은 문자열 ( 길이 또는 기타 )입니다. 정수 정렬의 경우에도 스왑이 더 비싸다는 것이 확실하지 않습니다. 브랜칭은 최신 고급 프로세서에서 상대적으로 비싼 작업이므로 정렬시 브랜치 예측이 거의 쓸모가 없다는 것을 알 수 있습니다.
질 'SO-정지 존재 악마'

@Gilles 자체적으로 스왑은 내가 아는 플랫폼보다 정수 비교보다 비쌉니다. 예를 들어 지점의 잘못된 예측과 같은 "2 차"비용은 확실히 요인이며, 그 영향은 지속적인 연구 대상입니다. (실제로 사용하는 것과 관련하여, 자격을 갖춘 진술을 할 수는 없습니다. 그러나 표준 라이브러리 관리자는 기본 데이터 유형에 사용하는 정렬 알고리즘을 계속 개선하여 많은 사용이 보인다고 가정합니다.
Raphael
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.