GN⁺: 파이썬 3.12용 윈도우에서의 SciPy 빌드, 작은 기적으로 평가
(labs.quansight.org)파이썬 3.12 버전의 SciPy 빌드가 기적 같은 이유
- 최근 파이썬 3.12 버전이 출시됨.
- 주요 패키지들이 새 파이썬 버전과 호환되는 릴리스를 곧바로 내놓는 것은 일반적인 상황.
- SciPy가 파이썬 3.12와 호환되는 빌드를 출시한 것은 여러 타임라인이 겹치면서 발생한 행운의 결과.
Fortran과 컴파일러의 역할
- Fortran은 1950년대부터 중요한 프로그래밍 언어로, 많은 과학적 코드가 Fortran으로 작성됨.
- 다양한 Fortran 컴파일러가 존재했으나, 모두 독점적이었음.
- 컴파일러는 프로그래머가 작성한 코드를 컴퓨터가 실행할 수 있는 형태로 변환하는 역할을 함.
- GCC는 자유롭게 사용할 수 있는 컴파일러로, 다양한 CPU 아키텍처와 운영 체제를 지원함.
파이썬과 성능 문제
- 파이썬은 컴파일러 없이 사용할 수 있지만, 컴파일 언어에 비해 느림.
- 성능이 중요한 경우, 컴파일된 코드를 사용하되 파이썬 인터페이스로 래핑하는 것이 좋은 해결책임.
- NumPy와 SciPy는 성능을 위해 Fortran 코드를 사용하며, 이로 인해 사용자가 패키지를 설치할 때 컴파일러가 필요함.
파이썬 패키징의 문제
- 파이썬 패키징은 복잡성으로 인해 지속적으로 재발명되어야 했음.
- 소스 코드를 직접 다운로드하는 것은 사용자에게 컴파일러 설정이 필요하고, 빌드 시간이 오래 걸리는 등의 문제가 있음.
- "wheel" 포맷은 패키지에 필요한 라이브러리를 포함하여 배포하는 방식으로 개선됨.
conda와 conda-forge의 등장
- conda는 패키징에 필요한 모든 것을 포함하는 더 포괄적인 접근 방식을 제공함.
- conda-forge는 커뮤니티 주도로 패키지 통합 작업을 수행하는 채널임.
- conda-forge는 모든 일반적인 플랫폼을 지원하려 하며, 자원 봉사자에 의해 운영됨.
SciPy의 빌드 도구로 Meson 선택
- SciPy는 빌드 도구로 Meson을 선택함.
- Meson은 파이썬 스타일의 인터페이스를 제공하며, CMake보다 덜 복잡함.
- Meson은 전문가가 아닌 사용자에게는 잘못된 작업을 허용하지 않는 설계 철학을 가짐.
Fortran의 부활과 LLVM
- Fortran은 최근 몇 년 동안 관심이 증가함.
- LLVM 기반의 새로운 Fortran 컴파일러 개발이 활발해짐.
- LLVM은 다양한 아키텍처와 플랫폼에서 작동하는 컴파일러 인프라를 제공함.
SciPy의 Meson 전환과 conda-forge의 문제
- SciPy는 Meson으로 전환했지만, Windows용 Fortran 컴파일러 부재로 문제가 발생함.
- conda-forge는 Python 3.12 버전으로의 마이그레이션을 위해 모든 관련 패키지를 재빌드해야 함.
'유카타스트로피'의 의미와 GN⁺의 의견
- SciPy 테스트 스위트가 100% 통과하여, conda-forge에서 Python 3.12와 호환되는 SciPy 빌드가 가능해짐.
- 이는 여러 노력과 우연이 겹쳐진 결과로, 파이썬 커뮤니티에 큰 이득을 가져옴.
- GN⁺의 의견: 이 기사는 파이썬 커뮤니티의 노력과 협력이 어떻게 복잡한 기술적 문제를 해결할 수 있는지 보여줌. SciPy가 Python 3.12와 호환되는 빌드를 성공적으로 출시한 것은 과학 컴퓨팅 분야에서 중요한 진전이며, 이는 오픈 소스 소프트웨어의 강력함과 커뮤니티의 힘을 상징함.
Hacker News 의견
-
무료 소프트웨어 커뮤니티는 마이크로소프트의 운영 체제에 대한 지원을 중단하고, scipy와 같은 것들을 그들이 직접 포팅하게 해야 함
- 리눅스가 필요한 사람은 WSL2에서 찾을 수 있음
- 마이크로소프트는 다른 모든 운영 체제 벤더들이 60년 동안 해온 것처럼 컴파일러를 운영 체제에 포함시켜야 함
-
Python 패키징이 복잡한 이유는 C/C++/Fortran 빌드 도구의 비표준화와 거대한 생태계 때문이며, Python 자체의 문제는 아님
- 이 복잡성은 줄일 수 없는 부분임
- Python 패키징 시스템이 작동하는 것 자체가 기적임
-
Meson 빌드 도구가 MSVC+gfortran 조합을 거부하는 것은 버그로 보임
- 빌드 도구의 목적은 사용자가 지시한 명령을 실행하는 것이지, 사용자에게 거부하는 것이 아님
-
많은 사람들이 WSL2를 사용하여 문제를 해결하고 있으며, 네이티브 Windows 버전을 빌드하려는 이유가 궁금함
-
최고의 BLAS 라이브러리들이 대부분 C로 작성되었으며, C와 Python만으로도 어느 정도 성과를 낼 수 있을지 궁금함
- Fortran은 피할 수 없는 부분일 수도 있지만, Windows에서의 Fortran 도구 개선이 시작되어 긍정적임
-
Fortran의 의미 체계가 C와 너무 달라서 C로 변환한 후 C 컴파일러로 컴파일할 수 없는지, 그리고 C로 유지 관리하는 것이 가능한지에 대한 순진한 질문
- 오래된 라이브러리를 유지 관리하는 Fortran 전문가가 많지 않을 것으로 추정되며, 유지 관리가 필요함
-
Python의 빌드 시스템 변화를 따라가기 어려움
- Windows에서의 성능 수치에 대한 호기심이 있지만, 심각한 작업은 대부분 리눅스 기계에서 실행될 것으로 예상됨
-
"aarch64"와 "arm64"가 같은 것인지에 대한 질문
- Wikipedia에서 ARM64를 AArch64로 리다이렉트함
-
Fortran이 IT 부서에서 농담의 대상이었지만, 최근 몇 년 동안 극적인 부활을 경험함
- 이 부활의 이유는 명확하지 않지만, 관련 링크를 통해 이해할 수 있음
-
컴파일러/아키텍처 표에서 "arm64"와 "aarch64"의 차이에 대한 질문
- Wikipedia의 ARM64 문서가 AArch64로 리다이렉트되는 것에 대한 언급