Java 및 .NET : 기본적으로 다른 정렬 알고리즘이 사용되는 이유는 무엇입니까?


19

왜 그냥 궁금 Java하고 .NET Framework기본적으로 정렬 알고리즘을 사용하는 다른.

Java Array.Sort() 에서는 기본적으로 병합 정렬 알고리즘을 사용 하며 Wikipedia.com 은 다음 과 같이 말합니다.

Java에서 Arrays.sort () 메소드는 데이터 유형에 따라 병합 정렬 또는 조정 된 빠른 정렬을 사용하고 7 개 미만의 배열 요소가 정렬 될 때 구현 효율성을 삽입 정렬로 전환합니다.

.NET 프레임 워크를 Array.Sort/List.Sort() 사용하여 빠른 정렬 기본 정렬 알고리즘 (같은 MSDN을 ) :

List.Sort ()는 QuickSort 알고리즘을 사용하는 Array.Sort를 사용합니다. 이 구현은 불안정한 정렬을 수행합니다. 즉, 두 요소가 같으면 순서가 유지되지 않을 수 있습니다. 반대로 안정적인 정렬은 동일한 요소의 순서를 유지합니다.

훌륭한 "알고리즘 비교" 테이블을 보면 두 알고리즘이 최악의 경우와 메모리 사용 관점에서 동작이 매우 다르다는 것을 알 수 있습니다.

여기에 이미지 설명을 입력하십시오

모두 Java와 .NET엔터프라이즈 솔루션 개발을위한 좋은 프레임 워크는 모두 임베디드 개발을위한 플랫폼을 가지고 있습니다. 그렇다면 기본적으로 다른 정렬 알고리즘을 사용하는 이유는 무엇입니까?


1
이 두 종류의 비교에 대한 자세한 설명은 참조 stackoverflow.com/q/680541/866022
— yoozer8

답변:


10

컴퓨터 자체만큼 결정론 적이므로 컴퓨터 공학은 정확한 과학이 아닙니다. 동일한 문제 영역이 주어진 두 사람은 분석을 수행하고 문제의 모든 제약 조건을 만족시키는 두 가지 다른 솔루션을 개발할 것입니다. 이들 중 어느 것이 일반적인 경우에 "더 나은"지를 경험적으로 결정하는 것은 어렵거나 불가능할 수있다.

내 생각에 .NET QuickSort는 MFC 또는 Windows API의 상단에 계층화되어 있으며 MergeSort의 다중 스레드 이점은 컴퓨터에서 고려되지 않았던 훨씬 이전 버전의 Windows에서 상속되었을 것입니다. 그 날. ( 편집 : MS-DOS 이후 정렬 선택의 선택에 의해 입증 된 것처럼 Microsoft 개발자는 오랫동안 QuickSort fanboys 였음은 아닙니다).

처음부터 완전히 플랫폼 독립적으로 설계 되었기 때문에 플랫폼 별 구현을 사용할 수없는 Java는 다른 방식으로 진행되었습니다. MergeSort가 나온 이유를 누가 알겠습니까? 필자의 추측은 구현이 개발자가 생각해 낸 다른 종류와 비교하여 성능 경쟁에서 이겼거나 O (n) 공간 MergeSort가 최상의 경우와 최악의 성능 측면에서 종이에서 가장 잘 보인 것입니다. (MergeSort에는 QuickSort와 같은 요소 선택과 관련된 Achilles의 힐이 없으며 가장 좋은 경우는 거의 정렬 된 목록이지만 종종 QuickSort의 최악입니다). 멀티 스레딩의 이점이 처음에는 의심되었지만 현재 구현은 멀티 스레딩 일 수 있습니다.


1
List<T>.Sort.NET에서는 CLR로 구현 된 기본 메서드 (사용자 지정 비교기를 사용하지 않는 경우)를 사용하지만 OS 라이브러리에는 의존하지 않습니다.
— Joey

1
@Keith-.NET은 무엇보다 계층화되어 있지 않으며 플랫폼 독립적으로 설계되었습니다. 여기에서 구현을 볼 수 있습니다 : github.com/dotnet/coreclr/blob/master/src/mscorlib/src/System/…
— Robert MacLean

@RobertMacLean-문제의 정렬 기능이 전체적으로 "관리되는"코드임을 입증했지만 ".NET은 무엇이든 위에 계층화되어 있지 않다"는 것은 사실이 아닙니다. 암호화 지원, Windows 데스크톱 GUI 라이브러리, Windows API interop (프로세스 및 스레딩 제어 포함)을 포함하여 .NET의 많은 부분은 모두 MFC를 포함하여 기존의 관리되지 않는 코드를 기반으로합니다. 그들은 단순히 있어야만한다. 윈도우 자체의 코드베이스의 매우 작은 .NET 구성 요소가, 나머지는 관리되지 않는
— KeithS

Microsoft 개발자는 QuickSort가 MS-DOS 이후 선택한 알고리즘이기 때문에 다른 구현에 비해 QuickSort의 팬보이로 입증되어 있으며이 알고리즘으로 .NET의 정렬을 구현하려는 결정에 영향을 미쳤습니다.
— KeithS

이 답변은 너무 잘못되어 정직하게 충격을 받았습니다.
— user9993

17

서로 다른 두 회사의 다른 개발 팀은 프레임 워크 및 구성 요소에 대한 일반적인 사용 사례에 대해 다른 결론을 내리고 그에 따라 구현하기로 결정했습니다.

본질적으로 각 회사는 분석을 수행하고 고객 기반을 살펴보고 그에 따라 다른 결정을 내 렸습니다.

서로 다른 가정과 원시 데이터를 사용하여 서로 다른 회사와 팀이 분석 한 결과를 동일한 결론에 도달 할 수는 없습니다.


5
또는 심지어 동일한 가정과 원시 데이터. . .
— 와이엇 바넷

네, 그것은 아마 습관의 강제 된 - (안정) 퀵을 사용하는 데 사용 된 마이크로 소프트, 자바는 안정적인 종류로 가고 싶어 ... 그리고 병합 정렬 가장 빠른 알려진 안정적인했다 ...
— rogerdpack

12

Java가 현재 Timsort를 사용하기 때문에이 질문은 약간 오래된 것입니다 (Java 7 현재)

언급 된 특정 알고리즘 중 :

  • Quicksort는 O (n ^ 2)에서 좋지 않은 최악의 성능을 갖지만 약간 더 가볍고 메모리 소모가 적으므로 일반적인 경우 더 나은 성능을 제공합니다.

  • Mergesort는 O (n log n)에서 최악의 성능을 보장했지만 약간 더 많은 오버 헤드 및 메모리 요구 사항을 제공합니다. 또한 자동으로 안정적입니다 (즉, 동일한 순서로 동일한 요소를 유지).

자바 디자이너들은 일반적으로 좀 더 보수적이고 "올바른 것"에 초점을 둔 것처럼 보이므로 더 나은 보증을 제공하기 때문에 두 가지 중에서 Mergesort를 선택했다는 것은 놀라운 일이 아닙니다.

왜 마이크로 소프트가 퀵소트를 선택했는지 잘 모르겠습니다. 마이크로 벤치 마크에서 더 나아 보이게했을까요?

당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.