▲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 구현이 완료되었으므로 업데이트된 벤치마크를 보는 것이 흥미로울 것임
Hacker News 의견
32개의 엔트리가 가장 효율적인 이유는 캐시 라인이 64바이트이기 때문임
CRDTs를 사용하는 실제 애플리케이션 중 좋은 경험을 제공하는 예시를 찾기 어려움
CRDTs는 강력하지만, 역사적인 작업(또는 요소)을 남기는 단점이 있음
현재 GitHub Readme 인용:
이 기사는 내용이 어려워도 잘 쓰여져 있어 읽는 것을 멈출 수 없었음
계층 구조를 사용한 것을 보고 중첩 집합을 대신 사용했는지 궁금함
몇 년 전에 이 게시물을 우연히 발견했음
WASM이 네이티브 실행보다 4배 느린 이유에 대해 궁금함
Automerge의 Rust 구현이 완료되었으므로 업데이트된 벤치마크를 보는 것이 흥미로울 것임