최근에 Linux 커널에 대한 제안이 발표되었습니다., 다음과 같은 패치 세트를 포함하도록 제안되었습니다. memchr() 함수의 최적화된 구현 배열에서 문자를 검색하는 데 사용됩니다.
memchr() 함수는 c의 첫 번째 인스턴스에 대해 s가 가리키는 메모리 영역의 선행 n바이트를 스캔합니다. c와 s가 가리키는 메모리 영역의 바이트는 모두 부호 없는 문자로 해석됩니다.
제안 약속 더 빨라지다 메모리 블록 내에서 문자를 찾습니다. 개발자 테스트에서 새로운 구현은 대규모 검색에서 거의 XNUMX배 더 빠를 수 있습니다.
바이트 단위 비교를 사용했던 이전 버전과 달리, 제안된 구현은 64비트 및 32비트 CPU 레지스터의 전체 사용을 고려하여 생성됩니다. 바이트 대신 기계어를 사용하여 비교를 수행하므로 한 번에 최소 4바이트를 비교할 수 있습니다.
이 일련의 패치는 "memchr()"을 최적화하고 다음을 위한 매크로를 추가했습니다.
"memchr_inv()"를 사용하여 두 함수 모두 비트 마스크를 생성하는 데 사용할 수 있습니다."memchr()"의 원래 구현은 바이트 비교를 기반으로 합니다.
CPU의 64비트 또는 32비트 레지스터를 완전히 사용하지 않습니다. 우리는 구현
적어도 4 바이트가 동일한 것과 비교할 수 있도록 단어로 비교
날씨. 최적화된 memchr()은 원본보다 거의 4배 빠릅니다.
긴 사슬을 위해. Linux 커널에서 우리는 문자열의 길이가
"memchr()"에 의해 검색된 것은 drivers/misc/lkdtm/heap.c에서 최대 512바이트입니다.
큰 문자열을 검색할 때, 새 버전은 이전 버전보다 약 4배 빠른 것으로 나타났습니다. (예: 1000자의 문자열). 소규모 체인의 경우 새 구현의 효율성은 그다지 중요하지 않지만 여전히 원래 버전보다 높습니다.
새로운 제안에 대한 흥미로운 점은 시간을 상당히 개선하는 대형 체인에 대한 개선입니다. Linux 커널에서 언급할 가치가 있습니다. memchr()에서 처리되는 문자열의 크기는 512바이트에 이릅니다. 테스트에서 검색 문자가 문자열의 끝에 있으면 20%입니다.
memchr()의 원래 버전은 64비트 또는 32비트 CPU의 레지스터를 완전히 사용하지 않는 바이트 단위 비교 기술로 구현된다는 점을 언급할 가치가 있습니다.
CPU에서 동시에 8자를 비교할 수 있도록 전체 단어 비교를 사용합니다. 이 코드는 David Light의 구현을 기반으로 합니다.
첫 번째 파일의 성능을 측정하기 위해 두 개의 파일을 만듭니다. 대상 문자 앞에 평균 10자를 포함합니다. 두 번째 파일에는 대상 캐릭터.
"memchr()" 구현은 약간 첫 번째 테스트에서 더 우수하고 원본보다 거의 4배 빠릅니다. 두 번째 테스트에서 구현합니다.
5.18비트 및 32비트 아키텍처에 대한 새로운 "memchr()" 변형으로 커널 64 테스트 어떤 문제도 밝히지 않았다.
p가 8(또는 4비트 대상의 경우 32) 바이트로 정렬되지 않으면 어떻게 됩니까? 모든 대상이 정렬되지 않은(효율적인) 부하를 지원하는 것은 아닙니다. 맞나요?
p가 8 또는 4바이트로 정렬되지 않은 경우 작동한다고 생각합니다. 문자열이 10바이트라고 가정해 보겠습니다. 여기서 for 루프는 처음 8바이트를 찾습니다. 대상 문자가 마지막 2바이트에 있으면 두 번째 for 루프가 이를 찾습니다. 32비트 시스템에서도 이와 같이 작동합니다.
아직 평가되지 않은 전반적인 성능 향상 최적화된 "memchr()" 변형을 사용할 때 커널 하위 시스템의 영향을 받지 않으며 구현을 재정의할지 여부도 논의되지 않았습니다(memchr() 함수 호출은 드라이버 및 파일 시스템을 포함하여 커널 코드에서 129번 발생합니다).
최종적으로 그것에 대해 더 많이 알고 싶다면 세부 사항을 확인할 수 있습니다 다음 링크에서.