분할 방법은 m이 소수일 때 가장 잘 작동하며, 키의 규칙성은 해시 값에서 클러스터링을 생성할 수 있습니다. 예를 들어 m이 256이면 어떻게 되는지 생각해 보십시오. 그러나 나머지 컴퓨팅은 상대적으로 느린 작업이므로 해시 함수를 빠르게 계산하는 것은 어려울 수 있습니다. 정수를 압축하기 위해 많은 비트 패킹 방식이 이미 잘 설정되어 있습니다. 예를 들어 비트패킹의 한 예는 Elias 감마 코딩[12]과 같은 범용 코드입니다. Elias 감마 코딩에서 첫 번째(c- 1) 비트가 0인 (2c – 1) 비트를 사용하여 c 비트가 필요한 양수 정수를 인코딩할 수 있으며, 다음 c 비트에 실제 정수를 포함함을 나타내는 코드워드로 사용됩니다. 이러한 선행(c – 1) 비트는 각 정수의 시작과 끝을 설명하기 위해 직렬 디코딩에 필요합니다. 마찬가지로 Elias delta 코딩 [12]라는 유사한 체계는 Elias 감마로 비트 c 수를 인코딩하고 가장 중요한 비트를 따르는 (c – 1) 비트를 추가하여 정수를 나타냅니다. 또 다른 범용 코드는 피보나치 숫자 세트를 사용하여 정수를 인코딩합니다 [13], 손상된 비트 스트림에서 복구 할 수 있기 때문에 노이즈가있는 경우 디코딩을 돕기 위한 것입니다.
최신 컴퓨터는 점점 더 많은 양의 기본 랜덤 액세스 메모리 또는 RAM에 액세스할 수 있지만, 스토리지 공간은 여전히 대용량 데이터 구조를 저장하고 사용하는 데 여전히 문제가 되고 있습니다. PatternHunter II 프로그램의 저자가 말했듯이, 그들의 개발은 „여러 해시 테이블에 대한 큰 메모리 요구 사항”[10]에 의해 방해되었다. 또한 15-mers에 대한 해시 테이블에는 오프셋 배열의 크기가 4GB가 필요하기 때문에 FusionMap 개발자가 아이디어를 14mers 이상으로 확장하는 것을 배제할 수 있습니다. 블록 크기가 64의 한 가지 장점은 균일한 비트 너비를 균등값으로 제한할 수 있다는 것입니다. 앞에서 언급했듯이 BP128 스키마는 0에서 32까지의 모든 비트 너비에 대해 128비트 단어 경계에서 128개의 정수 블록을 정렬합니다. 예를 들어 비트 너비가 3인 경우 128개의 정수 블록에는 저장소에 정확히 3개의 128비트 레지스터가 필요합니다. 그러나 블록 크기가 64인 경우 홀수 비트 너비는 다음으로 큰 짝수 비트 너비에 비해 저장소에서 비용을 절감할 수 없습니다. 이 블록 크기의 경우 비트 너비3는 1비트 및 반 128비트 레지스터를 사용하며, 두 개의 전체 128비트 레지스터를 사용하는 4의 비트 너비와 효과적으로 동일한 공간을 사용합니다. 또한 홀수 비트 너비에 대한 디코딩 절차는 홀수 크기가 32비트 레지스터에 균등하게 맞지 않기 때문에 한 레지스터의 끝에서 교차하는 정수를 병합하기 위한 SIMD 작업이 더 필요하기 때문에 짝수 비트 너비에 대한 디코딩 절차가 더 복잡합니다. 다음 것의 시작부분(그림 2의 파선으로 표시). 따라서 짝수 비트 너비의 디코딩 속도는 홀수 비트 너비[16]보다 약간 빠른 것으로 나타났습니다.
Q3에서 x43을 계산하는 예제의 경우, 양방향 구성표의 원하는 컬럼은 그림 4b에서 연한 파란색과 진한 파란색으로 음영화되며, 세 개가 아닌 두 개의 SIMD 하중이 필요합니다. 이러한 음영은 그림 2d에 표시된 양방향 열구조 레이아웃에 해당합니다. 이 레이아웃에서는 도 4b의 열에 따라 첫 번째 절반 블록에 정수팩을 한 다음, 다시 열에 따라 두 번째 절반 블록의 정수들을 반대 순서로 포장합니다.