“줄리아”과학 컴퓨팅 언어 프로젝트는 얼마나 성숙합니까?

현재 사용하는 C ++ 및 Python의 (일부) 대체품으로 수치 / 시뮬레이션 모델링 프로젝트에 사용할 새 언어를 배우는 것을 고려하고 있습니다. 나는 Julia 를 만났다 . 그것이 주장하는 모든 것을 수행한다면, 모든 프로젝트에서 C ++ 과 Python 을 대체하는 데 사용할 수 있습니다 .PyPlot을 포함한 고급 과학 컴퓨팅 라이브러리 코드에 액세스하고 C와 비슷한 속도로 루프를 실행할 수 있기 때문입니다. 또한 다른 언어 중 하나에는 존재하지 않는 적절한 코 루틴과 같은 것들로부터 이익을 얻을 것입니다.

그러나 현재 버전 0.x의 비교적 새로운 프로젝트이며 매일 사용할 준비가되지 않았다는 다양한 경고 (과거의 다양한 날짜에 게시 됨)를 발견했습니다. 결과적으로이 단계에서이 언어를 배우는 데 시간을 투자해야하는지 여부를 평가할 수 있도록 지금 프로젝트 상태 (2014 년 2 월 또는 답변이 게시 될 때마다)에 대한 정보를 원합니다.

Julia 프로젝트에 관한 특정 관련 사실에 중점을 둔 답변에 감사드립니다 . 다른 프로젝트에 대한 경험을 바탕으로 한 의견에 덜 관심이 있습니다.

특히 Geoff Oxberry의 의견에 따르면 Julia API는 여전히 유동적 인 상태에 있으며 코드가 변경 될 때 업데이트되어야합니다. API의 어느 영역이 안정적이며 어떤 영역이 변경 될 수 있는지에 대한 아이디어를 얻고 싶습니다.

필자는 일반적으로 선형 대수학 (예 : 고유 문제 해결), 많은 변수를 사용한 ODE의 수치 적분, PyPlot 및 / 또는 OpenGL을 사용한 플로팅, 낮은 수준의 C 스타일 숫자 크 런칭 (예 : Monte Carlo 시뮬레이션) ). Julia의 도서관 시스템이이 영역에서 완전히 개발 되었습니까? 특히, 이러한 유형의 활동에 대해 API가 다소 안정적입니까, 아니면 새 버전의 Julia로 업그레이드 한 후 이전 코드가 깨지는 경향이 있습니까?

마지막으로 현재 심각한 작업에 Julia를 사용할지 여부를 결정할 때 고려해야 할 다른 문제가 있습니까?

Julia는이 시점 (2019 년 5 월, v1.2가 출시 될 Julia v1.1)이 과학 컴퓨팅에 매우 적합합니다. v1.0 릴리스 는 연간 코드 중단으로 끝났다 . 이를 통해 많은 과학적 컴퓨팅 라이브러리가 중단없이 단순히 성장할 시간이있었습니다. Julia 패키지에 대한 광범위한 개요는 pkg.julialang.org 에서 찾을 수 있습니다 .

코어 과학 컴퓨팅 들어 DifferentialEquations.jl의 미분 방정식 (미분 방정식, SDES, DAE에, DDEs, 길레스피 시뮬레이션 등)을위한 라이브러리 Flux.jl 신경망 및 점프 수학적 프로그래밍 (최적화 라이브러리 : 선형, 이차, 혼합 정수 등 프로그래밍)은 과학 컴퓨팅 생태계의 세 가지 초석입니다. 특히 EPIRK 적분기 , Runge-Kutta-Nystrom , Stiff / Differential-Algebraic 지연 미분 방정식 등의 기능을 구현하는 대규모 개발 팀과 함께 미분 방정식 라이브러리는 다른 언어에서 볼 수있는 것보다 훨씬 더 개발되었습니다.적응 시간 강성 확률 론적 미분 방정식 적분기와 함께 인접 감도 분석 , 화학 반응 DSL , 행렬이없는 뉴턴-크릴 로프, 완전한 (데이터 전송이없는) GPU 호환성, 신경 미분 방정식의 훈련 과 함께 환상적인 벤치 마크 결과 (면책 조항 : 저는 수석 개발자입니다).

성숙 된 Julia 생태계에 대해 약간 염려하는 것은 그 호환성입니다. 기본적으로 누군가 누군가 DifferentialEquations.jl에있는 것과 같은 일반 라이브러리 함수를 작성할 때 모든 AbstractArray / Number 유형을 사용하여 새 코드를 즉시 생성 할 수 있습니다. 예를 들어, 오류 전파 라이브러리 ( Measurements.jl )가 있으며이를 ODE 솔버에 고정하면 매개 변수 샘플링없이 오류 전파를 수행 하는 새 버전의 ODE 솔버 가 자동으로 컴파일됩니다 . 이로 인해 기능 코드가 자체 생성되므로 라이브러리 기능에 대해 더 많이 생각해야하므로 일부 기능이 문서화되어 있지 않을 수 있습니다.

구성이 가장 유용한 방법 중 하나는 선형 대수학입니다. 예를 들어 ODE 솔버를 사용하면 jac_prototype내부적으로 사용될 Jacobian에 대한 유형 을 지정할 수 있도록을 지정할 수 있습니다. 물론 물건을 거기에 LineraAlgebra 표준 라이브러리 와 같은 Symmetric과 Tridiagonal당신은 유형 일반적인 알고리즘 composibility의 유틸리티, 사람들이 지금 사라지고 전체 배열 형식 라이브러리를 구축 주어진 여기에 사용하지만, 수 있습니다. BandedMatrices.jl 및 BlockBandedMatrices.jl 은 빠른 lu과부하 를 갖는 (블록) 밴딩 매트릭스 유형을 정의하는 라이브러리로 , 부분 미분 방정식 시스템의 뻣뻣한 MOL 이산화 솔루션을 가속화하는 좋은 방법입니다. PDMats.jl양의 한정 행렬을 지정할 수 있습니다. Elemental.jl를 사용하면 분산 희소 자 코비안을 정의 할 수 있습니다. CuArrays.jl 은 GPU에서 배열을 정의합니다. 기타.

그런 다음 모든 숫자 유형이 있습니다. Unitful.jl 은 컴파일 타임에 단위 검사를 수행하므로 오버 헤드가없는 단위 라이브러리입니다. DoubleFloats.jl 은 Quadmath.jl 및 ArbFloats.jl 과 함께 초고속 정밀 라이브러리 입니다. ForwardDiff.jl 은 이중 숫자 산술을 사용하는 순방향 모드 자동 차별화를위한 라이브러리입니다. 그리고 나는 이것을 계속 나열 할 수 있습니다. 그리고 예, DifferentialEquations.jl과 같은 충분히 일반적인 Julia 라이브러리에 넣어 이러한 숫자 유형에 맞게 특별히 최적화 된 버전을 컴파일 할 수 있습니다. ApproxFun.jl 와 같은 것 조차Chebfun과 같은 대수 객체로 기능하는이 일반 시스템에서 작동하므로 함수 공간의 스칼라에서 PDE를 ODE로 지정할 수 있습니다.

호환성의 장점과 유형이 일반적인 Julia 함수에서 새롭고 효율적인 코드를 생성하는 데 사용할 수있는 방법을 고려할 때 핵심 과학 컴퓨팅 기능을 순수한 Julia로 구현하기위한 많은 작업이있었습니다. Optim.jl 비선형 최적화는 NLsolve.jl는 비선형를 해결하기위한, IterativeSolvers.jl는 선형 시스템 eigensystems의 반복 해법 들어 BlackBoxOptim.jl는 블랙 박스 최적화 등과도 신경망 라이브러리 Flux.jl는 단지 CuArrays를 이용한다. GPU의 기능을 위해 GPU에 대한 코드의 자동 컴파일. 이 호환성은 DiffEqFlux.jl에서 신경 미분 방정식 과 같은 것을 생성 한 핵심 이었습니다.. Turing.jl 과 같은 확률 적 프로그래밍 언어 도 이제는 매우 성숙하고 동일한 기본 툴링을 사용합니다.

Julia의 라이브러리는 기본적으로 코드 생성 도구를 기반으로하기 때문에 코드 생성과 관련하여 많은 도구가 있다는 것은 놀라운 일이 아닙니다. Julia의 브로드 캐스트 시스템 은 위에서 언급 한 많은 기능을 제공하기 위해 어레이 유형 에 의해 오버로드 된 융합 커널을 즉시 생성 합니다. CUDAnative.jl을 사용하면 Julia 코드를 GPU 커널로 컴파일 할 수 있습니다. ModelingToolkit.jl은 자동으로 AST를 수학 코드를 변환하기위한 상징적 시스템으로 추출합니다. 카세트 .jl규칙을 사용하여 컴파일 시간 전에 함수를 변경하는 규칙을 사용하여 다른 사람의 기존 함수를 "더빙"할 수 있습니다 (예 : 모든 배열 할당을 정적 배열 할당으로 변경하고 GPU로 작업 이동). 이것은 고급 도구입니다 (과학 컴퓨팅을하는 모든 사람들이 컴파일러를 직접 제어 할 것으로 기대하지는 않습니다). 그러나 이것은 많은 차세대 도구가 작성되는 방법 (또는 기능 자체 작성 방법)입니다.

병렬 처리에 관해서는 GPU를 언급했으며 Julia는 내장 멀티 스레딩 및 분산 컴퓨팅을 제공 합니다. Julia의 멀티 스레딩은 곧 병렬 작업 런타임 (PARTR) 아키텍처를 사용하여 중첩 된 멀티 스레딩의 자동 스케줄링을 가능하게합니다 . MPI를 사용하려면 MPI.jl을 사용 하면 됩니다. 물론 모든 것을 사용하는 가장 쉬운 방법은 AbstractArray 유형 설정을 사용하여 작업에서 병렬 처리를 사용하는 것입니다.

Julia는 또한 과학 응용 프로그램에 사용되는 범용 언어를 기대할 수있는 기본적인 기본 에코 시스템을 보유하고 있습니다. 그것은이 주노 IDE A를 중단 점과 내장 디버거 , 그것은이 Plots.jl를 플롯의 모든 종류를 만들기위한. Revise.jl 이 파일을 저장할 때 함수 / 라이브러리를 자동으로 업데이트하는 것과 같이 많은 특정 도구도 유용 합니다. 당신은 당신이 DataFrames.jl , 통계 라이브러리 등 가장 좋은 라이브러리 중 하나는 실제로 Distributions.jl 당신은 예를 들어 분포 (제네릭 알고리즘을 작성할 수 있습니다 :rand(dist)임의의 분포가 전달 된 임의의 수를 취하고 일 변량 및 다변량 분포의 전체로드가 있습니다 (물론 디스패치는 컴파일 타임에 발생하므로 분포에 특정한 함수를 하드 코딩하는 것만 큼 빠릅니다). 이름을 지정 하는 많은 데이터 처리 툴링 , 웹 서버 등이 있습니다. 이 시점에서 기본적인 과학적인 것이 있고 그것이 존재하기를 기대한다면 .jl 또는 Julia를 사용하여 Google에 표시하면 나타날 것입니다.

그런 다음 수평선에 명심해야 할 것이 몇 가지 있습니다. PackageCompiler 는 Julia 라이브러리에서 바이너리를 빌드하려고 시도하고 있으며 이미 성공했지만 더 많은 개발이 필요합니다. Makie.jl 은 대화 형 기능이있는 GPU 가속 플로팅을위한 전체 라이브러리이며 여전히 더 많은 작업이 필요하지만 Julia의 기본 플로팅 라이브러리가 되고자합니다. Zygote.jl 은 추적 기반 AD (Flux 's Tracker, PyTorch, Jax)의 성능 문제가없고 모든 순수 Julia 코드에서 작동하는 소스-소스 자동 차별화 라이브러리입니다. 기타.

결론적으로 많은 곳에서 많은 움직임을 찾을 수 있지만 대부분의 지역에는 이미 성숙 된 도서관이 있습니다. 더 이상 "어떻게 채택 할 것인가?"라는 질문을받는 곳이 아닙니다. 줄리아는 충분한 사람들 (수백만 다운로드)에 의해 입양되어 좋은 상태를 유지하기위한 추진력이 있습니다. 정말 멋진 커뮤니티가 있으므로 바람을 parallel 고 병렬 컴퓨팅 또는 수치 미분 방정식에 대해 이야기하고 싶다면 Julialang Slack 에 가장 적합한 대화방이 있습니다 . 학습해야 할 언어인지 여부는 개인적인 질문이며, 프로젝트에 적합한 언어인지는 기술적 인 문제이며 다른 것입니다. 그러나 언어가 성숙하고 일관된 대규모 개발자 그룹의 지원을받는 언어입니까? 그것은 긍정적 인 예인 것 같습니다.

그렇지 않은 경우 다시 고려하기 전에 얼마나 기다려야하는지 대략적인 크기 순서를 지정할 수 있습니까?

컴퓨터 과학 언어를 성숙시키는 데 걸리는 시간에 대한 대략적인 크기의 추정치는 약 10 년입니다.

예 1 : SciPy는 2001 년 정도에 시작되었습니다. 2009 년 Scipy 0.7.0이 릴리스되었고 ODE 통합자는 VODE에 대한 인터페이스를 가졌습니다 ( ode15s대략 ode15sNDF 기반, VODE는 BDF / Adams-Bashforth에 따라 다름). SciPy 0.10.0의 인터페이스 dopri5는 MATLAB과 거의 동일 ode45하며 Runge-Kutta 4 차 방법은 일반적으로 학부생에게 최초의 실제 수치 통합 방법으로 도입되었습니다. SciPy 0.10.0은 2011 년 12 월에 출시되었으며, 내가 아는 모든 엔지니어링에 소개 된 MATLAB의 기능을 포함하는 데 약 10 년이 걸렸습니다.

예 2 : Mathworks는 1984 년에 설립되었습니다. 첫 번째 릴리스에서 그들은 JACKPAC이라는 C에 LAPACK 포트를 사용했습니다 (MathWorks 엔지니어 Jack Little의 이름을 딴). 2000 년까지 LAPACK으로 교체하지 않았습니다.

줄리아는 시간이 덜 걸릴지 모르지만 창립에서 주류가되기까지 약 10 년이 걸렸습니다. (이미 1 년 정도 지났지 만 9-10 년이 되었을까요?)

Julia의 도서관 시스템이이 영역에서 완전히 개발 되었습니까? 특히, 이러한 유형의 활동에 대해 API가 다소 안정적입니까, 아니면 새 버전의 Julia로 업그레이드 한 후 이전 코드가 깨지는 경향이 있습니까?

나는 Julia를 사용하지 않으므로 Jeff Bezanson이 Julia에 대한 프레젠테이션을하는 것을 보았으므로 소금 한 알로 말을하십시오. C, Python 및 Fortran의 라이브러리를 쉽게 연결하고 사용할 수 있도록 뒤로 구부 렸습니다. 원하는 작업을 수행하는 Julia 라이브러리를 찾을 수없는 경우 라이브러리에 대한 Julia Shim을보다 확실한 언어로 작성하십시오. 결과적으로 라이브러리 부족이 걱정되지 않는다고 생각합니다. 핵심 언어 기능에 대한 변경 사항이 엉덩이를 물지 않도록하는 것이 우려가 될 것이라고 생각합니다. Julia Git 리포지토리에서 이정표를 보면 "breaking"태그가 상당히 많이 사용 된 것을 볼 수 있습니다 (0.2 릴리스에서는 12 회, 0.3 릴리스에서는 5 회). 나에게 그것은 핵심 언어가 여전히 발전하고 있음을 시사하므로 지금 언어를 사용하는 것을 망설입니다.

편집 : Aurelius는 좋은 지적을 제시합니다.

줄리아가 실제로 주류가 될 것이라고 생각하는 이유는 무엇입니까? 다른 많은 언어처럼 모호하게 죽지 않을까요? SciPy / numpy는 줄리아가 가지고 있지 않은 점점 커지는 파이썬 커뮤니티의 후원을 받았습니다.

원래 답변에서 나는 "줄리아가 주류가되는 데 성공할 것인가?"라는 질문을 피하기로 결정했습니다. 가능한 한 많이. 실패는 쉽습니다. 성공은 어렵다. Julia의 가장 좋은 비교는 MATLAB, R 및 Octave와 같은 기술 컴퓨팅 언어에 대한 것입니다. HPC 언어 (Chapel, Fortress, UPC 등)는 기술 컴퓨팅 언어보다 폭이 좁고 범용 언어 (C, Python, C ++ 등)는 기술 컴퓨팅 언어보다 폭 넓습니다.

Julia에게 도움이되는 것은 표현력을 희생하지 않으면 서 성능을위한 디자인입니다. Julia는 MATLAB, R 또는 심지어 Python보다 C와 같은 컴파일 된 언어에서 훨씬 더 경쟁력이 있습니다. 이 디자인 목표는 다음과 같은 기존 언어에서 사람들을 끌어들이는 기능이기도합니다.

• 성능에 대해 많은 관심과 C와 포트란 같은 언어에서 오는, 그러나 희생하고자하는 사람들 의 작은 성능의 비트 (2ish의 어쩌면 요인)는 REPL에 따라 (해석 언어의 적은 라인에 컴파일 된 언어에서 이동합니다 더 빠른 개발 및 테스트).
• 높은 생산성에 관심이 있고 Python, R 및 MATLAB과 같은 언어를 사용하지만 더 많은 성능을 원하는 사람들. 실행에 관해서는 순수한 파이썬, 순수한 MATLAB 및 순수한 R이 느립니다. 이러한 언어를 사용하는 개발자는 라이브러리를 컴파일 된 언어로 래핑하지 못했지만 모든 것을 래핑 할 수 없으며 어느 시점에서 핵심 언어로 인해 속도가 느려질 수 있습니다. 코어 줄리아가 빠를수록 더 많은 과학을 할 수 있습니다.
• 자유 소프트웨어에 관심이있는 사람들. Julia는 해석되고 무료입니다 (Python, Octave 등도 마찬가지 임). MATLAB은 아닙니다.

Julia는 또한 병렬 처리를 촉진하려고합니다. 나는 그 시점에서 확장 할 수있는 자격이 없다고 생각하며, 그것이 언어의 주된 견해라고 생각하지는 않지만, 그것이 그들이 작업하고있는 판매 포인트라고 생각하며, 다른 사람들이 그것에 대해 밝힐 수 있기를 바랍니다.

그러나 기술적 인 장점이 있더라도 언어 제작자는 언어를 홍보하고 복음을 전파하기 위해 다리를 밟아야합니다. Jeff Bezanson, Alan Edelman, Stephen Karpinski 및 Viral Shah는 언어를 성공시키기 위해 열심히 노력하고 있습니다. Alan Edelman은 전산 과학 커뮤니티와 긴밀한 관계가 있으며, 전에 언어 수준 프로젝트 (특히 MATLAB에 대한 Star-P 확장)에서 일했습니다. Jeff Bezanson은 컨퍼런스 회로를 수행하여 Julia를 계산 과학자 및 엔지니어에게 잠시 홍보했습니다. MIT에서 그들은 Julia에 도서관을 추가하여 학생과 교직원 (특히 Steven G. Johnson)을 모집하는 일을 잘 해왔습니다. 그들은 Wired에 기사를 가지고 있으며 1 년 만에 Wikipedia 기사를 얻을 수있었습니다. 그들의 Git 저장소에는 수천 개의 별, 수백 개의 포크가 있으며 오픈 소스 표준에 따라 수백 개의 시계가 성공을 거두었습니다. 나는 그들이 지금까지 옳은 일을했다고 생각하기 때문에 그 노력을 지속하고 공동체를 구축하는 것이 중요합니다. 그들은 여전히 ​​실패 할 수 있지만, 이것을 멀리하면 성공할 수있는 합리적인 기회가 있음을 알 수 있습니다.

줄리아가 배울 가치가 있다고 생각합니다. 나는 그것을 사용하여 몇 가지 연구 유한 요소 코드를 생성하고 매우 빨리 생성했습니다. 나는 내 경험에 매우 기뻐했습니다.

Julia는 다른 언어로는 달성하기 어려운 워크 플로를 구현했습니다. MATLAB과 같은 프로토 타이핑 언어로 사용할 수 있지만 작업 코드가 있고 속도를 높이기 위해 반복을 프로파일 링 할 때 MATLAB과 달리 핫스팟을 C 코드로 바꾸는 것은 쉽지 않습니다. 그들은 디자인에서 C (및 Python)와의 인터페이스를 우선 순위로 삼았습니다.

따라서이 언어를 통해 수학 공식에서 기능 코드로, 기능 코드에서 고성능 코드로 매우 빠르게 이동할 수있었습니다. Julia의이 기능은 과매도 된 것으로 생각되지만 엄청난 가치가 있습니다.

많은 경우에 기능 유한 요소 코드를 생성 한 후 몇 시간 만에 C 성능 (내 C 코드와 비교)을 얻었습니다. 지금까지 Julia 기능 만 사용하는 경우 일반적으로 C보다 ~ 3 배 느려집니다.이 후 핫스팟을 C 함수로 바꿉니다 (Julia는이를 식별하기 위해 스택 샘플링 프로파일 러와 함께 제공됨). 종종 이것은 문제가되는 핫스팟 코드 라인을 "콜"로 교체하기 만하면됩니다. Julia는 마샬링을 처리합니다.

줄리아가 지금 놓친 주요한 점은 더 큰 프로젝트를 위해 주저하는 것을 망설이는 것입니다. 완전히 지원되는 디버거가 없으며 플로팅에 대한 지원이 부족합니다 (지금 플로팅에 대한 최선의 베팅은 실제로 matplotlib의 인터페이스 일뿐입니다) 내가 더 자주 휴식을 취했다는 것). 코드에 대한 즉각적인 피드백이 정말 중요합니다. 나는 또한 대화식 디버깅없이 생존하는 방법을 모른다.이 점에서 나는 MATLAB과 GDB에 의해 매우 망친다.

내 경험상 Julia는 (과학적으로) 매일 사용할 준비가되지 않았습니다 (2016 년 3 월의 안정화 된 버전 0.4에 대해 이야기하고 있습니다). 언어 자체는 훌륭하고 기능이 풍부하며 일관성이 있습니다. matlab과 python 모두에서 상쾌한 발전. Julia가이 초기 단계에서도 좋은 선택이되는 경우가 있습니다. 그러나 신뢰할 수 있고 성숙한 과학 라이브러리가 필요한 경우 지금 옮기는 것이 좋습니다. 내가 만난 주요 문제는 다음과 같습니다.

• Julia의 핵심이 아닌 패키지는 신뢰할 수 없습니다. 업데이트, 변경, 교체, 때로는 불완전하거나 단순히 고장난 경우가 있습니다.
• Julia의 병렬 처리 기능 (Im에서 가장 유망한 MATLAB 킬러 기능)은 미숙합니다. 분할 오류, 메모리 누수, 충돌 및 성능 저하가 발생합니다. 때로는 줄리아의 다른 부분, 예를 들어 선형 시스템이나 코어 외부의 패키지에 대한 솔버와 잘 어울리지 않습니다. 이러한 기능은 유망한 것으로 들리지만 종종 실패했습니다. 거의 @parallelfor 루프 앞에 글을 쓰는 것만으로는 충분하지 않았다 .
• 너무나도 좋고 때로는 잘못된 호출 스택 추적, 약간의 버그가있는 통역사 기록, 느린 패키지 로딩, 하나 또는 다른 패키지 / 기능의 나쁜 성능 등. 대부분은 matplotlib의 래퍼 인 PyPlot 패키지입니다. 현재이 패키지에 대한 대안은 없습니다. 거기에 있다는 것이 정말 좋으며 대부분 작동합니다. 그러나 데이터를 플로팅해야하는 경우 성능 저하 및 문제 발생에 대비하십시오.

이것은 모두 나아질 것입니다. 언젠가 줄리아가 거의 모든 측면에서 matlab과 python보다 우수 할 것이라고 확신합니다. 혁신적인 패키지가 개발 될 가능성이 높습니다. 이미 큰 커뮤니티가있는 것 같습니다. 지금도 opencl에서 웹 서버에 이르기까지 사용 사례가있는 다양한 패키지가 있습니다. 파이썬이나 c 라이브러리를 사용하는 것은 매우 쉬우므로 라이브러리 가용성 측면에서 벽에 부딪치지 않을 것입니다. Julia의 큰 장점은 현대적이고 일관된 고급 언어로 다양한 소스의 고성능 기능을 결합 할 수있는 손쉬운 노력입니다 (위 답변 참조). 그러나 전체적으로 나는 그것이 생산적으로 사용될 정도로 성숙하거나 안정적이지 않다는 것을 알았습니다.