GN⁺ 2024-08-28 | parent | ★ favorite | on: 더 빠른 CRDTs (2021)(josephg.com)
Hacker News 의견
  • 32개의 엔트리가 가장 효율적인 이유는 캐시 라인이 64바이트이기 때문임

    • 2바이트 정수를 사용할 경우, 32개의 엔트리가 정확히 하나의 캐시 라인에 맞아 메인 메모리 전송을 줄일 수 있음
  • CRDTs를 사용하는 실제 애플리케이션 중 좋은 경험을 제공하는 예시를 찾기 어려움

    • Notion은 두 사람이 동시에 노트를 작성할 때 Google Docs에 비해 사용성이 떨어짐
  • CRDTs는 강력하지만, 역사적인 작업(또는 요소)을 남기는 단점이 있음

    • 압축을 사용해도 여전히 단점으로 작용해 채택에 대한 우려가 있음
    • 그럼에도 불구하고 파일 기반 저장소 제공자(Dropbox, Syncthing 등)에서 충돌 없는 알고리즘을 구현할 가능성에 대해 흥미를 느낌
  • 현재 GitHub Readme 인용:

    • 블로그 게시물 이후 성능이 10-80배 향상됨
  • 이 기사는 내용이 어려워도 잘 쓰여져 있어 읽는 것을 멈출 수 없었음

  • 계층 구조를 사용한 것을 보고 중첩 집합을 대신 사용했는지 궁금함

    • 읽기 작업에서의 이득이 삽입 작업에서의 손실을 상쇄할 수 있을지에 대한 아이디어 없음
  • 몇 년 전에 이 게시물을 우연히 발견했음

    • 최근 몇 년 동안 가장 재미있었던 게시물 중 하나임
  • WASM이 네이티브 실행보다 4배 느린 이유에 대해 궁금함

    • 모든 문자열 작업이 WASM 메모리로 복사되고 결과가 계산된 후 다시 JS로 복사되어야 하기 때문이라고 생각했음
    • 이 맥락을 잘못 이해한 것인지 궁금함
  • Automerge의 Rust 구현이 완료되었으므로 업데이트된 벤치마크를 보는 것이 흥미로울 것임