Xxhash: 벤치마크에 Meow 해시 추가

meow_hash는 전적으로 하드웨어 가속 AES 명령의 존재 여부에 달려 있습니다.

코드가 매우 짧고 소프트웨어 백업 코드 경로가 표시되지 않기 때문에 이러한 지침이 없으면 컴파일되지 않을 것이라고 생각합니다. 게다가 내가 읽을 수 있는 모든 AES 명령은 직접적인 Intel 내장을 사용하므로 하드웨어 기능에 관계없이 아키텍처 간에 이식할 수 없습니다.

그것이 반드시 "나쁜" 것은 아닙니다. 결국, 긴 입력에 대한 대가로 엄청난 속도를 얻습니다.

그러나 요점은 이러한 특수 하드웨어 명령 집합에 의존하기 때문에 이식성이 기능 목록에서 제외된다는 것입니다.

부작용으로 xxHash 벤치마크에 사용되는 플랫폼에서도 실행되지 않습니다.

아마도 이것을 문서화하는 데 시간을 할애해야 할 것입니다.

이것은 더 이상 사실이 아닙니다. 이것을 다시 방문해야 합니다.

예, 공지사항을 읽고 몇 번의 수정으로 야옹이 많이 개선되었습니다.
ARM과의 호환성을 발표하기도 합니다.

좀 더 자세히 알아보는 시간이 필요하겠습니다.

대충 봤는데 소프트웨어 백업 경로를 찾을 수 없었습니다. 어쩌면 거기에 있고 나는 그것을 놓쳤습니다.
또한 다른 AES 하드웨어 모듈이 정확히 동일한 해시 값을 생성하도록 보장되는지 또는 더 많은 것이 있는지(예: 다르게 사전 설정될 수 있고 기계별 명령이 균일해야 하는 추가 매개변수와 같이) 더 있는지 아직 모릅니다. 해시를 로컬에서 계산하고 소비하는 것은 한 가지이며 이 경우 정확한 표현은 중요하지 않습니다. 값을 쓰고/직렬화하고 다른 시스템에서 정확히 읽고/재생할 것으로 기대하는 것은 또 다른 문제입니다. 상호 운용성의 그 부분은 조금 더 까다롭습니다.
그러나 다시 한 번, 아마도 거기에 있을 수 있으며, 나는 그것을 조사할 시간이 필요합니다.

참고로 제 최신버전인 2.0GHz Core i7 Gen 2(Sandy Bridge) 기준입니다.

클랑 7.0.1
플래그: -O3 -march=native

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54765 it/s ( 5348.2 MB/s)
XXH32 unaligned     :     102400 ->    53782 it/s ( 5252.1 MB/s)
XXH64               :     102400 ->   104882 it/s (10242.4 MB/s)
XXH64 unaligned     :     102400 ->   105935 it/s (10345.2 MB/s)
XXH32a              :     102400 ->    78027 it/s ( 7619.8 MB/s)
XXH32a unaligned    :     102400 ->    75624 it/s ( 7385.2 MB/s)
XXH64a              :     102400 ->    77204 it/s ( 7539.5 MB/s)
XXH64a unaligned    :     102400 ->    76209 it/s ( 7442.3 MB/s)
XXH auto            :     102400 ->   105179 it/s (10271.4 MB/s)
XXH auto unaligned  :     102400 ->   101546 it/s ( 9916.6 MB/s)
XXH32 auto          :     102400 ->   107646 it/s (10512.3 MB/s)
XXH32 auto unaligne :     102400 ->   104364 it/s (10191.8 MB/s)
XXH64 auto          :     102400 ->   107443 it/s (10492.4 MB/s)
XXH64 auto unaligne :     102400 ->   105843 it/s (10336.3 MB/s)
meow auto           :     102400 ->   214435 it/s (20940.9 MB/s)
meow auto unaligned :     102400 ->   213289 it/s (20829.0 MB/s)

-march=penryn -mno-sse4.2 -mno-avx 및 C 구현:

./xxhsum 0.6.5 (64-bits little endian), by Yann Collet
Sample of 100 KB...
XXH32               :     102400 ->    54106 it/s ( 5283.8 MB/s)
XXH32 unaligned     :     102400 ->    53303 it/s ( 5205.4 MB/s)
XXH64               :     102400 ->   107245 it/s (10473.1 MB/s)
XXH64 unaligned     :     102400 ->   107774 it/s (10524.8 MB/s)
XXH32a              :     102400 ->    78394 it/s ( 7655.6 MB/s)
XXH32a unaligned    :     102400 ->    79666 it/s ( 7779.9 MB/s)
XXH64a              :     102400 ->    78907 it/s ( 7705.7 MB/s)
XXH64a unaligned    :     102400 ->    78179 it/s ( 7634.6 MB/s)
XXH auto            :     102400 ->   108878 it/s (10632.6 MB/s)
XXH auto unaligned  :     102400 ->   105124 it/s (10266.0 MB/s)
XXH32 auto          :     102400 ->   105819 it/s (10333.9 MB/s)
XXH32 auto unaligne :     102400 ->   103970 it/s (10153.3 MB/s)
XXH64 auto          :     102400 ->   110021 it/s (10744.2 MB/s)
XXH64 auto unaligne :     102400 ->   107109 it/s (10459.9 MB/s)
meow auto           :     102400 ->    15962 it/s ( 1558.8 MB/s)
meow auto unaligned :     102400 ->    16022 it/s ( 1564.6 MB/s)

이것은 더 이상 사실이 아닙니다. 다시 방문해야 합니다.

...aa그리고 Meow 0.5에서는 다시 사실입니다. 최신 버전에서는 다시 x64 AES 코드 경로만 있습니다. :)

예, Meow Hash는 x86_64 및 Nehalem+에 고유하거나 느린 af 대체 버전으로 전환해야 합니다.

한편 XXH3에는 모든 x86_64(Core 2 및 친구 포함), Pentium 4+(Windows 7+에 필요), ARMv7-A w/NEON(대부분의 Android 및 원래 iPhone을 제외한 모든 iOS 장치에서 사용 가능)에 대한 벡터화된 코드 경로가 있습니다. ), ARM64(최근의 모든 iPhone 및 Android), VSX POWER9(많은 서버 및 슈퍼컴퓨터에 이러한 기능이 있지만 틈새 시장임), 그리고 충분하지 않은 경우 스칼라 버전이라도 32비트에서도 여전히 매우 빠릅니다. 적절한 승수가 있다는 점을 감안할 때 대상.

몇 년 동안 이러한 종류의 요청이 여러 번 있었기 때문에 벤치마크 결과를 더 수집하기 시작했습니다.
반복적인 요청이었던 이것부터 시작합니다.

meowHash 는 실제로 매우 빠르며 대용량 데이터(~100KB)의 경우 XXH3 와 거의 동일한 속도를 기록하므로 XXH128 보다 약간 빠릅니다.
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

즉, meowHash 는 실제로 대용량 데이터용으로 설계되었습니다. _작은_ 데이터의 경우 알고리즘에 큰 고정 비용이 필요하고 작은 데이터에서는 잘 상각되지 않기 때문에 성능이 비교할 수 없습니다.

우려스러운 발전은 "결과를 표현하고 해석하는 방법"에 불일치가 있다는 것입니다.
대용량 데이터의 경우 정렬된 테이블로 충분하므로 순위를 즉시 알 수 있습니다.
그러나 작은 데이터의 경우 더 복잡해 보입니다.
지금까지 다양한 길이와 시나리오에 따라 속도 결과를 제공하는 그래프를 사용했습니다. _more_ 정보를 제공하기 때문에 해석하기가 더 어렵습니다.

결과적으로 독자가 눈에 띄는 상단 테이블에서 첫 번째 성능 수치를 찾은 후 아래에서 추가 그래프를 찾는 것을 귀찮게 여기고 선택을 안내하면서 사용 사례에 대한 중요한 정보를 놓칠 수 있는지 여부는 불분명합니다.

또 다른 문제는 그래프 자체에 관한 것입니다. 정렬된 테이블은 비교적 쉽게 확장할 수 있습니다. 물론 한계가 있지만 일반적으로 경쟁자를 추가하면 한 줄만 추가됩니다.
그러나 그래프에서 각 경쟁자는 선으로 표시됩니다. 선이 겹치는 경향이 있습니다. 선택할 수 있는 색상이 너무 많습니다. 매우 빠르게, 대표되는 경쟁자의 nb가 크면 큰 혼란일 뿐입니다.
따라서 작은 데이터 성능에 그래프가 필요한 경우 표현할 수 있는 경쟁자의 nb를 심각하게 제한합니다.

"원시" 벤치마크 데이터를 포함하는 단락을 추가하는 것은 칭찬할 만하지만 부적절합니다.

따라서 소규모 데이터 테스트 결과를 "요약"하고 순위표에서 사용할 수 있는 "성능 번호"를 만들어 소규모 데이터에 대한 일반적인 성능에 대한 힌트를 제공하는 것을 고려했습니다. 관심 있는 독자는 여전히 더 정확한 정보(그래프)를 살펴봐야 하지만, 최소한 일부 알고리즘이 다른 알고리즘보다 작은 데이터에 더 적합하다는 개념은 비교적 간단한 방식으로 전달할 수 있습니다.

그래프가 제한된 수의 경쟁자를 나타낼 수 있다는 문제가 여전히 있으며, 독자가 관찰하고자 하는 것은 선택한 목록의 일부가 아닐 수도 있습니다(원시 데이터를 사용할 수 있는 경우에도).

그래프를 더 잘 표현할 수 있는 방법이 없을까 하는 생각이 들었습니다. 준비된 스크린샷보다 더 역동적이어서 사용자가 어떤 경쟁자를 표시할지 선택할 수 있습니다.

meow 해시가 비교에 추가되었습니다.
https://github.com/Cyan4973/xxHash/wiki/Performance-comparison

테이블에 항목을 추가하는 것은 괜찮습니다.
그러나 나는 여전히 많은 수의 후보자에 대한 그래프를 그리는 더 나은 방법이 필요합니다.