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.