Thời gian đọc: & NBSP; 10 phút
Trong phòng thí nghiệm của chúng tôi, một cuộc tranh luận phân cực từ khoảng năm 2010, được tóm tắt bởi điều này & nbsp; câu hỏi:
Tại sao ngày càng có nhiều tính toán khoa học quan trọng theo thời gian trước đây được thực hiện ở Fortran hiện được viết bằng Python, một ngôn ngữ chậm hơn & nbsp;
Các thuật ngữ mơ hồ, khuyến khích các cuộc chiến bộ lạc giữa người dùng dựa trên thói quen của họ hơn là dựa trên các đánh giá khách quan về hai cách tiếp cận. Hãy để cố gắng đưa ra một số yếu tố để đạt được sự hiểu biết lẫn nhau, bằng cách thu hẹp câu hỏi & nbsp;
“Python, một ngôn ngữ chậm hơn”Python, a slower language”Python có tiếng là chậm, tức là chậm hơn đáng kể so với các ngôn ngữ được biên dịch như Fortran, C hoặc Rust. Nếu bạn đã nghe điều này, bạn không đơn độc: chỉ đơn giản là googling tại sao Python chậm lại mang lại hàng đống trang về chủ đề này. Điều này bắt nguồn từ một khía cạnh cơ bản của Python: nó là một ngôn ngữ được giải thích. Điều này ngụ ý một chi phí quan trọng cho mỗi hướng dẫn, do đó làm chậm các tính toán lớn. Điều này sẽ đúng với bất kỳ ngôn ngữ được giải thích nào, bao gồm ví dụ: Perl hoặc & nbsp; Ruby.
Vì vậy, có, Python đơn giản chậm hơn nhiều so với & nbsp; Fortran.
Tuy nhiên, sự so sánh này không có ý nghĩa gì, vì việc sử dụng khoa học của Python không dựa vào Python đơn giản. Thay vào đó, Python được sử dụng như một lớp dán, dựa vào các gói được tối ưu hóa được biên dịch mà nó nối với nhau để thực hiện tính toán mục tiêu. Gói phổ biến nhất trong điện toán khoa học có lẽ là vô cùng, đối với python số. Như tên cho thấy, dữ liệu số được thao tác thông qua gói này, không phải trong python đơn giản, và đằng sau hậu trường, tất cả các công việc nặng được thực hiện bởi các thói quen biên dịch C/C ++ hoặc Fortran. Về bản chất, Python được sử dụng để chỉ ra một thói quen nhanh theo đúng hướng [nghĩa là đến đúng địa chỉ bộ nhớ] và không & nbsp; nhiều hơn nữa.Numerical Python. As the name suggests, numeric data is manipulated through this package, not in plain Python, and behind the scenes all the heavy lifting is done by C/C++ or Fortran compiled routines. In essence, Python is used to point a fast routine in the right direction [i.e. to the right memory address], and no more.
Do đó, đánh giá hiệu suất cho điện toán khoa học nên dựa trên loại phương pháp này. Biểu đồ sau đây là một ví dụ về so sánh, cho thấy mức độ nhanh của 2 bậc nhanh hơn so với Python thuần túy. Như bạn có thể thấy, các gói khác cũng tồn tại, có thể giảm thêm chi phí nếu & nbsp; cần.
Điều này làm giảm chi phí của phương pháp giải thích từ 2 đến 3 bậc độ lớn, đưa nó vào sân bóng của các giải pháp được biên dịch. Tất nhiên, một số so sánh chính xác hơn tồn tại, hãy kiểm tra chúng cho & nbsp; nhiều hơn nữa.
Được sử dụng đúng cách, Python chậm hơn một chút so với biên dịch & nbsp; mã.
"nhiều hơn và nhiều hơn nữa"more and more”Có thể định lượng phổ biến? Một chỉ số là Google Trends. Đối với người Fort Fortran và người Numpy. Fortran thực sự đang dần giảm dần, và đã tụt hậu so với Numpy kể từ năm 2015. Tuy nhiên, hãy lấy một hạt muối này, vì sự quan tâm được ghi lại nhiều hơn về Numpy bị sai lệch bởi sự phụ thuộc nặng nề của các lập trình viên trẻ và các nhà phát triển Python nói chung trên Web & NBSP;recorded interest in NumPy is biased by the heavy reliance of young programmers and Python developers in general on web resources.
Ok, bất cứ điều gì, những đứa trẻ mới thích Python hơn Fortran. Điều này cũng được điều khiển bởi nhiều ứng dụng phi khoa học, đáng chú ý là dựa trên web. Trong lĩnh vực của chúng tôi, đây không phải là những gì hướng dẫn các quyết định của chúng tôi. Tuy nhiên, những gì là mối quan hệ với HPC.HPC.
“Các tính toán khoa học quan trọng về thời gian”time-critical scientific computations”Sự cạnh tranh giữa các phương pháp tiếp cận phần mềm với điện toán hiệu suất cao chưa bao giờ khốc liệt như ngày nay. Một thách thức cụ thể phát sinh từ môi trường của HPC, rất cụ thể và không phải là những gì phần mềm chung tiến bộ tối ưu hóa. Ví dụ, công nghệ container [nghĩ rằng Docker] đã trở nên phổ biến trong nhiều thiết lập lập trình, nhưng vẫn không đủ trong bối cảnh HPC. Điều này cũng đúng với các ngôn ngữ, chẳng hạn như Rust có lượng người theo dõi lớn trong cộng đồng C / C ++ nhưng tiếp tục có một hệ sinh thái thư viện không đủ cho HPC.HPC, which is very specific and not what general software advances optimize for. As an example, container technology [think Docker] has become ubiquitous in many programming setups, but is still largely inadequate in an HPC context. This is also true for languages, such as Rust which has a large following in the C / C++ community but continues to have an insufficient library ecosystem for HPC.
Phần mềm HPC ngày nay phụ thuộc vào một loạt các phương pháp tiếp cận, bao gồm các mã biên dịch nguyên khối truyền thống [chủ yếu là ở Fortran và C ++], các phương pháp tạo mã [a.k.a. DSLS] và các phương pháp được giải thích / biên dịch. Thể loại thứ hai hiện có một số người thách thức nghiêm trọng, chẳng hạn như PYFR hoặc FENICS, đã được chứng minh là mở rộng lên hàng trăm đến hàng chục ngàn CPU và thậm chí & NBSP; GPU. software today relies on a vast range of approaches, including traditional monolithic compiled codes [mostly in Fortran and C++], code generation approaches [a.k.a. DSLs], and hybrid interpreted / compiled approaches. The latter category now counts some serious challengers, such as PyFR or FEniCS, which have been shown to scale to several hundred to tens of thousands of CPUs and even GPUs.
Tuy nhiên, với các tác giả, kiến thức không có người thách thức nào, bao gồm các nỗ lực của Python/HPC, đã xây dựng một cộng đồng đủ và sự trưởng thành để có được lợi thế trong bối cảnh HPC toàn cầu. Vì vậy, hiện tại, có lẽ sẽ an toàn hơn khi đặt cược vào & nbsp; cả hai:HPC attempts, has built a sufficient community and maturity to get an edge in the global HPC scene. So for the moment, it is probably safer to bet on both:
- Giữ mã hàng đầu Fortran/C ++/C của chúng tôi nổi. Cũ hơn, nhưng & nbsp; khôn ngoan hơn.
- Thử một số phương pháp mới này [ví dụ: dựa trên Python] trên các ứng dụng thực tế & nbsp;
Is Python ever better suited?
Up until this point, one could rightfully think:
Fortran is very fast and well suited to HPC platforms. Python is slightly slower, requires to learn about several layered packages, and is not always suited in a scientific-computing context. Why on earth would anyone switch to Python?
A good point! And yet, in some situations, Pythonistas will argue that “speed” shouldn’t necessarily be measured by implementing the same algorithm between languages. To grasp why, let’s dive into an example.
At Cerfacs, a tool nicknamed Projector was written around 2010 by a Fortran-only programmer. Let’s call him Bob.
Several years later, circa 2016, Bob rewrote the same tool in Python. The motivation was simply that for several years, his younger co-workers got many things done in python. Meanwhile, their output in Fortran and Tcl/Tk was constantly disappointing to him. In particular, the Projector in Fortran was barely understood and never fully maintained by anyone else but Bob.
Bob saw Python as a hassle, an indentation-greedy language supported by many impolite youngsters too happy to bully others by saying “this is not pythonic” with the penetrating stare of those who saw the light. In short, he was pissed…
Bob strained to shove these 1.5K lines of fortran code, painfully validated over the years, into NumPy [and a bit of SciPy]. The projector tool performs the projection of the thousands of multi-perforations of a combustor liner on the skin of a 3D complex shape made of millions of polygons. As you can imagine, this is quite a compute-heavy task.
Bob soon discovered that once he had fit the data structures into NumPy, many pre-existing and optimized functions were available to make his task easier in packages such as SciPy. Searching through the documentation, he found some useful tools for 3D points manipulation, including a smart data representation called a Kdtree. The implementation was easy enough to test a dozen projections workflows in the afternoon, ending with a simple back-and-forth projection with two SciPy Kdtree objects, one for the mesh skin and one for the drills.
This discovery might not have left Bob’s computer however, if it hadn’t been distributable to the end users. Here, these are engineers working on HPC clusters, where containers are still rare, system installs through the IT is a slow and careful process, and there is no internet access. So even though Python definitely has it’s flaws in its distribution pipeline, Bob was quite happy to see that distributing interpreted code [basic compiled libraries like NumPy are a given on these clusters, thankfully] was very easy, an led to quickly replacing the code in production.
Then came the time to compare the brute-force [Fortran] and KDtree-based [Python / NumPy / SciPy] versions. Bob chose a large representative test case:
- 1 billion cells
- 10 million multi-perforated boundary nodes
- 18 thousand perforations
The brute-force version ran in 6 hours and 30 minutes. And the Kdtree-based one? 4 minutes only, almost a 100 times faster, with discrepancies in the result only at the level of machine precision.
Speed vs agility
What really happened here? Well, Projector‘s main operation involves searching for points in a 3D pointcloud. The Fortran version did this by looking in the pointcloud array, a search which has a \[O[n]\] complexity. A KDTree is a data structure designed for this type of search, with a complexity of \[O[log[n]]\]. And when your \[n\] is 1 billion, algorithms matter more than language performance.
So yes, Fortran would have been faster for the same implementation. Programmers with enough basic skills in computer-science might be appalled here: isn’t the problem simply that Bob should know his basic data structures? Sure, but Bob, like many people that rely on scientific computing, is not a computer-science expert. He holds a PhD in numerical simulation of compressible turbulent reactive flows, and that’s already a lot of knowledge to fit into software. He, like many others, hasn’t spent a couple of years learning about computer-science itself. And he would never have tried this algorithm had he stuck to Fortran [He should have, like I. Pribec Suggested, but he did not, and that is the point]. The friction related to exploring new algorithms and data structures in Fortran’s ecosystem was just too high.
By definition, a higher level language will allow more explorations. In Bob’s case, the initial fortran version was working like a charm. There was no strong incentive to break the implementation, insert a localization tree -octree or kdtree-, and look how far Bob could reduce the stencil of points without degrading the output. In other words, the Return On Investment was far too uncertain. Moving to python simply reduced the Investment part. Of course, If the best algorithm is known beforehand or the manpower is not a problem, a lower level-language is probably faster, but this is seldom the case in real life.
Một trích dẫn từ một kỹ sư phần mềm có ảnh hưởng cho thấy vấn đề này có mặt trong nhiều cuộc tranh luận ở cấp độ cao so với mức thấp & NBSP;
Các lập trình viên làm việc với các ngôn ngữ cấp cao đạt được năng suất và chất lượng tốt hơn so với những người làm việc với các ngôn ngữ cấp thấp hơn. Các ngôn ngữ như C ++, Java, Smalltalk và Visual Basic đã được ghi nhận là cải thiện năng suất, độ tin cậy, đơn giản và tính hiểu biết của các yếu tố từ 5 đến 15 so với các ngôn ngữ cấp thấp như hội và C [Brooks 1987, Jones 1998, Boehm 2000 ]. Bạn tiết kiệm thời gian khi bạn không cần phải có một lễ trao giải mỗi khi tuyên bố C thực hiện những gì mà nó phải làm. - Steve McConnell, Code & NBSP; Hoàn thành.
Lấy đi
Rất nhiều điều đã được nói về tốc độ thực hiện so với tổng thời gian của lập trình viên cần thiết để thực hiện một nhiệm vụ trong thế giới khoa học máy tính. Trong điện toán khoa học, có một xu hướng mạnh mẽ để đánh giá quá cao tầm quan trọng của thời gian thực hiện, do đó tập trung sự chú ý vào tốc độ.
Tuy nhiên, như bạn sẽ học trong bất kỳ lớp thuật toán nào và như đã được chứng minh trong nghiên cứu người dùng ở trên, tốc độ không có gì nếu bạn không sử dụng thuật toán đầy đủ. Và để đảm bảo bạn là, đôi khi buông bỏ một chút tốc độ để đạt được sự nhanh nhẹn sẽ đi một cách dài & nbsp;
Vì vậy, lần tới khi bạn có một công cụ để viết cho máy tính khoa học, hãy tự hỏi: Tôi có cảm thấy tự tin rằng tôi có khả năng chọn và thực hiện một thuật toán hiệu quả cho nó không? Nếu bạn là, một ngôn ngữ được biên dịch sẽ cung cấp cho bạn hiệu suất tốt nhất. Nếu không, đầu tư một chút thời gian để học một ngôn ngữ nhanh để khám phá các thuật toán có thể là cách tốt nhất để công cụ của bạn trở nên rực rỡ & nbsp; nhanh chóng.
Tuyên bố miễn trừ trách nhiệm: Văn bản này có lẽ khá không công bằng với Fortran hiện đại, tất cả các lời xin lỗi. Nó thực sự tập trung vào việc sử dụng Fortran nội bộ của chúng tôi, được cân nhắc bởi các mã di sản kéo dài hàng thập kỷ, theo nghĩa đen . Độc giả, giữ liên lạc với những câu hỏi mới nhất xung quanh Fortran hiện đại bằng cách sử dụng Fortran & nbsp; diễn ngôn : This text was probably quite unfair to modern Fortran, all apologies. It focused indeed on “our” internal use of Fortran, weighted by decades-long Legacy codes, literally millions of not-very-modern Fortran statements, and the frustrating rules of HPC clusters where you are not sys-admin, and without internet access. Readers, keep in touch with the latest questions around modern Fortran using the Fortran Discourse
Bài đăng này là tác nhân của một cuộc thảo luận dài của cộng đồng Fortran. Người đọc rất được khuyến khích duyệt các cuộc thảo luận chuyên dụng.
Antoine Dauptain là một nhà khoa học nghiên cứu tập trung vào các chủ đề khoa học và kỹ thuật máy tính cho HPC. is a research scientist focused on computer science and engineering topics for HPC.
Corentin Lapeyre là một nhà khoa học nghiên cứu tập trung vào AI cho mô hình vật lý. is a research scientist focused on AI for physical modeling.