Hacker News 의견

• Rust가 알고리즘 관련 저수준 콘텐츠에서 점점 더 많이 사용됨을 관찰함. 과거에는 C(++)나 과학적인 의사코드로 작성된 콘텐츠가 주를 이루었음. Rust의 사용이 증가하는 것을 긍정적으로 봄

  • Rust를 잘 모르지만, Rust로 작성된 콘텐츠를 이해할 수 있었음. C로 작성된 알고리즘 예제를 Rust 프로그래머가 이해할 수 있는 것과 유사함
  • Rust가 표준화되는 것을 선호하며, Zig도 함께 사용되면 좋겠다고 생각함

• 쿼리를 배치로 나누는 방법이 탐구되지 않았음. 캐시 외부 테이블에서 조회하는 것이 주요 비용임

  • 충분히 많은 쿼리가 있을 경우, 트리의 여러 계층을 한 번에 해결할 수 있음
  • 결과를 올바른 출력 순서로 정렬해야 하는 문제가 발생할 수 있음

• int32 값의 수는 많지 않으며, 전체 비트셋은 512MB임. 일반적인 데이터 구조로는 Roaring Bitmaps를 추천함

  • 단순 조회만 필요하다면 최소 완벽 해시 함수를 고려할 가치가 있음

• Rust에서 저수준 효율성을 높이는 방법에 대해 놀라움을 느낌. C++ 구현과 비교해보고 싶음

• Eytzinger 트리의 장점은 노드 인덱스를 중위 순회 위치로 변환하는 공식이 있다는 것임

  • 기본 키 저장소가 정렬된 키 집합일 경우 유용함
  • Eytzinger를 사용하면 여러 루프 반복을 사전에 예측할 수 있음

• 4GB 메모리에서 u32를 검색하는 데 ~27ns의 오버헤드가 발생하는 것이 놀라움

  • 배치 크기 8에서 최적화가 어떻게 진행되는지 궁금함
  • 멀티스레딩 결과도 흥미로움. 1에서 6 스레드로 전환 시 오버헤드가 4배 개선됨

• Rust와 C++에 대한 논의가 많지만, Common Lisp에서 SIMD를 유지하며 구현하는 방법을 고민함

• 저수준 최적화에 대한 글을 읽을 때마다 저자가 시간을 들여 나노초를 절약해 준 것에 감사함

  • 이러한 최적화가 쌓여 인류가 얼마나 많은 시간을 절약했는지 궁금함

• 1.7 그림 3에 오류가 있다고 생각함. 1.3 그림 1의 y축 레이블이 "역전송량"이어야 한다고 제안함

• 가끔 쓰기를 지원해야 한다면, 큰 정적 검색 트리와 작은 쓰기 가능한 트리를 사용할 수 있음

  • 충분한 변경이 있을 때 정적 트리의 새 버전으로 변경 사항을 전송할 수 있음