Article Weekly, Issue 41

Period

2024-10-06 ~ 2024-10-12

It’s Time to Stop Taking Sam Altman at His Word

• 현재 OpenAI 제품의 한계
  • ChatGPT와 DALL-E는 2022년에는 최첨단 기술이었지만 지금은 평범하고 버그가 많은 현재의 기술처럼 느껴짐
  • GPT-4는 이제 전능한 초지능의 전조가 아니라 그냥 또 다른 챗봇처럼 보임
  • LLM으로 이메일이나 이야기를 작성할 수 있지만 특별히 독창적이지는 않음
  • 도구는 여전히 환각(거짓 정보를 자신있게 주장함)을 일으키고 당혹스럽고 예기치 않은 방식으로 실패함
• “AI 슬롭” 웹 콘텐츠의 확산
  • LLM으로 생성된 쓰레기가 거의 무료로 생산되고 제작자에게 광고 수익을 발생시킴
  • 모두가 예상했고 아무도 행복하지 않은 바닥을 향한 경쟁이 일어나고 있음
  • 한편 부풀려진 기술 회사 가치를 정당화할 만한 규모의 제품-시장 적합성을 찾는 노력은 계속 부족함
  • Altman조차도 OpenAI의 최신 제품 o1이 처음 사용할 때는 인상적이지만 더 많은 시간을 보내면 그렇지 않다고 인정함
• 현재 AI 기술의 문제점에 주목해야 함
  • AI가 어린이를 괴롭히고 착취하는 데 사용되는 방식에 초점을 맞추기보다 AI가 삶을 더 편하게 만드는 방법을 상상하는 것이 더 즐거움
  • 기후 변화로 인한 문제를 해결하는 자비로운 미래 AI를 상상하는 것이 오늘날 실제로 존재하는 AI의 막대한 에너지와 물 소비에 대해 생각하는 것보다 훨씬 더 즐거움
  • 이러한 기술들은 이미 실적이 있음. 세계는 그것들의 잠재력뿐만 아니라 결과와 영향을 기반으로 그것들과 그것들을 만드는 사람들을 평가할 수 있고 그래야 함

AI is an impediment to learning web development

• LLMs의 사용이 학습을 방해함
  • LLMs는 과제를 빠르게 완료할 수 있는 지름길이지만, 학습에는 거의 도움이 되지 않음
  • 학습은 다양한 경로를 시도하고 정보를 조합하여 정신적 모델을 만드는 과정임
  • LLMs는 이러한 정신적 모델을 형성할 필요 없이 결과를 제공하지만, 실제로 필요할 때는 정신적 모델이 없을 수 있음
• 사람에게 질문하는 것이 더 나음
  • 실제 사람에게 질문하면 필요한 맥락에 맞춰 설명을 받을 수 있음.
  • 사람들은 여전히 LLMs보다 간결하고 적절한 수준의 설명을 제공하는 데 뛰어남
  • 그러나 많은 사람들이 여전히 LLMs에 질문하여 코드를 작성하게 될 것임
• 늘 나오는 의견인듯…

Smolderingly fast b-trees

• 많은 스크립팅 언어들이 기본 연관 데이터 구조로 해시맵을 사용하지만, 해시맵에는 여러 단점이 있음
• B-트리와 같은 정렬된 데이터 구조는 해시맵의 단점을 갖지 않지만 일반적으로 더 느린 것으로 알려져 있음
• 저자는 Rust와 Zig의 해시맵 및 B-트리 구현과 자체 개발한 B+트리를 다양한 마이크로벤치마크로 비교
• 벤치마크 결과, 해시맵과 B-트리의 성능 차이는 측정 방식에 따라 크게 달라짐
• 투과량을 측정하는 벤치마크에서는 해시맵이 B-트리보다 훨씬 빠르지만, 지연 시간을 측정하는 벤치마크에서는 차이가 크지 않음
• 이는 해시맵이 투기적 실행(speculative execution)의 이점을 더 잘 활용하기 때문
• 문자열 키를 사용할 경우 B-트리의 성능이 크게 저하될 수 있으며, 특히 긴 공통 접두사가 있는 경우 더욱 그러함
• WebAssembly 환경에서는 해시 함수의 성능이 저하되어 B-트리가 상대적으로 더 경쟁력 있을 수 있음

How do HTTP servers figure out Content-Length?

• Go의 http 클라이언트는 기본적으로 요청 본문의 크기를 알 수 없을 때 청크 인코딩을 사용함
• 청크 인코딩은 HTTP/1.1에서 도입되었으며, 전체 크기를 모르는 상태에서 데이터를 전송할 수 있게 해줌
• 일부 서버는 청크 인코딩을 지원하지 않거나 Content-Length 헤더를 요구할 수 있음
• Go에서 Content-Length 헤더를 설정하는 방법:
  • 요청 본문이 io.ReadSeeker인 경우 자동으로 설정됨
  • http.NewRequest 대신 http.NewRequestWithContext 사용
  • req.ContentLength 필드를 직접 설정
  • req.Body를 io.NopCloser로 감싸지 않음
• io.ReadSeeker 인터페이스를 구현한 타입(예: bytes.Reader, strings.Reader)을 사용하면 자동으로 Content-Length가 설정됨
• 대용량 파일 업로드 시 메모리 사용을 줄이기 위해 os.File을 직접 사용할 수 있음
• Content-Length 설정이 불가능한 경우 Transfer-Encoding: chunked를 사용해야 함

Rust is rolling off the Volvo assembly line

• Volvo의 Rust 도입 사례 : 매우 큰 기업에서 조용히 Rust를 사용 중
• Julius Gustavsson은 2019년부터 볼보의 저전력 프로세서 ECU(전자 제어 장치)의 주요 소프트웨어 아키텍트 역할을 맡아옴
• Rust를 선택한 이유
  • Julius의 첫 직장은 Ada를 많이 사용하는 항공 교통 관제 소프트웨어를 구축하는 것이었음
    • 당시 회사의 컨센서스는 Ada가 너무 난해하고 독점적이라는 것이었음
  • 그 후 약 15년 동안 C와 C++의 혼합을 사용했는데, 모든 회사에서 메모리 관련 버그가 항상 문제였음
  • 불변성과 가정이 성문화되지 않았지만 모두가 준수해야 하는 코드베이스가 대부분이었음
    • 프로젝트 복잡성과 팀 규모가 커질수록 어느 시점에서 실패할 수밖에 없었음
  • Rust는 1.0 출시 전인 2015년에 알게 되었고, 출시 후 더 많은 관심을 가지게 되었음
    • 볼보에 입사할 때 취미로 약간의 경험이 있었음
  • ECU 프로젝트에서 Rust를 선택한 것은 갑자기 이루어진 것이 아니었음
    • 프로토타입을 만들 때 Rust로 Android와 상호 운용되는 HAL을 만들어 시스템을 제어해봤는데, 컴파일이 성공하자마자 팬이 작동하기 시작해서 매우 인상적이었음
• 다른 사람에게 Rust를 추천하시겠습니까?
  • 매우 엄격한 신뢰성과 가용성 요구 사항이 있고 배포하는 것이 실제로 올바른지 확신하고 싶은 모든 프로젝트에 Rust는 탁월한 선택임
  • Cargo 및 기타 사용 가능한 도구로 인해 고품질 소프트웨어 개발 주기 전체가 정말 좋은 경험이 됨
  • 컴파일될 때 거의 항상 작동하기 때문에 사람들이 코드를 인계받아 안전하게 수정할 수 있어서 이직률이 높은 팀에서도 잘 작동함
  • 프로토타이핑의 경우 엣지 케이스와 세부 사항에 더 많이 작업하도록 컴파일러가 강제하므로 최상의 선택이 아닐 수 있음
  • “이것에 Rust를 사용할 수 있습니까?“라고 묻는 대신 “왜 이것에 Rust를 사용할 수 없습니까?“라고 묻고 토론해야 할 시점에 와있음
• 방해가 된 부족한 점은 무엇입니까?
  • 요구 사항에 적절히 부합하는 소프트웨어를 만드는 것은 쉽지 않았는데, 이는 주로 도구 문제임
  • 예를 들어 임베디드 타겟에서 단위 테스트를 실행하기 어려웠음
    • 코드 커버리지, 런타임 프로파일링, 소프트웨어 BOM, 라이선스 추적 등도 어려움이 있었음
  • Knurling 프로젝트와 같은 도구가 많은 도움이 되었지만, 여전히 스스로 해야 할 일이 많음

My negative views on Rust

• Rust에는 긍정적인 면도 있지만, 저자는 여러 가지 우려 사항을 제기함
• unsafe 사용은 약간 우려되지만, FFI 사용과 크게 다르지 않음
• panic은 명시적 오류 처리를 강조하는 Rust의 철학과 모순됨
• Rust의 자동 역참조, 복사, 삭제 등의 “마법적” 기능은 초보자들에게 어려움을 줄 수 있음
• 메모리 제한으로 인해 합리적인 코드 작성이 어려운 경우가 있음
• Rust의 메모리 모델에 대한 과도한 찬사와 이론과 실제의 괴리가 존재함
• 가비지 컬렉션 없이 C와 유사하면서 안전한 언어를 목표로 하지만, 이는 장단점이 됨
• Rust로 재작성한 프로그램의 성능 향상이 언어 자체의 특성인지 의문
• 언어의 복잡성이 증가하고 있으며, 이는 Go 언어의 설계 철학과 대조됨
• 커뮤니티의 “친절함"은 일시적일 수 있으며, 언어 사용이 확대됨에 따라 변화할 수 있음
• 런타임/스케줄러 부재로 인한 대안 전략(예: async)이 문제를 야기함
• Rust가 “시스템” 언어로 정의되지만 다양한 용도로 사용되고 있음
• 저자는 개인 프로젝트에 Rust를 사용하지 않을 것이지만, 단일 스레드 C 대체로는 고려할 수 있음
• 우수한 도구와 개발팀이 Rust의 단순성과 투자 가치에 대한 착각을 불러일으킬 수 있다고 우려함

Designing A Fast Concurrent Hash Table

• papaya는 Rust를 위한 빠르고 기능이 완전한 동시성 해시 테이블임
• 동시성 해시 테이블의 주요 고려사항
  • 읽기/쓰기 처리량과 지연 시간, 메모리 사용량
• papaya는 읽기 작업에 더 중점을 두며, 예측 가능한 지연 시간을 목표로 함
• 기본 설계는 원자적 포인터를 사용한 락프리 해시 테이블 구조를 채택
• 오픈 어드레싱 방식과 메타데이터 테이블을 사용하여 캐시 효율성 향상
• 탐색 전략으로 전통적인 이차 탐색(quadratic probing)을 사용
• 로드 팩터 대신 최대 탐색 제한(probe limit)을 사용하여 리사이징 결정
• 삭제된 항목을 재사용하지 않는 방식으로 동시성 문제 해결
• 메모리 회수를 위해 hyaline 알고리즘 채택
• 점진적 리사이징을 구현하여 대규모 리사이징 시 지연 시간 스파이크 방지
• 복잡한 연산을 위한 원자적 연산 기능 제공 (예: compute 메서드)
• 비동기 지원 기능 포함

References

• https://www.theatlantic.com/technology/archive/2024/10/sam-altman-mythmaking/680152/
• https://ben.page/jumbocode-ai
• https://www.scattered-thoughts.net/writing/smolderingly-fast-btrees/
• https://aarol.dev/posts/go-contentlength/
• https://tweedegolf.nl/en/blog/137/rust-is-rolling-off-the-volvo-assembly-line
• https://chrisdone.com/posts/rust/
• https://ibraheem.ca/posts/designing-papaya/