Python 3.12용 Windows SciPy 빌드, 작은 기적으로 평가

• conda-forge의 SciPy Windows 빌드가 Python 3.12.0 출시 이틀 뒤 제공되어, SciPy 지점의 Python 3.12 마이그레이션이 몇 달 정체가 아니라 며칠 지연으로 진행됨
• Python 3.12에서 distutils가 표준 라이브러리에서 제거되면서, SciPy는 numpy.distutils 대신 Meson 빌드 도구로 이전하기로 결정함
• Meson은 conda-forge가 쓰던 MSVC+gfortran 조합을 거부할 예정이었고, Windows에는 conda-forge가 사용할 수 있는 무료 ABI 호환 Fortran 컴파일러가 없었음
• conda-forge는 Windows에서 SciPy를 재빌드하지 못할 경우 SciPy에 의존하는 최소 약 1,000개 패키지의 마이그레이션이 모든 플랫폼에서 지연되거나 Python 마이그레이션에서 Windows를 제외해야 하는 상황을 예상함
• LLVM 17.0은 Flang에서 -flang-experimental-exec 플래그를 제거한 첫 릴리스였고, Flang은 “0.8 level maturity” 수준으로 추정됨
• Meson에 llvm-flang 처리를 추가한 뒤 SciPy 빌드와 설치에 성공했고, 테스트는 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning으로 100% 통과함 {p:100}

[GN⁺]

Hacker News 의견들

• 정말 훌륭한 글이었고, 이제 Python 3.12에서 pip install이 실패하던 이유를 알게 됐지만 앞으로는 더 밝아 보임
  Python은 좋아하지만, Python 패키징이 왜 관리 가능한 수준의 난장판인지 이해하는 데도 도움이 됨
  원인은 Python 자체가 아니라 C/C++/Fortran 빌드 도구의 비표준화와 생태계의 거대함이며, 어느 정도는 줄일 수 없는 복잡성임
  이게 돌아간다는 것 자체가 기적에 가까움

  • 맞음, Python 패키징이 복잡한 근본 이유가 거기에 있음
    Python의 성공은 핵심 혼합 언어 패키지를 사용할 수 있었기 때문인 면이 크고, 다른 주류 언어 패키지 관리자는 이런 문제를 거의 다루지 않음
    예를 들어 Rust의 cargo는 훌륭하지만 대부분 Rust 전용 코드 패키징을 가정할 수 있고, 컴파일 언어이면서도 언어가 컴파일러를 “소유”하므로 소스 빌드 배포 전략이 통함
    cargo가 Fortran을 기본으로 어떻게 다루는지는 모르겠지만, Windows에서 상위 cargo 패키지들이 Fortran 코드를 요구한다면 잘 돌아가긴 어려울 것 같음
    Python 생태계의 가장 큰 개선은 바이너리 패키지 형식인 wheel의 표준화였고, 그때서야 과학 Python 생태계가 Windows에서 본격적으로 번성하기 시작함
    다만 바이너리 호환성은 특히 언어와 CPU를 넘나들 때 엄청난 골칫거리임
  • Python과 무관하다고 하기엔, 이런 FFI 바인딩이 존재하는 이유가 Python이 너무 느리기 때문임
  • “이게 돌아간다는 것 자체가 기적”이라는 데 동의함
    소프트웨어 생태계의 복잡도가 지수적으로 커지는 것처럼 보이는데, 결국 바벨탑식 붕괴로 가지 않게 막는 게 무엇인지 궁금함
    물론 소프트웨어에만 해당하는 문제는 아니지만, 좋은 예시가 됨
  • 정말 눈이 트이는 글이었음
    사람들이 자기가 좋아하는 패키지 관리자를 Python의 것과 비교하고 Python이 형편없다고 결론 내리는 걸 자주 보는데, 실제로는 그렇지 않음
    다만 잘 이해가 안 되는 건, 왜 Python 쪽 사람들이 Fortran 대신 C/C++ 수학 라이브러리를 쓰지 않는지임
  • 진짜 문제는 Python이 소프트웨어 개발 훈련을 받지 않은 사람들을 끌어들이는 경향이 있다는 데 있어 보임
    난장판 위에 또 난장판이 쌓인 셈임

• Linux가 느슨하게 조율된 해커들이 때로는 비실용적인 이념적 제약을 안고 운영하던 삐걱대는 변방 사례였을 때, 뛰어난 사람들이 거기에 지원을 붙이려고 엄청난 노력을 들인 건 환상적이었음
  그런데 이제 그 삐걱대는 변방 사례가 제약의 성격이 그냥 적대성에 가까운 독점 시스템이자 사이버 지주들이 운영하는 곳이 되니, 그걸 지원하려는 작업을 예전만큼 긍정적으로 보긴 어려움
  한편으로는 이런 도구를 모두가 쓸 수 있게 하려는 깊은 배려가 정말 훌륭하고, 그 작업에 박수를 보냄
  방향을 바꾸라고 하는 건 전혀 아니고, 그냥 곱씹게 됨
  예전엔 “와, 이 작업이 진행돼서 정말 다행이다”라고 생각했다면, 이제는 “와, 저 훌륭한 사람들이 이런 일에 매달리지 않아도 됐다면 무엇을 이뤘을까”라는 생각이 더 듦

  • 사실 그들이 꼭 해야만 하는 일은 아님
    여러 번 나온 것처럼 SciPy 개발자들은 자원봉사자임
    이야기의 대부분은 SciPy가 Windows용 오픈소스 Fortran 컴파일러를 누군가 만들어주길 바랄 수밖에 없었던 이유를 설명하고 있고, 구원은 주로 NVIDIA 개발자들이 제공한 것처럼 보임
  • 그것조차 핵심이 아님
    SciPy는 Python 핵심 개발자들이 Windows에서 Python용 도구 체인으로 MinGW 대신 MSVC를 선택한 어리석고 매우 편향된 결정의 대가를 치르는 중임
    그 동기는 Microsoft 후원에서 비롯됐다고 봄
    핵심 개발자 목록에는 Microsoft 직원들이 꽤 있고, 그들은 Microsoft로부터 그 목록에 참여하는 대가를 받으며, 게다가 Microsoft는 CPython 프로젝트의 CI 서버 비용도 댐
    Python이 도구 체인에 독점 도구를 쓰지 않았다면 이 전체 문제는 피할 수 있었음

• “Meson이 conda-forge에서 쓰이던 MSVC+gfortran 조합을 거부하려 했다”는 건 버그처럼 들림
  빌드 도구의 목적은 시킨 명령을 실행하는 것이지, “미안해요 Dave”라고 막는 게 아니라고 봄

  • 실제로 불평하는 쪽은 MSVC 링커임
    문제는 MSVC와 gfortran이 사용하는 C 런타임, 특히 gfortran 자체 런타임 라이브러리가 C로 작성되어 있는데, 이 둘이 ABI 호환이 되지 않는다는 점임
    NumPy가 썼던 우회법은 Fortran 객체들을 DLL로 링크해서 가져오기 라이브러리라는 간접 계층을 추가하고, MSVC를 달래는 방식이었음
    그래서 이런 DLL을 만들기 위한 추가 작업이 필요했음
    빌드 설명 파일에서 하든 Meson에서 하든 해야 했는데, SciPy 쪽은 어느 쪽에도 이 간접 계층을 구현하고 싶어 하지 않았고 Meson 개발자들도 적극적으로 도와주고 싶어 하지 않았음
    물론 Meson 개발자들은 Fortran과 Cython 지원 같은 일반적인 도움은 줬지만, 위험한 발판을 제공하고 싶진 않았던 것임
    실제로 이건 해킹에 가까웠고, 예를 들어 Fortran 쪽이 Python/C 쪽에서 연 파일을 사용하지 않았기 때문에만 동작했음
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • 글은 잘 쓰였고 자세했지만, Meson이 “C와 C++ 프로젝트에 널리 쓰인다”는 주장에는 좀 놀랐음
    개인적으로는 Meson보다 Bazel을 더 자주 봤음
    Meson이 Python으로 작성되어 있어서 SciPy에 좋은 선택처럼 보였던 것 같고, 결국 잘 풀렸으니 축하할 일임
    그래도 여러 괴상함과 복잡함과 문제가 있음에도 CMake가 여전히 표준에 가깝다고 봄
  • Meson은 단순히 사용자가 지시한 명령을 실행하는 것 이상을 함
    MSVC/gcc/clang을 지원할 수 있도록 명령 자체를 합성할 수도 있음
    모르는 조합에 대해 명령을 합성해 달라고 하면 당연히 “미안해요 Dave”라고 말할 수밖에 없음
  • 동의함
    곧 공개할 Meson 경쟁 빌드 시스템의 작성자라는 점은 밝혀둠
    다만 내가 방금 말한 걸 깨닫게 해준, 잘 알려지지 않은 작은 보석 같은 rant가 [1]임
    요약하면 빌드 시스템은 사용자가 실행하라고 한 명령을 실행해야 하며, 끝임
    가끔은 프로그래머가 정말 자기가 뭘 하는지 알고 있기 때문임
    부끄럽지만 그 댓글을 읽기 전에는 내 빌드 시스템을 마법처럼 만들 생각을 하고 있었음
    그런데 그 댓글을 읽고 나서, 사람들이 빌드 시스템을 싫어하는 이유가 바로 그 “마법”이라는 걸 깨달음
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• 이런 일은 다들 WSL2를 쓰고 끝내는 줄 알았음
  굳이 네이티브 Windows 버전을 빌드하려는 이유가 뭘까?

  • 그건 macOS 개발자들에게 네이티브 빌드를 원하지 말고 Linux 가상 머신에서 작업하면 되지 않냐고 묻는 것과 같음
    가상 머신에서 작업하는 건 불편하고 통합성도 떨어짐
  • 생각보다 훨씬 많은 연구자들이 Windows를 씀
    학생들도 그렇고
  • Windows가 아닌 장비를 받는 게 거의 불가능한 대기업들이 중요한 사용자층일 것 같음
  • Microsoft와 NVIDIA가 WSL2의 CUDA 드라이버 문제를 해결해준 건 정말 구원 같음
    특히 그 위에서 Docker Desktop을 쓸 수 있을 때 더 그렇다
    이상적이지 않은 상황에서 최선을 끌어내는 셈임

• καταστροφή의 κατα는 “갑작스러움”이 아니라 “아래로” 또는 “따라서”에 가깝고, 나쁜 방향으로 꺾인다는 함의가 강함
  κατα의 반대는 보통 ανα이지만 αναστροφή는 문자 그대로 “위로 도는 것” 또는 반전을 뜻함
  그래서 “좋은 전환”이라는 뜻의 ευστροφη, 즉 eustrophe가 더 나은 조어일지도 모름
  그래도 JRR Tolkien과 언어 조어를 두고 논쟁해 이긴다면 그건 ευκαταστροφη, 즉 행운일 것임
  전반적으로 넘치는 은총을 포착한 점이 좋고, 그런 것이 세상에 기쁨과 행복을 줌

  • katastrofi의 kata는 실제로는 “against”에 가까워서, katastrofi는 사물이 “등을 돌리는” 것에 해당함

• 최고의 BLAS들은 대체로 C로 되어 있다는 인상이 있음
  MKL, BLIS, OpenBLAS 같은 것들 말임
  C와 Python만으로 어디까지 갈 수 있었을지 궁금함
  지금 시작했다면 그냥 libflame을 택했을지도 궁금함
  물론 SciPy에는 반복법, 희소 행렬 등 다른 기능도 많으니 Fortran을 피하기 어려울 수도 있음
  그래도 Fortran은 훌륭한 언어이고, Windows에서 도구 상황이 적어도 개선되기 시작해 다행임

  • SciPy에서 Fortran 제거를 논의한 적은 몇 번 있었지만, 앞서 말한 이유들 때문에 진전되지 않았음
    SciPy 자체에도 Fortran 코드가 많이 들어 있고, 다시 작성하려면 수년 단위의 인력이 필요함
    가능해진 뒤에는 Fortran을 쓰던 핵심 부분 몇 가지가 제거되기도 했음
    예를 들면 FFT 관련 부분임
  • 솔직히 “Fortran은 훌륭한 언어이고, Windows에서 도구 상황이 개선되기 시작해 다행”이라는 문장을 2023년에 보게 될 줄은 몰랐음

• 훌륭한 글임
  올해 Python 바인딩이 있는 CMake C++ 프로젝트를 현대화하는 데 많은 시간을 썼고, 새 feedstock으로 conda-forge에 성공적으로 추가해본 뒤 자신 있게 말할 수 있음
  내가 신 황제가 된다면 IT 관련 첫 조치로 모든 우주에서 영원히 Windows를 뿌리 뽑을 것임

• 아주 순진한 질문이지만, Fortran 의미론이 그렇게 달라서 먼저 C로 변환한 뒤 C 컴파일러로 컴파일할 수 없는 건가?
  이후에는 C로 유지보수할 수도 있지 않을까?
  이런 오래된 라이브러리를 유지보수하는 Fortran 사람들이 많을 것 같지는 않은데, 그래도 유지보수는 필요하지 않나?

  • 느려져도 괜찮다면 가능함
    Fortran에는 포인터가 없고 배열만 있으며, 함수 인자가 별칭을 가질 수 없기 때문에, 일단 COMMON 블록의 공포는 제쳐두면, 공격적인 최적화와 벡터화가 더 쉬움
    표준 Fortran 수학 라이브러리들은 그냥 잘 동작하고 빠름
    C/C++에서도 특히 C의 restrict 키워드를 쓰면 동등한 속도의 코드를 작성할 수는 있음
    하지만 기존 코드를 f2c 단계로 변환하면 많은 경우 성능이 크게 나빠짐
  • Fortran은 C보다 더 고수준 언어임
    Fortran 개발자도 충분히 많음
    애플리케이션 개발에는 끔찍하지만, 그게 Fortran의 주 분야는 아님
  • 이미 그런 게 있음
    f2c는 수십 년 전부터 존재했음
  • 맞음, Fortran에는 네이티브 배열이 있음

• 한 가지 사소한 궁금증이 있는데, 내가 알기로 aarch64와 arm64는 같은 것임
  내가 잘못 알고 있나?

  • 같은 것이지만, 예전에는 백엔드 쪽에 경쟁하는 LLVM 구현이 두 개 있었음
    [1] https://www.phoronix.com/news/MTY5ODk
  • 필수 링크: https://lkml.org/lkml/2012/7/15/133
  • Python에서 내가 보기로는 aarch64는 보통 Linux를 가리키고, arm64는 보통 macOS ARM을 가리킴
    왜 이름이 다른지 이해할 만큼 이 분야를 잘 알지는 못함

• Python의 빌드 시스템 변동은 따라가기 정말 어려움
  Windows에서의 성능 수치도 궁금함
  다만 1차적으로는 중요하지 않을 수도 있음
  진지한 작업은 아마 Linux 머신에서 돌아갈 테니까

  • 다행히 이제는 느려질 것 같음
    큰 전환은 모두가 PEP 517을 받아들이게 하는 것이었고, 특히 기존 Setuptools 프로젝트를 전환하는 일이었음
  • 순수 CPU 계산에서는 Windows도 Linux만큼 빠름
    시간의 99.9%는 운영체제가 아니라 사용자 코드가 실행되기 때문임

[ahwjdekf]

바이너리 컴파일 언어에 빌어먹는 처지가 적나라하게 드러난경우네요.

[kayws426]

파이썬은 해결했지만 다른 생태계에서는 해결 못한것 아닌가요? 그래서 사전 빌드된 바이너리를 제공하겠지요.