Làm thế nào trưởng thành là dự án ngôn ngữ máy tính khoa học Julia Julia?


55

Tôi đang xem xét việc học một ngôn ngữ mới để sử dụng cho các dự án mô hình số / mô phỏng, như là một sự thay thế (một phần) cho C ++ và Python mà tôi hiện đang sử dụng. Tôi tình cờ gặp Julia , nghe có vẻ hoàn hảo. Nếu nó làm mọi thứ mà nó tuyên bố, tôi có thể sử dụng nó để thay thế cả C ++ Python trong tất cả các dự án của mình, vì nó có thể truy cập mã thư viện máy tính khoa học cấp cao (bao gồm cả PyPlot) cũng như chạy các vòng lặp với tốc độ tương tự C. Tôi cũng sẽ được hưởng lợi từ những thứ như coroutines thích hợp không tồn tại trong một trong các ngôn ngữ khác.

Tuy nhiên, đây là một dự án tương đối mới, hiện đang ở phiên bản 0.x và tôi đã tìm thấy nhiều cảnh báo khác nhau (được đăng vào các ngày khác nhau trong quá khứ) rằng nó chưa hoàn toàn sẵn sàng để sử dụng hàng ngày. Do đó, tôi muốn có một số thông tin về tình trạng của dự án ngay bây giờ (tháng 2 năm 2014 hoặc bất cứ khi nào câu trả lời được đăng), để giúp tôi đánh giá liệu cá nhân tôi có nên xem xét đầu tư thời gian để học ngôn ngữ này trong giai đoạn này hay không.

Tôi sẽ đánh giá cao câu trả lời tập trung vào các sự kiện cụ thể có liên quan về dự án Julia ; Tôi ít quan tâm đến ý kiến ​​dựa trên kinh nghiệm với các dự án khác.

Cụ thể, một nhận xét của Geoff Oxberry cho thấy rằng API Julia vẫn đang trong tình trạng thay đổi liên tục, yêu cầu mã phải được cập nhật khi thay đổi. Tôi muốn biết ý tưởng về mức độ của trường hợp này: khu vực nào của API ổn định và có khả năng thay đổi?

Tôi đoán thông thường tôi hầu như sẽ thực hiện đại số tuyến tính (ví dụ: giải các biểu thức riêng), tích hợp số ODE với nhiều biến số và vẽ đồ thị bằng PyPlot và / hoặc OpenGL, cũng như bẻ khóa số C ở mức độ thấp (ví dụ như mô phỏng Monte Carlo ). Hệ thống thư viện của Julia có được phát triển đầy đủ trong các lĩnh vực này không? Cụ thể, API ít nhiều ổn định hơn cho các loại hoạt động đó hay tôi sẽ thấy rằng mã cũ của mình sẽ có xu hướng bị hỏng sau khi nâng cấp lên phiên bản mới của Julia?

Cuối cùng, có bất kỳ vấn đề nào khác đáng để xem xét khi quyết định có nên sử dụng Julia cho công việc nghiêm túc ở thời điểm hiện tại không?


2
Câu hỏi này có vẻ như không phù hợp với định dạng Stack Exchange vì nó mang tính chủ quan. Tôi biết một số người phát triển tích cực ở Julia, yêu thích nó và nghĩ rằng nó hoàn toàn sẵn sàng cho thời gian chính (miễn là bạn sẵn sàng cập nhật cơ sở mã của mình để đáp ứng với những thay đổi trong API Julia). Có những người khác không cảm thấy cần phải sử dụng Julia ngay bây giờ (như tôi).
Geoff Oxberry

1
Việc chủ quan không tự nó làm cho một câu hỏi không phù hợp với định dạng Stack Exchange - xem blog.stackoverflow.com/2010/09/good-subjective-bad-subjective . Nếu bạn có một chính sách trang web chống lại các câu hỏi chủ quan thì tôi xin lỗi. Tuy nhiên, tôi nghĩ rằng đó chỉ là một chút chủ quan: nhận xét của bạn cho tôi ý tưởng tốt hơn về tình huống so với trước khi đặt câu hỏi. Người ngoài có thể rất khó để có được một ý tưởng sơ bộ về mức độ trưởng thành của một dự án.
Nathaniel

Quan điểm của bạn về các thay đổi API có vẻ khá quan trọng đối với tôi, vì vậy tôi đã thêm một đoạn vào câu hỏi hỏi cụ thể để biết chi tiết về nó. Nếu cập nhật Julia sẽ có xu hướng phá vỡ mã cũ của tôi, đó có thể là một chút phá vỡ đối với tôi trong giai đoạn này.
Nathaniel

Bạn hoàn toàn đúng về "chủ quan tốt so với chủ quan xấu" (một trong những bài đăng trên blog Stack Exchange yêu thích của tôi); Tôi đã đăng bình luận vì tôi đang chờ xem phản hồi. Với những "bạn nghĩ gì về _____?" câu hỏi, câu trả lời có thể được giới hạn trong một vài bài viết rất chu đáo, hoặc chúng có thể ngổn ngang, khắp nơi, lặp đi lặp lại "tôi cũng vậy!" bài viết. Cái trước là tuyệt vời; cái sau thì không, vì vậy tôi sẽ cho bạn một phép lịch sự để nói: hãy xem cái này diễn ra như thế nào.
Geoff Oxberry

3
Cảm ơn bạn đã đăng tiền thưởng, @AntonMenshov. Tôi lưu ý rằng Julia hiện đã vượt qua phiên bản 1.0 (mà nó đã không có vào năm 2014 khi tôi đăng bài này), vì vậy thực sự sẽ rất tốt nếu có câu trả lời cập nhật.
Nathaniel

Câu trả lời:


43

Julia, tại thời điểm này (tháng 5 năm 2019, Julia v1.1 với v1.2 sắp ra mắt) khá trưởng thành cho điện toán khoa học. Bản phát hành v1.0 biểu thị sự phá vỡ mã hàng năm . Cùng với đó, rất nhiều thư viện máy tính khoa học đã có thời gian đơn giản phát triển mà không bị gián đoạn. Tổng quan về các gói Julia có thể được tìm thấy tại pkg.julialang.org .

Đối với máy tính khoa học cốt lõi, các DifferentialEquations.jl thư viện cho phương trình vi phân (ODEs, SDEs, mô phỏng DAEs, DDEs, Gillespie, vv), Flux.jl cho các mạng thần kinh, và nhảy thư viện cho lập trình toán học (tối ưu hóa: tuyến tính, bậc hai, số nguyên hỗn hợp, vv lập trình) là ba trong số các nền tảng của hệ sinh thái điện toán khoa học. Thư viện phương trình vi phân nói riêng phát triển hơn nhiều so với những gì bạn thấy trong các ngôn ngữ khác, với một nhóm phát triển lớn thực hiện các tính năng như tích hợp EPIRK , Runge-Kutta-Nystrom , phương trình vi phân trì hoãn Stiff / vi sai-đại sốCác nhà tích hợp phương trình vi phân ngẫu nhiên cứng thời gian thích ứng , cùng với một loạt các tính năng khác như phân tích độ nhạy của sự điều chỉnh , DSL phản ứng hóa học , Newton-Krylov không có ma trận và khả năng tương thích GPU đầy đủ (miễn phí truyền dữ liệu), với việc đào tạo các phương trình vi phân thần kinh , tất cả đều có kết quả điểm chuẩn tuyệt vời (từ chối trách nhiệm: Tôi là nhà phát triển chính).

Điều có một chút suy nghĩ về hệ sinh thái Julia trưởng thành là khả năng kết hợp của nó. Về cơ bản, khi ai đó xây dựng một hàm thư viện chung giống như các hàm trong differentialEquations.jl, bạn có thể sử dụng bất kỳ loại Tóm tắt / Số nào để tạo mã mới một cách nhanh chóng. Vì vậy, ví dụ, có một thư viện để truyền lỗi ( Methurements.jl ) và khi bạn dán nó vào bộ giải ODE, nó sẽ tự động biên dịch một phiên bản mới của bộ giải ODE thực hiện lan truyền lỗi mà không cần lấy mẫu tham số . Do đó, bạn có thể không tìm thấy một số tính năng được ghi lại vì mã cho các tính năng tự tạo và do đó bạn cần suy nghĩ thêm về thành phần thư viện.

Một trong những cách mà thành phần hữu ích nhất là trong đại số tuyến tính. Ví dụ, bộ giải ODE cho phép bạn chỉ định jac_prototype, cho phép bạn cung cấp loại cho Jacobian sẽ được sử dụng nội bộ. Tất nhiên có những thứ trong thư viện tiêu chuẩn LineraAlgebra như SymmetricTridiagonalbạn có thể sử dụng ở đây, nhưng được cung cấp tiện ích về khả năng kết hợp trong các thuật toán chung loại, giờ đây mọi người đã đi và xây dựng toàn bộ thư viện kiểu mảng. BandedMatrices.jlBlockBandedMatrices.jl là các thư viện xác định các loại ma trận dải (Block) có luquá tải nhanh , làm cho chúng trở thành một cách hay để tăng tốc độ giải quyết MOL cứng của các hệ phương trình vi phân từng phần. PDMats.jlcho phép đặc tả các ma trận xác định dương. Elemental.jl cho phép bạn xác định một Jacobian thưa thớt phân tán. CuArrays.jl định nghĩa các mảng trên GPU. Vân vân.

Sau đó, bạn có tất cả các loại số của bạn. Unitful.jl thực hiện kiểm tra đơn vị tại thời gian biên dịch để nó là thư viện đơn vị không có phí. DoubleFloats.jl là một thư viện có độ chính xác cao nhanh hơn, cùng với Quadmath.jlArbFloats.jl . ForwardDiff.jl là một thư viện để phân biệt tự động ở chế độ chuyển tiếp sử dụng số học số kép. Và tôi có thể tiếp tục liệt kê những thứ này ra. Và vâng, bạn có thể ném chúng vào các thư viện Julia đủ chung chung như differentialEquations.jl để biên dịch một phiên bản được tối ưu hóa cụ thể cho các loại số này. Thậm chí một cái gì đó giống như ApproxFun.jlcó chức năng như các đối tượng đại số (như Chebfun) hoạt động với hệ thống chung này, cho phép đặc tả các PDE dưới dạng ODE trên vô hướng trong một không gian hàm.

Với những lợi thế của khả năng kết hợp và cách các loại có thể được sử dụng để tạo mã mới và hiệu quả cho các hàm Julia chung, đã có rất nhiều công việc để triển khai chức năng tính toán khoa học cốt lõi vào Julia thuần túy. Optim.jl để tối ưu hóa phi tuyến, NLsolve.jl để giải quyết các hệ thống phi tuyến, IterativeSolvers.jl cho người giải quyết lặp đi lặp lại của các hệ thống tuyến tính và eigensystems, BlackBoxOptim.jl để tối ưu hóa hộp đen, vv Ngay cả thư viện mạng nơron Flux.jl chỉ sử dụng CuArrays. jl tự động biên dịch mã cho GPU cho các khả năng của GPU. Khả năng kết hợp này là cốt lõi của những thứ đã tạo ra những thứ như phương trình vi phân thần kinh trong DiffEqFlux.jl. Các ngôn ngữ lập trình xác suất như Turing.jl hiện cũng khá hoàn thiện và sử dụng cùng một công cụ cơ bản.

Vì các thư viện của Julia về cơ bản dựa trên các công cụ tạo mã, nên không có gì ngạc nhiên khi có rất nhiều công cụ xung quanh việc tạo mã. Hệ thống phát sóng của Julia tạo ra các hạt nhân hợp nhất khi đang bị quá tải bởi các loại mảng để cung cấp rất nhiều tính năng được đề cập ở trên. CUDAnative.jl cho phép biên dịch mã Julia thành hạt nhân GPU. ModellingToolkit.jl tự động khử đường AST thành một hệ thống ký hiệu để chuyển đổi mã toán học. Cassette.jlcho phép bạn "thay thế" chức năng hiện có của người khác, sử dụng các quy tắc để thay đổi chức năng của họ trước thời gian biên dịch (ví dụ: thay đổi tất cả phân bổ mảng của họ sang phân bổ mảng tĩnh và chuyển hoạt động sang GPU). Đây là công cụ nâng cao hơn (tôi không hy vọng mọi người làm máy tính khoa học sẽ kiểm soát trực tiếp trình biên dịch), nhưng đây là cách mà rất nhiều công cụ thế hệ tiếp theo được xây dựng (hay đúng hơn là cách các tính năng tự viết).

Đối với song song, tôi đã đề cập đến GPU và Julia đã tích hợp tính năng đa luồng và phân tán . Đa luồng đọc của Julia sẽ sớm sử dụng kiến trúc thời gian chạy tác vụ song song (PARTR) cho phép lập lịch tự động cho đa luồng lồng nhau . Nếu bạn muốn sử dụng MPI, bạn chỉ có thể sử dụng MPI.jl . Và dĩ nhiên, cách dễ nhất để sử dụng tất cả là chỉ sử dụng một thiết lập kiểu AbstractArray để sử dụng tính song song trong các hoạt động của nó.

Julia cũng có hệ sinh thái cơ bản cơ bản mà bạn mong đợi về một ngôn ngữ có mục đích chung được sử dụng cho các ứng dụng khoa học. Nó có IDE Juno với trình gỡ lỗi tích hợp với các điểm dừng , nó có Plots.jl để tạo tất cả các loại cốt truyện. Rất nhiều công cụ cụ thể cũng rất hay, như Revise.jl tự động cập nhật các chức năng / thư viện của bạn khi lưu tệp. Bạn có DataFrames.jl , thư viện thống kê , v.v. Một trong những thư viện đẹp nhất thực sự là Distribut.jl cho phép bạn viết các thuật toán chung cho bản phân phối (ví dụ:rand(dist)có một số lượng ngẫu nhiên của bất kỳ phân phối nào được thông qua) và có toàn bộ các phân phối đơn biến và đa biến (và tất nhiên công văn xảy ra vào thời gian biên dịch, làm cho tất cả nhanh như mã hóa một chức năng cụ thể cho phân phối). Có một loạt các công cụ xử lý dữ liệu , máy chủ web , vv bạn đặt tên cho nó. Tại thời điểm này, nó đủ trưởng thành rằng nếu có một điều khoa học cơ bản và bạn mong đợi nó tồn tại, bạn chỉ cần Google với .jl hoặc Julia và nó sẽ xuất hiện.

Sau đó, có một vài điều cần ghi nhớ trên đường chân trời. GóiCompiler đang tìm cách xây dựng nhị phân từ các thư viện Julia và nó đã có một số thành công nhưng cần phát triển hơn. Makie.jl là toàn bộ thư viện cho âm mưu tăng tốc GPU với tính tương tác và nó vẫn cần thêm một số công việc nhưng nó thực sự mong muốn trở thành thư viện âm mưu chính trong Julia. Zygote.jl là một thư viện phân biệt tự động nguồn-nguồn không có vấn đề về hiệu năng của một AD dựa trên dấu vết (Flux's Tracker, PyTorch, Jax) và đang tìm cách hoạt động trên tất cả các mã Julia thuần túy. Vân vân.

Tóm lại, bạn có thể tìm thấy rất nhiều chuyển động ở rất nhiều nơi, nhưng ở hầu hết các khu vực đã có một thư viện trưởng thành vững chắc. Nó không còn ở một nơi mà bạn hỏi "nó sẽ được thông qua chứ?": Julia đã được nhận bởi đủ người (hàng triệu lượt tải xuống) mà nó có động lực để tồn tại mãi mãi. Nó có một cộng đồng thực sự tốt đẹp, vì vậy nếu bạn chỉ muốn chụp ảnh và nói về điện toán song song hoặc phương trình vi phân số, một số phòng trò chuyện tốt nhất dành cho Julialang Slack . Cho dù đó là ngôn ngữ bạn nên học là một câu hỏi cá nhân và liệu đó có phải là ngôn ngữ phù hợp cho dự án của bạn hay không là một câu hỏi kỹ thuật, và đó là những ngôn ngữ khác nhau. Nhưng nó có phải là một ngôn ngữ đã trưởng thành và có sự hỗ trợ của một nhóm lớn các nhà phát triển nhất quán không? Đó dường như là một khẳng định có.


2
Câu trả lời chính xác. Một câu hỏi: Liệu Julia có cho phép tiến hóa duyên dáng từ mã nghiên cứu thành một hệ thống sản xuất không? Hay nó giống như matlab hơn khi không có hy vọng?
user14717

6
Rất nhiều gói, chẳng hạn như differentialEquations.jl, bắt đầu làm mã cho một dự án nghiên cứu . Hệ thống đóng gói của Julia làm cho việc chuyển đổi mã làm việc thành một gói với CI và kiểm tra đơn vị để bảo trì trong tương lai khá đơn giản. Và thực tế là hầu hết các mã là thuần túy Julia làm cho việc triển khai dễ dàng hơn nhiều vì bạn không phải duy trì một loạt các hệ thống / nhị phân xây dựng. Vì vậy, tôi chắc chắn nói có. Chúng tôi có một số mã độc quyền được phát hành sớm. Một điều vẫn còn thiếu là xây dựng nhị phân (PackageCompiler).
Chris Rackauckas

29

Nếu không, có thể đưa ra ước tính thứ tự độ lớn trong bao lâu tôi nên đợi trước khi xem xét lại không?

Ước tính sơ bộ, có độ lớn của tôi về việc mất bao lâu để các ngôn ngữ khoa học tính toán trưởng thành là khoảng một thập kỷ.

Ví dụ 1: SciPy bắt đầu vào năm 2001 hoặc lâu hơn. Vào năm 2009, Scipy 0.7.0 đã được phát hành và nhà tích hợp ODE có giao diện với VODE (tương đương với ode15s, đại khái ode15slà dựa trên NDF, VODE là BDF / Adams-Bashforth, tùy thuộc). Với SciPy 0.10.0, một giao diện dopri5tương đương với MATLAB ode45, phương pháp bậc 4 Runge-Kutta thường được giới thiệu là phương pháp tích hợp số thực tế đầu tiên cho sinh viên đại học. SciPy 0.10.0 đã được phát hành vào tháng 12 năm 2011 và phải mất khoảng 10 năm để chúng bao gồm một tính năng của MATLAB được giới thiệu cho mọi sinh viên kỹ thuật mà tôi biết.

Ví dụ 2: Mathworks được thành lập vào năm 1984. Trong lần phát hành đầu tiên, họ đã sử dụng cổng LAPACK cho C có tên là JACKPAC (sau Jack Little, một kỹ sư MathWorks đã viết nó). Họ đã không thay thế nó bằng LAPACK cho đến năm 2000.

Julia có thể mất ít thời gian hơn, nhưng tôi ước tính khoảng 10 năm kể từ khi thành lập để trở thành chủ đạo. (Đã gần một năm rồi, có lẽ 9-10 năm rồi?)

Hệ thống thư viện của Julia có được phát triển đầy đủ trong các lĩnh vực này không? Cụ thể, API ít nhiều ổn định hơn cho các loại hoạt động đó hay tôi sẽ thấy rằng mã cũ của mình sẽ có xu hướng bị hỏng sau khi nâng cấp lên phiên bản mới của Julia?

Tôi không sử dụng Julia, vì vậy hãy lấy những gì tôi nói bằng một hạt muối, vì tôi chỉ thấy Jeff Bezanson thuyết trình về Julia. Họ đã cúi xuống để giúp dễ dàng liên kết và sử dụng các thư viện từ C, Python và Fortran. Nếu bạn không thể tìm thấy một thư viện Julia làm những gì bạn muốn, hãy viết một Julia shim cho một thư viện bằng một ngôn ngữ vững chắc hơn. Do đó, tôi không nghĩ rằng việc thiếu thư viện sẽ là một mối quan tâm. Tôi nghĩ rằng một mối quan tâm sẽ đảm bảo rằng những thay đổi đối với các tính năng ngôn ngữ cốt lõi sẽ không cắn vào mông bạn. Nếu bạn nhìn vào các mốc quan trọng trong repo Julia Git, bạn sẽ thấy thẻ "phá vỡ" được sử dụng khá nhiều (12 lần trong phiên bản 0,2, 5 lần trong phiên bản 0,3). Đối với tôi, điều đó cho thấy rằng ngôn ngữ cốt lõi vẫn đang phát triển, đó là lý do tại sao tôi ngần ngại sử dụng ngôn ngữ này ngay bây giờ.

EDIT: Aurelius đưa ra một điểm tốt:

Điều gì khiến bạn cho rằng Julia sẽ thực sự trở thành chủ đạo, và không chỉ chết trong mơ hồ như nhiều ngôn ngữ khác? SciPy / numpy đã có / có sự hậu thuẫn của một cộng đồng trăn đang phát triển không ngừng, mà Julia không có.

Trong câu trả lời ban đầu, tôi quyết định tránh câu hỏi "Liệu Julia có thành công trong việc trở thành chủ đạo?" Càng nhiều càng tốt. Thất bại là dễ dàng; thành công là khó khăn Tôi nghĩ rằng so sánh tốt nhất của Julia là với các ngôn ngữ điện toán kỹ thuật như MATLAB, R và Octave. Các ngôn ngữ HPC (Nhà nguyện, Pháo đài, UPC, v.v.) có đối tượng hẹp hơn ngôn ngữ máy tính kỹ thuật và ngôn ngữ mục đích chung (C, Python, C ++, v.v.) có đối tượng rộng hơn ngôn ngữ máy tính kỹ thuật.

Một cái gì đó tôi nghĩ rằng giúp Julia là thiết kế cho hiệu suất mà không mất đi tính biểu cảm. Julia cạnh tranh hơn nhiều với các ngôn ngữ được biên dịch như C so với MATLAB, R hoặc thậm chí là Python. Mục tiêu thiết kế này cũng là một tính năng có thể thu hút mọi người từ các ngôn ngữ hiện có, như:

  • Những người quan tâm rất nhiều về hiệu suất và đến từ các ngôn ngữ như C và Fortran, nhưng sẵn sàng hy sinh một nhỏ chút hiệu suất (có thể là một yếu tố của 2ish) để đi từ ngôn ngữ biên soạn để ít dòng ngôn ngữ diễn giải (cùng với một REPL cho phát triển và thử nghiệm nhanh hơn).
  • Những người quan tâm đến năng suất cao và đến từ các ngôn ngữ như Python, R và MATLAB, nhưng muốn có hiệu suất cao hơn. Khi thực hiện, Python thuần túy, MATLAB thuần túy và R thuần túy bị chậm. Các nhà phát triển trong các ngôn ngữ đó đã cố gắng bao bọc các thư viện bằng các ngôn ngữ được biên dịch, nhưng bạn không thể bao bọc mọi thứ và đến một lúc nào đó, ngôn ngữ cốt lõi sẽ làm bạn chậm lại. Core Julia nhanh hơn, cho phép bạn làm khoa học nhanh hơn.
  • Những người quan tâm đến phần mềm miễn phí. Julia được giải thích và miễn phí (Python cũng vậy, Octave, v.v.); MATLAB thì không.

Julia cũng đang cố gắng tạo điều kiện cho sự song song; Tôi không cảm thấy đủ điều kiện để mở rộng về điểm đó và tôi không nghĩ đó là ngôn ngữ chính của ngôn ngữ, nhưng tôi nghĩ đó là một điểm bán hàng mà họ đang làm việc và tôi hy vọng những người khác có thể làm sáng tỏ nó.

Tuy nhiên, ngay cả với công đức kỹ thuật về phía họ, những người sáng tạo ngôn ngữ phải làm công việc để thúc đẩy ngôn ngữ và truyền giáo. Jeff Bezanson, Alan Edelman, Stephen Karpinki và Viral Shah đang làm việc rất chăm chỉ để làm cho ngôn ngữ thành công. Alan Edelman có mối quan hệ sâu sắc với cộng đồng khoa học tính toán và trước đây ông đã từng làm việc cho các dự án cấp ngôn ngữ (đáng chú ý là phần mở rộng Star-P cho MATLAB). Jeff Bezanson đã thực hiện các mạch hội nghị để quảng bá Julia cho các nhà khoa học và kỹ sư tính toán trong một thời gian. Tại MIT, họ đã làm rất tốt việc tuyển dụng sinh viên và nhân viên (đáng chú ý là Steven G. Johnson) để đóng góp bằng cách thêm thư viện vào Julia. Họ đã có một bài viết trên Wired và quản lý để có được một bài viết Wikipedia cho chính họ, tất cả chỉ sau một năm. Repo Git của họ có hàng ngàn ngôi sao, hàng trăm dĩa, và hàng trăm đồng hồ, do đó, theo tiêu chuẩn nguồn mở, dự án của họ đã thành công. Tôi nghĩ rằng họ đã làm tất cả những điều đúng đắn cho đến nay, vì vậy đó là vấn đề duy trì nỗ lực đó và xây dựng cộng đồng. Họ vẫn có thể thất bại, nhưng đến nay điều này cho tôi thấy rằng họ có cơ hội thành công hợp lý.


Điều gì khiến bạn cho rằng Julia sẽ thực sự trở thành chủ đạo, và không chỉ chết trong mơ hồ như nhiều ngôn ngữ khác? SciPy / numpy đã có / có sự hậu thuẫn của một cộng đồng trăn đang phát triển không ngừng, mà Julia không có. Đừng hiểu sai ý tôi, tôi muốn có một công cụ tốt hơn C ++ / Python / Fortran / Matlab (và tôi không biết gì về Julia), nhưng đã có nhiều lần thử các ngôn ngữ HPC mới đã thất bại.
Aurelius

3
Về việc thay đổi vi phạm, thực tế đã có rất ít thay đổi ngôn ngữ (ví dụ cú pháp, ngữ nghĩa) kể từ trước 0.1, hơn một năm trước - thực tế, tôi không thể nghĩ về bất kỳ ngôn ngữ cốt lõi nào khá ổn định. Các vấn đề được gắn thẻ là "phá vỡ" là các thay đổi đối với API thư viện chuẩn. Đây là những cách khá dễ dàng để giải quyết bằng cách để các phương thức khấu hao xung quanh cho phép mã cũ của bạn vẫn hoạt động nhưng in cảnh báo. Các gói có nhiều thông tin hơn, vì vậy tôi nghi ngờ vào thời điểm này, điểm đau thực sự là việc nâng cấp các gói của bạn có thể phá vỡ mã của bạn ngay cả khi chính ngôn ngữ không phá vỡ mọi thứ.
StefanKarpinki

Cảm ơn đã chỉnh sửa Geoff, đầu vào tốt. Tôi hy vọng một cái gì đó tốt hơn thành công. Thật là một chút sai lầm khi nghĩ rằng trên cơ sở hàng tuần, tôi đang sử dụng Matlab để tạo nguyên mẫu nhanh chóng cho algos, python để tự động hóa / kịch bản, và C ++ và / hoặc Fortran cho công việc "nghiêm túc", nhưng đó là thế giới chúng ta đang sống. Tôi m buồn bã bi quan mặc dù. Xu hướng 5-10 năm trong HPC là lập trình không đồng nhất và song song lớn, và điều đó vốn đã khó tạo ra một ngôn ngữ đơn giản. Trận chiến khó khăn của họ là một độ dốc rất lớn vì rất nhiều lý do.
Aurelius

Phân tích tuyệt vời. Tôi thực sự muốn nói rằng mọi thứ bạn làm cho HPC luôn bị phá vỡ. Đó là một không gian đổi mới, trong đó việc thực hiện / phá vỡ là ngang bằng với khóa học. Julia có rất nhiều điều tốt cho nó, nhưng tôi nghĩ rằng rất nhiều mánh khóe đến từ sự tích hợp LLVM, một lần nữa là một mục tiêu rất cảm động. Tôi sẽ học được một chút về nó, nhưng cho nó một vài năm cho đến khi bạn mong đợi sử dụng nó hàng ngày.
meawoppl

21

Tôi tin rằng Julia đáng để học hỏi. Tôi đã sử dụng nó để sản xuất một vài mã phần tử hữu hạn nghiên cứu và sản xuất chúng rất nhanh. Tôi đã rất hài lòng với kinh nghiệm của mình.

Julia đã kích hoạt một quy trình làm việc cho tôi mà tôi thấy khó đạt được với các ngôn ngữ khác. Bạn có thể sử dụng nó như một ngôn ngữ tạo mẫu như MATLAB, nhưng không giống như MATLAB khi bạn có mã làm việc và đang trải qua các lần lặp lại để tăng tốc độ, thay thế các điểm nóng bằng mã C là không gây đau đớn. Họ đã ưu tiên giao tiếp với C (và Python) trong thiết kế.

Do đó, ngôn ngữ đã cho phép tôi chuyển rất nhanh từ các công thức toán học sang mã chức năng và sau đó từ mã chức năng sang mã hiệu suất cao. Tôi nghĩ rằng tính năng này của Julia không được tiết lộ, nhưng nó làm tăng giá trị to lớn.

Trong nhiều trường hợp, tôi đã đạt được hiệu suất C (so với mã C của riêng tôi) trong vài giờ sau khi tạo mã phần tử hữu hạn chức năng. Cho đến nay, nếu tôi chỉ sử dụng các tính năng của Julia, tôi thường nhận được trong khoảng ~ 3 lần chậm hơn C. Sau đó, tôi thay thế các điểm nóng bằng các hàm C (Julia đi kèm với một trình lược tả lấy mẫu ngăn xếp để giúp xác định các tính năng này). Thông thường, điều này chỉ yêu cầu thay thế các dòng mã điểm nóng vi phạm bằng "ccall", với Julia xử lý bất kỳ sự sắp xếp nào.

Tôi nghĩ rằng điều chính mà Julia đang thiếu ngay bây giờ mặc dù điều đó khiến tôi ngần ngại khi xem xét nó cho các dự án lớn hơn là thiếu trình gỡ lỗi được hỗ trợ đầy đủ và hỗ trợ kém cho âm mưu (ngay bây giờ đặt cược tốt nhất của bạn vào âm mưu thực sự chỉ là giao diện vào matplotlib rằng tôi đã nghỉ ngơi thường xuyên hơn không). Phản hồi ngay lập tức về mã là thực sự quan trọng. Tôi cũng không biết làm thế nào để tồn tại mà không cần gỡ lỗi tương tác, và về mặt này, tôi rất được MATLAB và GDB chiều chuộng.


Cảm ơn, đây là một câu trả lời rất hữu ích. Tôi có một số câu hỏi tiếp theo. Đầu tiên, bạn có sử dụng phiên bản phát hành hoặc theo kịp nguồn không? Nếu sau này, bạn có gặp phải nhiều vấn đề với việc phá mã do cập nhật không? Thứ hai, làm thế nào để giao diện để matplotlib "phá vỡ" chính xác? Tôi thực sự khá phấn khích khi biết rằng âm mưu là thông qua matplotlib, bởi vì nó có thể hiển thị LaTeX trong nhãn trục (LaTeX thực tế, sử dụng cài đặt TeX) và đối với tôi đó là một tính năng giết người. Nhưng nếu giao diện không ổn định thì điều đó không tuyệt lắm ...
Nathaniel

Tôi luôn cập nhật với nguồn vì tôi cũng đang cố gắng đóng góp cho dự án. Cho đến nay tôi đã không có bất kỳ nghỉ giải lao nào, nhưng tôi chỉ có một khoảng thời gian lớn về văn bản và lý thuyết và bây giờ tôi sẽ quay trở lại mã của mình và chúng ta sẽ thấy điều đó diễn ra như thế nào. Theo mặc định, mảng Numpy được lập chỉ mục 0 và hàng chính. và Julia theo mặc định là 1 chỉ mục và cột chính, thường thì điều này không gây ra vấn đề gì nhưng việc vẽ sơ đồ dữ liệu không có cấu trúc đòi hỏi các mảng chỉ mục phải được truyền qua nên tôi đã phải làm những điều kỳ lạ như truyền p'-1 cho lưới tam giác không cấu trúc các thói quen, trong đó p là một bản đồ chỉ số.
Reid.Atcheson

9

Theo kinh nghiệm của tôi, Julia chưa sẵn sàng để sử dụng hàng ngày (khoa học) (Tôi đang nói về phiên bản ổn định 0.4 của tháng 3 năm 2016). Ngôn ngữ chính nó là tốt đẹp, tính năng phong phú và nhất quán; một bước tiến mới từ cả MATLAB và python. Chắc chắn có những trường hợp sử dụng mà Julia là một lựa chọn tốt ngay cả ở giai đoạn đầu này. Nhưng nếu bạn cần các thư viện khoa học đáng tin cậy và trưởng thành, tôi không thể khuyên bạn nên thực hiện ngay bây giờ. Các vấn đề chính tôi gặp phải là:

  • Các gói bên ngoài cốt lõi của Julia không đáng tin cậy. Họ phá vỡ với các bản cập nhật, thay đổi, được thay thế, đôi khi không đầy đủ hoặc đơn giản là bị hỏng.
  • Các tính năng song song của Julia (imo các tính năng sát thủ matlab tiềm năng hứa hẹn nhất) là chưa trưởng thành. Bạn sẽ gặp phải lỗi phân đoạn, rò rỉ bộ nhớ, sự cố và hiệu suất đáng thất vọng. Đôi khi, họ không chơi tốt với các phần khác của julia, ví dụ như một số bộ giải cho các hệ thống hoặc gói tuyến tính bên ngoài lõi. Mặc dù các tính năng này nghe có vẻ hứa hẹn, nhưng chúng thường đủ thất bại đối với tôi. Hầu như không bao giờ là đủ để chỉ đơn giản là viết @paralleltrước vòng lặp for, theo lý thuyết thì nó nên.
  • Nhiều vấn đề nhỏ, lỗi nhỏ và các vấn đề người ta có thể gặp phải: dấu vết ngăn xếp cuộc gọi không hay và đôi khi có lỗi, lịch sử trình thông dịch lỗi nhỏ, tải gói chậm, hiệu năng kém của gói này hoặc gói khác, v.v. hầu hết là gói PyPlot, một trình bao bọc cho matplotlib, hiện không có sự thay thế nào cho nó. Nó thực sự tuyệt vời khi nó ở đó và nó chủ yếu hoạt động. Nhưng nếu bạn cần vẽ dữ liệu, hãy chuẩn bị cho các vấn đề và hiệu năng rất chậm.

Tất cả điều này sẽ trở nên tốt hơn. Tôi tự tin rằng một ngày nào đó julia sẽ vượt trội hơn matlab và python ở hầu hết mọi khía cạnh. Rất có thể là các gói sáng tạo sẽ được phát triển cho nó. Có vẻ như đã có một cộng đồng lớn. Ngay cả bây giờ có rất nhiều gói với các trường hợp sử dụng từ opencl đến máy chủ web. Sử dụng thư viện python hoặc c rất dễ dàng, vì vậy bạn có thể sẽ không gặp phải khó khăn về tính khả dụng của thư viện. Một điểm mạnh lớn của Julia sẽ là sự nỗ lực mà người ta có thể kết hợp chức năng hiệu suất cao từ nhiều nguồn khác nhau trong một ngôn ngữ cấp cao hiện đại và nhất quán (xem câu trả lời ở trên). Nhưng nói chung, tôi thấy nó không đủ chín chắn và không đủ ổn định để được sử dụng một cách hiệu quả.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.