▲

Zig – io_uring 및 Grand Central Dispatch std.Io 구현 추가

 (ziglang.org)
1P by GN⁺ 15일전 | ★ favorite | 댓글 1개
  • Zig 표준 라이브러리의 std.Io.Evented 모듈에 io_uring과 Grand Central Dispatch(GCD) 기반 구현이 새로 통합됨
  • 두 구현 모두 사용자 공간 스택 전환(fibers, stackful coroutines, green threads) 방식으로 동작
  • 현재는 실험적 단계로, 오류 처리 개선·로깅 제거·성능 저하 원인 분석·테스트 보강 등의 후속 작업이 필요함
  • 동일한 애플리케이션 코드에서 I/O 백엔드만 교체해 io_uring 또는 GCD를 손쉽게 전환 가능함
  • Zig 컴파일러에서도 두 구현이 동작하며, 향후 안정화 시 플랫폼별 비동기 I/O 통합 기반으로 발전 가능성 있음

io_uring 및 GCD 기반 std.Io.Evented 구현

  • Zig 0.16.0 릴리스 주기 말기에 std.Io.Evented 가 최신 API 변경 사항을 반영해 업데이트됨

    • 새로 추가된 구현은 io_uring(Linux)과 Grand Central Dispatch(GCD) (macOS)
    • 두 구현 모두 사용자 공간 스택 전환(fibers, stackful coroutines, green threads) 기술을 사용

  • 두 구현은 현재 실험적 상태로, 안정적 사용을 위해 여러 개선 과제가 남아 있음

    • 오류 처리 개선 필요
    • 로깅 제거 및 성능 저하 원인 진단 필요 (IoMode.evented 사용 시 컴파일러 성능 저하 발생)
    • 일부 미구현 함수 존재 및 테스트 커버리지 확충 필요
    • 함수별 최대 스택 크기 확인용 내장 함수 추가 필요 (overcommit 비활성 시 실용성 확보 목적)

I/O 구현 교체 예시

  • 동일한 애플리케이션 코드에서 I/O 백엔드만 교체해 동작 가능함

    • 예시 코드에서 std.Io.Threaded 대신 std.Io.Evented를 사용하면 io_uring 기반으로 실행
    • app 함수는 동일하며, 출력 결과(Hello, World!)도 동일

  • strace 결과 비교를 통해 두 실행 방식의 차이를 확인 가능

    • hello_threaded는 일반 스레드 기반 I/O 호출
    • hello_evented는 io_uring 시스템 호출(io_uring_setup, io_uring_enter 등) 을 사용

Zig 컴파일러 적용 및 현황

  • Zig 컴파일러 자체도 std.Io.Evented 를 사용해 정상 동작함

    • io_uring 및 GCD 모두에서 컴파일러 실행 가능
    • 단, 성능 저하 원인 미확인 상태로 추가 분석 필요

  • 이 변경으로 Zig 코드가 I/O 구현을 손쉽게 교체할 수 있는 구조에 근접

    • 플랫폼별 비동기 I/O 모델을 통합적으로 다룰 수 있는 기반 마련

향후 과제

  • 안정적 사용을 위한 성능 개선 및 테스트 강화 필요
  • 스택 크기 관리 기능 추가 시, 오버커밋이 비활성화된 환경에서도 실용적 사용 가능
  • 완성 시 Zig의 비동기 I/O 추상화 계층이 한층 강화될 전망

결론

  • 이번 업데이트는 Zig의 표준 I/O 시스템 확장에서 중요한 진전
  • io_uring과 GCD를 통합함으로써 플랫폼 간 비동기 처리 일관성을 확보할 기반 마련
  • 향후 안정화 작업 완료 시, Zig의 고성능·유연한 I/O 모델 구현 가능성 확대
▲
GN⁺ 15일전  [-]
Hacker News 의견들

  • 나는 Zig 팬은 아니지만, 작은 팀이 꾸준히 발전하는 모습이 보기 좋음
    완성보다는 실험과 점진적 개선을 중시하는 태도가 인상적임
    1.0을 서둘러 내는 대신 장기적인 목표를 향해 나아가는 게 더 중요하다고 생각함
    한 명 중심의 프로젝트치고는 놀라운 성취이며, 노력하는 사람들에게 정당한 인정이 필요함

    • 나는 새로운 언어를 배울 때마다 TCP/UDP 멀티플레이 서버가 있는 게임 엔진을 만들어보는데, 최근엔 Zig로 시도했음
      지금까지 중 가장 재미있고 생산적인 경험이었음
      Rust의 엄격한 메모리 관리보다 Zig의 단순함이 훨씬 잘 맞음
      인생은 짧고, 나는 그저 빠르고 잘 정리된 소프트웨어를 만들고 싶음

  • Zig 관련 글마다 비판이 많지만, 왜 그렇게 신경 쓰는지 모르겠음
    Andrew와 팀이 믿는 바를 실현하려는 엔지니어링 정신이 오히려 영감을 줌
    Zig가 주류가 될지 걱정할 필요 없음, 문제 해결에 도움이 되면 그걸로 충분함
    언어를 정체성처럼 대할 필요는 없음

    • 이런 현상을 없애려면 프로그래머들이 받는 경제적 인센티브를 바꿔야 함
      언어와 라이브러리는 곧 ‘팔 수 있는 기술’이기 때문에, 사람들은 자신이 쓰는 도구의 시장성을 의식함
      게다가 의사결정권자들이 엔지니어를 교체 가능한 자산으로 보는 경향도 문제임
    • 이런 언어 논쟁은 Zig만의 일이 아님
      Lisp, Ruby, Rust 등에서도 반복되어 왔고, 정체성 싸움이 업계의 고질적인 문제임
    • 새로운 언어 스택은 리눅스 배포판에서 유지보수 부담을 늘림
      보안·아키텍처 지원 등 장기 관리가 필요함에도, 개발자들은 그 비용을 간과함
      Zig는 아직 안정적이지 않아 특정 버전에서만 패키지가 컴파일됨
      다른 언어 개선으로도 해결 가능한 문제를 굳이 새 언어로 풀 필요가 있는지 의문임
    • 주류 언어가 되려면 대부분의 사용 사례를 커버할 예측 가능한 라이브러리 생태계가 필요함

  • Zig가 1.0이 되기 전까지는 따라가 봐야 의미 없다고 느낌
    지금 구조는 여러 번 다시 짜일 가능성이 높음
    나도 한때 관심 있었지만, 내 생애에 1.0을 볼 수 있을지 모르겠음

    • 실제로 Zig의 호환성 깨짐은 대부분 표준 라이브러리(stdlib)에서 발생함
      파일 입출력 같은 기본 기능은 거의 동일하고, 네임스페이스만 바뀜
      나는 ‘살아 있는 언어’가 더 낫다고 생각함
      1.x 이후에도 stdlib을 슬림하게 유지하기 위해 버전별 인터페이스 관리 전략이 있으면 좋겠음
    • Zig 언어 자체는 좋아하지만 stdlib 품질에 의문이 생김
      I/O 프레임워크를 직접 만들다 보니 테스트 부족과 잘못된 어셈블리 코드를 발견했음
      여러 번 지적했지만 수정되지 않아 신뢰가 떨어짐
    • 대규모 프로젝트에는 망설여질 수 있지만, Zig는 이미 비즈니스적으로 가치 있음
      특히 클라우드 환경에서 성능 최적화로 서버 비용을 90% 이상 절감할 수 있음
      Python이나 Node로는 한계가 있어 결국 C, C++, Rust, Zig 중 하나로 내려가야 함
      그중 Zig는 배우기 쉽고, 읽기·테스트하기 편함
    • 참고로 Bun도 Zig로 작성되어 있음
      이미 실무 수준에서 쓰이고 있는 언어임
    • 우리 팀(ZML)은 std.Io 도입 이후 Zig master 브랜치를 계속 따라가고 있음
      대부분의 변경이 실제로 언어 개선으로 느껴짐

  • Rust의 io_uring 지원이 아직 완성되지 않은 상황에서 Zig가 먼저 구현을 시도하는 게 흥미로움
    Rust에서는 안전하고 제로코스트인 추상화를 설계하기가 어려움

  • 이번 소식은 아직 미완성 구현에 대한 것임
    예를 들어 GCD 버전에는 네트워킹이 없음
    인터페이스가 점점 커지고 있어 완성형이라기보다 현재 스냅샷에 가까움

    • 하지만 글의 서두에서 이미 실험적 단계임을 명시했고,
      앞으로 해야 할 6가지 주요 과제를 구체적으로 나열했음

  • 스택 메모리 최적화 관련 이슈가 있음
    서로 다른 블록에서 [500]u8을 사용해도 스택 프레임에 500바이트만 차지하도록 하는 기능이 필요함
    이는 그린 스레드 코루틴 스택과 관련해 특히 중요함

  • 나는 Zig의 지속적인 개선 노력을 긍정적으로 봄
    현재 io_uring을 제대로 다루는 언어는 없음
    Zig가 이 부분을 잘 해결하면 큰 우위를 점할 것임
    안정성보다 학습과 실험을 중시하는 태도가 더 가치 있다고 생각함

    • 저수준 언어에서까지 async를 원한다는 게 흥미로움
      나는 Zig에서 libxev를 사용해 io_uring을 직접 제어하는 방식을 선호함
    • 나도 긍정적이지만, Zig가 C처럼 장기 안정 버전(LTS) 을 내놓을 시점이 궁금함
      C의 성공 요인은 안정성과 일관된 개발 문화였음

  • Zig가 freestanding 타깃을 진지하게 다루는 점이 좋음
    0.16 버전에서 코드 재사용성이 더 높아질 것으로 기대함

  • macOS 내부를 오랜만에 살펴봤는데, GCD를 유지한 게 반가움
    병렬화의 균형 잡힌 접근이라 생각함

  • 다른 언어들이 논쟁만 하는 동안 Zig는 직접 시도하고, 필요하면 되돌림
    실전에서 검증된 API가 최고의 설계라고 믿음
    구버전을 유지할 수도 있고, 최신 버전으로 가면 더 깔끔하고 빠른 도구를 얻을 수 있음

    • Jai는 게임 개발 중심이라 범용성이나 안전성 측면에서 부족함
      C++처럼 복잡하지만 Zig는 C 수준의 단순함을 유지함
      Carbon은 아직 실체가 없는 상태임
    • Zig가 1.0이 아니라고 비판하는 건 이상함
      Jai는 11년째 클로즈드 베타인데, Zig는 이미 여러 실제 프로젝트에서 사용 중임
    • 언어는 20년이 걸리더라도 제대로 완성되는 게 낫다고 생각함
      Python 2→3, Rust async, Go 제네릭, C++ 등에서 본 무분별한 변화가 오히려 해로움
답변달기