![]() |
|
||||||||
경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
![]() 음.. 생각해 보니 그렇네요. 아마도 블록 단위로 처리되어야 한다면 기존의 해시 개념이 많이 바뀌어야 해서 그렇지 않을까 싶습니다.예를 들면 파일을 배포하면서 파일의 변경 여부를 확인하기 위해 file md5 검증 과정을 거치는 것이 있는데, 만약 블록 단위로 처리해야 한다면 파일 크기가 n의 배수로 딱 떨어 지지 않는 경우 padding을 해야 할 것이고 이렇게 되면 파일에 대한 해싱 정보의 의미가 조금 더 떨어 지지 않을까요? 정보(파일)의 배포자와 정보(파일)의 수급자가 해싱함수뿐 아니라 블록의 크기, 패딩의 방법까지 다 일일이 약속을 해야 한다면 관리가 더 힘들어 지지 않을까 하는 생각을 해 봅니다.
음... hash의 표준어 표기가 아무래도 해쉬가 아니라 해시인 것 같아서 일단 원문을 수정했습니다.
n배수로 떨어지지 않는건 0를 필요한 만큼 삽입해 n배수로 만들면 되죠. 마치 Base64에서 하는 것 처럼요. 물론 해시의 용도는 다양하고 당연히 자신의 용도에 맞는 적합한 해시 함수를 선택해야겠죠. 동키나 토런트 같은 응용프로그램에선 당연히 중복이 거의 일어나지 않는 긴 bit의 해시를 내 놓는 놈이 좋지만 해시테이블을 구현한다든지 할 때는 어차피 버킷 카운트로 나머지 연산을 해서 사용하는것이 일반적이므로 32bit 안쪽의 골고루 분산되는 해시값이 더 유용하다고 봅니다. 자기가 구현한 해시함수의 성능과 품질이 좋다면 굳이 표준 해시 함수들을 사용할 필요도 없겠죠. 여튼... 남이 해 놓은게 있으면 좀 날로 먹어볼까 했는데 잘 눈에 안 띄네요. ㅋㅋ ELF 해시함수를 찾아보다 발견한 사이트인데 ELF도 역시 byte단위 계산이네요.
http://www.hello-world.co.kr/?q=node/148 근데 오히려 그 페이지의 맨 마지막에 소개된 SuperFast 알고리즘이 눈에 띕니다. http://www.azillionmonkeys.com/qed/hash.html 어쩜 이게 제가 찾고 있던거랑 좀 유사할지도 모르겠네요. 속도 테스트 한건 역시나 2~3배정도 빠르네요. 32비트 단위 루프고 16비트씩 짤라서 쉬프트연산으로 상위 하위비트를 섞는 듯 합니다. 나중에 함 테스트 해 보고 결과를 포스팅 하죠. 고맙습니다. 관련 글 리스트
|
Copyright © 1999-2015, borlandforum.com. All right reserved. |