Linux 파이프 기반 애플리케이션을 Windows로 포팅했던 경험을 잊지 못함, POSIX 표준이니 성능이 크게 다르지 않을 거라 생각했는데 엄청나게 느렸던 기억, 파이프 연결을 대기하는 상황에서 Windows 전체가 거의 멈추는 수준까지 갔던 문제점, 몇 년 뒤 Win10에서 C#으로 같은 걸 다시 구현했을 때는 조금 나아졌지만 성능 차는 여전히 큰 부끄러움이었던 기억
최근 몇 년 사이 Windows에 AF_UNIX 소켓이 추가된 걸로 아는데, Win32 파이프 대비 어느 쪽 성능이 나은지 궁금함, 내 예상엔 더 나을 거란 추측
"성능이 엉망이었다"고 할 때, 파이프가 이미 연결된 이후의 I/O를 말하는 건지, 아니면 연결 이전의 과정인지 궁금증, 이미 연결된 후라면 의외이겠지만, 연결/해제 반복이 문제라면 OS가 최적화하지 않았을 가능성 인정, 실제로 그럴 필요는 거의 없으니까 사용 사례에 따라 다르게 받아들임
내가 최근에 확인해본 결과 Windows에서 로컬 TCP의 성능이 파이프보다 훨씬 뛰어나다는 사실
POSIX는 동작만 정의하고 성능은 정의하지 않는다는 점, 각 플랫폼과 OS마다 고유의 성능 특이점이 있음을 상기
옛날에 반대 경우의 경험이 있었음, 파이프는 아니지만, Linux에서 PHP 앱이 .NET 기반 SOAP API와 통신했을 때 .NET 구현 쪽 응답 속도가 더 좋았던 기억
참고로 readv() / writev(), splice(), sendfile(), funopen(), io_buffer() 등 여러 방법이 있음, splice()는 파이프와 UNIX 소켓 사이에서 zero-copy로 대용량 데이터 전달 시 매우 뛰어난데 Linux 전용임, splice()는 데이터 전송 시 사용자 공간 메모리 할당, 추가 버퍼 관리, memcpy(), iovec 탐색 없이 직접 처리하는 가장 빠른 방법, BSD 계열에서는 파이프에 대해 readv()/writev()가 최적이 맞는지 여부에 대한 확인 요청도 함께, 어쨌거나 이 기사 매우 인상적이라는 평
sendfile()은 파일→소켓 zero-copy 방식의 매우 높은 성능 제공, Linux와 BSD 양쪽에서 사용 가능, 단 파일→소켓만 지원함, sendmsg()는 일반적인 파이프에는 사용 불가, UNIX 도메인/INET/기타 소켓용임, 참고로 Linux에서는 sendfile이 내부적으로 splice로 구현된 덕분에 파일→블록 디바이스 전송에도 실제로 사용해본 경험
splice()가 리눅스에서 파이프 간 초고속 대량 데이터 전송의 최고지만, io_uring을 제대로 쓰면 비슷하거나 오히려 앞지르는 성능 기대 가능
shm_open 같은 공유 메모리와 파일 디스크립터 전달 방식이 실제론 더 빠르고, 완전히 포터블함
아직 아무 댓글도 없어서 아쉽다는 감상과, splice를 더 많이 쓰고 싶으나 글 마지막에 언급된 보안이나 ABI 호환성 이슈가 걱정, splice가 앞으로도 계속 유지될지, 그리고 성능 향상을 위해 기본 파이프가 splice를 항상 쓰도록 패치하는 난이도도 궁금증 제기
Hacker News 의견
Linux 파이프 기반 애플리케이션을 Windows로 포팅했던 경험을 잊지 못함, POSIX 표준이니 성능이 크게 다르지 않을 거라 생각했는데 엄청나게 느렸던 기억, 파이프 연결을 대기하는 상황에서 Windows 전체가 거의 멈추는 수준까지 갔던 문제점, 몇 년 뒤 Win10에서 C#으로 같은 걸 다시 구현했을 때는 조금 나아졌지만 성능 차는 여전히 큰 부끄러움이었던 기억
최근 몇 년 사이 Windows에 AF_UNIX 소켓이 추가된 걸로 아는데, Win32 파이프 대비 어느 쪽 성능이 나은지 궁금함, 내 예상엔 더 나을 거란 추측
"성능이 엉망이었다"고 할 때, 파이프가 이미 연결된 이후의 I/O를 말하는 건지, 아니면 연결 이전의 과정인지 궁금증, 이미 연결된 후라면 의외이겠지만, 연결/해제 반복이 문제라면 OS가 최적화하지 않았을 가능성 인정, 실제로 그럴 필요는 거의 없으니까 사용 사례에 따라 다르게 받아들임
내가 최근에 확인해본 결과 Windows에서 로컬 TCP의 성능이 파이프보다 훨씬 뛰어나다는 사실
POSIX는 동작만 정의하고 성능은 정의하지 않는다는 점, 각 플랫폼과 OS마다 고유의 성능 특이점이 있음을 상기
옛날에 반대 경우의 경험이 있었음, 파이프는 아니지만, Linux에서 PHP 앱이 .NET 기반 SOAP API와 통신했을 때 .NET 구현 쪽 응답 속도가 더 좋았던 기억
참고로 readv() / writev(), splice(), sendfile(), funopen(), io_buffer() 등 여러 방법이 있음, splice()는 파이프와 UNIX 소켓 사이에서 zero-copy로 대용량 데이터 전달 시 매우 뛰어난데 Linux 전용임, splice()는 데이터 전송 시 사용자 공간 메모리 할당, 추가 버퍼 관리, memcpy(), iovec 탐색 없이 직접 처리하는 가장 빠른 방법, BSD 계열에서는 파이프에 대해 readv()/writev()가 최적이 맞는지 여부에 대한 확인 요청도 함께, 어쨌거나 이 기사 매우 인상적이라는 평
sendfile()은 파일→소켓 zero-copy 방식의 매우 높은 성능 제공, Linux와 BSD 양쪽에서 사용 가능, 단 파일→소켓만 지원함, sendmsg()는 일반적인 파이프에는 사용 불가, UNIX 도메인/INET/기타 소켓용임, 참고로 Linux에서는 sendfile이 내부적으로 splice로 구현된 덕분에 파일→블록 디바이스 전송에도 실제로 사용해본 경험
splice()가 리눅스에서 파이프 간 초고속 대량 데이터 전송의 최고지만, io_uring을 제대로 쓰면 비슷하거나 오히려 앞지르는 성능 기대 가능
shm_open 같은 공유 메모리와 파일 디스크립터 전달 방식이 실제론 더 빠르고, 완전히 포터블함
지난 HN에서 이 기사에 대해 토론이 활발하게 이뤄졌던 링크라며 https://news.ycombinator.com/item?id=31592934 (200개 댓글), https://news.ycombinator.com/item?id=37782493 (105개 댓글)로 안내
정말 멋진 기사라며, 주기적으로 다시 언급되는 것도 매우 반가운 점
아직 아무 댓글도 없어서 아쉽다는 감상과, splice를 더 많이 쓰고 싶으나 글 마지막에 언급된 보안이나 ABI 호환성 이슈가 걱정, splice가 앞으로도 계속 유지될지, 그리고 성능 향상을 위해 기본 파이프가 splice를 항상 쓰도록 패치하는 난이도도 궁금증 제기
최신 Linux에 SunOS의 Doors와 유사한 무언가가 있는지 질문, 지연 시간이 매우 민감한 작은 데이터 교환이 필요한 임베디드 애플리케이션에서 AF_UNIX보다 나은 기술을 찾는 중인 상황
공유 메모리가 지연 시간 측면에서 가장 빠르지만, 태스크 깨우기(보통 futex 활용)가 필요함, Google이 FUTEX_SWAP 시스템 콜을 개발하고 있었는데, 한 태스크에서 다른 태스크로 직접 핸드오버 가능할 예정이었으나 이후 상황은 잘 모름
'Doors'가 너무 일반적인 단어라 검색이 어려워 설명 요청
현재 AF_UNIX에 대해 어떤 점이 문제인지, 필요한 기능이 없는지, 원하는 것보다 지연이 높은지, 아니면 서버/클라이언트 소켓 API 구조가 맞지 않는 것인지 추가 정보 요청
기사 작성 시점을 2022년으로 간결하게 정보 추가