그냥 사실에 가깝다고 봄. MVP 출시 후 7년이 지났지만 언어 설계나 컴파일러 구현에서 거의 진전이 없었고, MVP를 주로 만들어낸 사람들이 비슷한 시기에 프로젝트 활동을 줄이면서 이후 전달이 멈춰버린 상태임
이 작업을 하려는 사람이 필요한 지원을 받았으면 함
I want to work on this in the compiler and as such have submitted it as a Project Goal
Stop generating statemachines that don’t have to be there
Make the compiler’s job easier by removing panic paths and branches
Make statemachines smaller
이 문제가 다뤄지는 걸 보니 좋음. 지금 rustc가 LLVM에 너무 많은 코드를 넘기고 최적화기가 전부 잡아주길 기대한다는 글을 몇 번 봤는데, 특히 이 글은 그 작업을 위한 자금 지원도 요청하고 있음
맙소사, 내가 멍청했음
async는 어떤 형태로든 런타임, 작업 추적, 완료를 확인하는 폴링이 필요하니 본질적으로 “비대하다”고 늘 생각했음. 그 오버헤드는 0이 아니니까
여기서 말하는 “무비용 추상화”는 언어 기능에 관한 것이고, 덧붙여진 런타임과는 별개라고 여겼음
LLVM에 넘기기 전에 rustc가 무엇을 내보내는지 살펴볼 생각조차 못 했음
async Rust에 익숙하지 않은 사람들을 위해:
It's amazing how we can write executor agnostic code that can run concurrently on huge servers and tiny microcontrollers.
이건 정말 맞는 말임. async 호출이 중첩된 트리도 최대 최적화를 거치면 내부에 상태 기계를 가진 단일 구조체로 굳어짐. 정말 영리한 방식임
릴리스 빌드에서 이 경우에 도달하면 일종의 교착 상태가 생기는 건가? 아니면 항상 Pending인 작업을 기다리는 태스크들 때문에 누수가 생길 수도 있나?
맞음. 그런 future들은 멈춘 상태가 되어 절대 완료되지 않음. 다만 그런 상태는 이미 버그가 있는 저수준 async 코드에서만 도달할 수 있고, 완료된 future를 제대로 추적하지 못하는 코드는 아마 이미 누수와 교착을 만들고 있을 가능성이 큼 .await로는 잘못된 폴링을 할 수 없음
몇 가지 생각이 듦:
이 글은 더 많은 최적화 로직을 LLVM 밖으로 빼서 MIR 계층으로 옮겨야 한다는 주장처럼 보임. 예를 들어 async 함수 인라이닝이 LLVM보다 MIR에서 더 쉬운 이유는 이해됨. async에 대해 MIR에서 해냈다면, 그 로직을 동기 함수에도 일반화하고 LLVM의 일부 최적화 패스를 제거하면 어떨까 싶음. 큰 작업이라는 건 알고 있고 실용적인 질문이라기보다 방향성에 가까움. 프런트엔드/미들엔드 컴파일러가 어느 정도 복잡해지면 LLVM의 범용 최적화 상당수가 다른 곳으로 옮겨지는 편이 더 나을 수도 있어 보임
여전히 panic=unwind 가 마음에 들지 않음. 일부 테스트 하네스를 제외하면 비용을 상쇄할 만큼 panic=abort보다 나은 장점을 본 적이 거의 없음. 테스트 하네스조차도 Linux에서는 난해하게 clone을 써서 pthread_join 대신 실행 스레드를 wait하는 식으로 비슷한 선택 적용이 가능할 것 같음. 이 부분은 내가 틀렸을 수도 있음
링크가 다른 사람에게도 방금 죽었나?
수정: 블로그 글이 반초쯤 보이다가 404 페이지로 넘어감
수정 2: 블로그 글 목록으로 들어가서 이것저것 눌러봤고, 목록에 있는 그 글을 열어도 404 페이지로 감. 정적 페이지이거나 적어도 그래야 할 블로그를 어떻게 이렇게 망칠 수 있지?
말투가 조금 불필요하게 무례하고 공격적으로 느껴짐. 웹사이트에도 버그는 생길 수 있고, 보고하는 건 유용하지만 이 댓글은 좀 심술궂게 들림
참고로 같은 재현 절차를 따라본 것 같은데 나는 404가 전혀 안 나왔음. 휴대폰과 데스크톱에서, JavaScript를 켜고 끈 상태 모두 시도해 봄. 그래서 겪은 현상이 보기보다 더 복잡했을 수도 있어 보임
Lobste.rs 의견들
제목만 보고 예상했던 것보다 훨씬 건설적인 글이었음
이 작업을 하려는 사람이 필요한 지원을 받았으면 함
이 문제가 다뤄지는 걸 보니 좋음. 지금 rustc가 LLVM에 너무 많은 코드를 넘기고 최적화기가 전부 잡아주길 기대한다는 글을 몇 번 봤는데, 특히 이 글은 그 작업을 위한 자금 지원도 요청하고 있음
맙소사, 내가 멍청했음
async는 어떤 형태로든 런타임, 작업 추적, 완료를 확인하는 폴링이 필요하니 본질적으로 “비대하다”고 늘 생각했음. 그 오버헤드는 0이 아니니까
여기서 말하는 “무비용 추상화”는 언어 기능에 관한 것이고, 덧붙여진 런타임과는 별개라고 여겼음
LLVM에 넘기기 전에 rustc가 무엇을 내보내는지 살펴볼 생각조차 못 했음
async Rust에 익숙하지 않은 사람들을 위해:
이건 정말 맞는 말임. async 호출이 중첩된 트리도 최대 최적화를 거치면 내부에 상태 기계를 가진 단일 구조체로 굳어짐. 정말 영리한 방식임
릴리스 빌드에서 이 경우에 도달하면 일종의 교착 상태가 생기는 건가? 아니면 항상
Pending인 작업을 기다리는 태스크들 때문에 누수가 생길 수도 있나?.await로는 잘못된 폴링을 할 수 없음몇 가지 생각이 듦:
panic=unwind가 마음에 들지 않음. 일부 테스트 하네스를 제외하면 비용을 상쇄할 만큼panic=abort보다 나은 장점을 본 적이 거의 없음. 테스트 하네스조차도 Linux에서는 난해하게clone을 써서pthread_join대신 실행 스레드를wait하는 식으로 비슷한 선택 적용이 가능할 것 같음. 이 부분은 내가 틀렸을 수도 있음링크가 다른 사람에게도 방금 죽었나?
수정: 블로그 글이 반초쯤 보이다가 404 페이지로 넘어감
수정 2: 블로그 글 목록으로 들어가서 이것저것 눌러봤고, 목록에 있는 그 글을 열어도 404 페이지로 감. 정적 페이지이거나 적어도 그래야 할 블로그를 어떻게 이렇게 망칠 수 있지?
참고로 같은 재현 절차를 따라본 것 같은데 나는 404가 전혀 안 나왔음. 휴대폰과 데스크톱에서, JavaScript를 켜고 끈 상태 모두 시도해 봄. 그래서 겪은 현상이 보기보다 더 복잡했을 수도 있어 보임