4 ms·

> big iron imperative language offers over the dozens of other superficially similar choices Given the capabilities of modern machines and the fact that non-ho

• reikonomusha 3y ago
  (I should preface this by saying that my claims are all based on what I see in a specific scientific community and US laboratory environment. I can't say for sure my observations are true more generally.) I think what you say is true in principle, basically on all counts, but Fortran's niche that its advantages serve best has been continually eaten away at by the Python/C++ combination. The "I don't know pointers" crowd steers toward Python, and the "I care about CPU cycles" crowd steers toward C++, and that relationship is symbiotic. Julia promised to be a general-purpose language, both as fast (or faster) than Fortran/C++ and as easy (or easier) than Fortran/Python. But it doesn't seem to have panned out as they'd perhaps have hoped.
  • pjmlp 3y ago
    Looking at Julia Computing industry partners, it isn't that bad.
  • sundarurfriend 3y ago
    Fortran still has a big fanbase and people actively fighting to keep it alive and thriving as much as possible. Maybe the crown will remain with C++ (in terms of fast languages), and maybe Rust will eat some of its lunch, but there seems to be a resurgence in the Fortran community to make sure it remains an important language in this space. Julia has something similar but to a lesser degree. Its main problem has been the developer experience - the latencies (slowly getting better), lack of a great editor/LSP experience (the VS Code plugin is decent, but not yet great), lack of accessible how-to resources (people are starting to write more of these), and things like that.
  • jki275 3y ago
    I don't think Julia has been around quite long enough to make that statement yet. I've just noticed it's now available on the system I work with, which puts it in the frame for a possible (probably far out still)future move for a massive C/Fortran codebase I maintain. My general default if I'm going to update something is C++, but from what I see of Julia it's at least worth a look.
  • goerz 3y ago
    How has it “not panned out”? Julia has been in a useable state only for a few years, and is still rapidly developing. Prior to Julia 1.0, I would have said Fortran (which I have 15 years experience with) was the most productive language for scientific computing. Today, Julia is, by a wide margin. In fact, our benchmarks show Julia matching or beating Fortran’s performance, to say nothing of the mich increased flexibility.
• rlkf 3y ago
  In my experience "very difficult mathematical code" stems from employing little or no abstraction of the problem domain, mashing together numerical algorithms with physics formula. Using Fortran is IMO as much a prerequisite as a result of this.
• ribit 3y ago
  I fully agree with you that scripting languages are a great fit for scientific computing. But I just don't see how this is a case for Fortran. R or Python are still much easier to use and give you the same access to high-performance numerical accelerators via BLAS/LAPACK backends. And if you need a low-level language (e.g when developing an optimised routine that solves a specific problem), I would use a high-performance widely supported systems programming language like C++ or Rust. Fortran seems to be around mostly for legacy reasons. And I am not sure that legacy considerations alone make a good foundation.
  • galangalalgol 3y ago
    BLAS/LAPACK are written in fortran was the point I think. There are eigen and nalgebra certainly, but neither exports as cleanly to python, and neither is significantly (if at all) faster. CuBLAS on the other hand makes a lot of sense to use from python if you have the right hardware.
    • xmcqdpt2 3y ago
      The reference implementation of BLAS that you should absolutely not use is written in Fortran. The actual implementations are written in C/C++/ASM. That's not to say you should use C yourself, memory management is a lot nicer in Fortran, for multidimensional arrays. You can stack allocate arrays inside functions and modern fortran has move semantics. Arrays are contiguous even if they have multiple index. It's generally a nice language for math, has good C API integration (both as caller and callee) and compiles down to small libraries without runtimes.
      • galangalalgol 3y ago
        Thanks! I did not most any of that. Except for that it is good at math.
  • enriquto 3y ago
    Loops in Python are excruciatingly slow, for no reason. Some algorithms are naturally written using loops, and Python makes this very uncomfortable, forcing you to rewrite your algorithm in a non-natural way. I hate writing numerical code in Python due to that; it just feels uncomfortable. For scientific computation I just need multi-dimensional arrays of floats and fast loops. Fortran has both of these things natively. Python has neither.
• BobbyJo 3y ago
  > the "winning" strategy is to have high-level scripting languages where you can ignore most of the details From personal experience, I don't believe this works in practice. Invariably, some level of logic is implemented in said scripting language, and it becomes a huge bottleneck. Counterintuitively, when you have a central thread dolling out work to many subroutines, the performance of that thread becomes more critical as opposed to less.
  • hutzlibu 3y ago
    "Invariably, some level of logic is implemented in said scripting language, and it becomes a huge bottleneck. " Not necessarily and if it does, then the solution is to add that logic into the low level libary. So yes, you need at least one guy who can do this.
    • mangodrunk 3y ago
      At that point, you’re not really using the high level language.
      • BobbyJo 3y ago
        If you aren't using the scripting language enough for it to get in the way, you're probably not using it enough for it to make things easier either. Just to be clear, I'm not saying it's impossible to strike the balance where it makes sense. I'm just saying I've yet to see it work, and I would, therefore, not assume such a balance is given by default, or even easy to achieve.
        • mangodrunk 3y ago
          I agree with you. There’s also the additional cost of maintaining more than one language which makes the balance that much harder to do. I could see utility in the high level language to do something with the result if it’s not computationally intensive.
      • hedora 3y ago
• Majromax 3y ago
  > the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably. That gets you about 70% of the way there, but the remaining 30% is tricky. Unfortunately, the library-call stage doesn't easily (with generality) let you fuse operations. For example, consider the example of a finite-volume code, where the flux is some nonlinear function of the interface value, taken to be the average of left and right cells: flux = nonlinear_flux_op(f[:-1] + f[1:]) # Compute interface fluxes f[1:-1] += dt/dx*(flux[:-1] - flux[1:]) # Update cell volumes based on flux differences # Do something special for the boundaries Each of the substeps here is fast. Sub-indexing these 1D arrays is trivial, and their local operations are highly vectorized. The nonlinear flux operator operates element-wise, so it's easy to compile it into a version that properly (CPU) vectorizes (and/or it might already be provided, like np.exp or *2). This code is also very readable. However, real performance would require fusing operations. There's no need to compute a full temporary array for the interface values, but that's exactly what would happen in naive NumPy code. Likewise, there's no need to compute all of the fluxes before taking their differences. A hand-optimized code would perform the full computation in a single scan of the array, keeping all of the data in CPU cache (blocking by a cache line or so in order to use vector registers effectively). Even if given the code naively written, an optimizing compiler would try loop fusion and get most of the way to the hand-optimized result. Code such as this is relatively FLOPS-light compared to the amount of memory accessed, so effective use of cache can lead to an order of magnitude speed-up. With a fair amount of work you can still achieve this result in Python, but to do so you need to use one of the optimizing Python compilation tools like numba. Unfortunately, this is not easy for the not-a-programmer domain scientist, since working with numba means understanding the intersection of Python and numba's imposed compilation rules.
  • thanatropism 3y ago
    [flagged]
  • blt 3y ago
    Numba is quite restrictive... to someone comfortable in C++, coercing my code into a form Numba likes sometimes feels no easier than writing an extension using Eigen types and pybind11.
• weinzierl 3y ago
  > "the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably" That's nice as long as it works, but in my experience gets ugly when it doesn't. While we can currently witness this being a successful model, the impedance mismatch between both worlds is often a pain. I bet on a language like Rust as the winning strategy in the long run - high level like Python but still close to the metal and all in one language, one compiler, one ecosystem.
  • hedora 3y ago
    Rust shares a lot of performance advantages around pointer aliasing with fortran. In fortran, pointers can't alias by default, and in rust, the borrow checker should be able to infer that a shared and exclusive reference don't alias, allowing the compiler to assume that it's not writing to input values of a loop, etc. In C, pointers can alias by default. The last time I checked, that made these sorts of optimizations harder. However, I'm not sure how measurable the performance impact is these days.
    • pklausler 3y ago
      Fortran pointers must be assumed to alias. It's Fortran's dummy arguments that must not alias.
• osigurdson 3y ago
  That kind of sounds like Mojo.
• hpcjoe 3y ago
  > the "winning" strategy is to have high-level scripting languages where you can ignore most of the details, which call into hyper-optimized, high performance libraries. For instance, when you're using Scipy, you call into Fortran and C almost interchangeably. Well, no. This is python's strategy. Doesn't make it the winning strategy. Python implicitly forces multiple languages upon you. A scripting one, and a performance one. Meanwhile languages such as Julia, Rust, etc. allow you to do the work in a single (fast/compiled) language. Much lower cognitive load, especially if you have multiple cores/machines to run on. Another point I've been making for 30+ years in HPC, is that data motion is hard. Not simply between machines, but between process spaces. Take large slightly complex data structures in a fast compiled language, and move them back and forth to a scripting front end. This is hard as each language has their own specific memory layout for the structures, and impedance matching between them means you have to make trade-offs. These trade-offs often result in surprising issues as you scale up data structure size. Which is one of the reasons that only the simplest of structures (vectors/arrays) are implemented in a cross language scenario. Moreover, these cross language boundaries implicitly prevent deeper optimization. Which leads to development of rather different scenarios for code development, including orthogonal not-quite-python based things (Triton, numba, etc.). Fortran is a great language, and as one of the comments pointed out, its really not that hard to learn/use. The rumors of its demise are greatly exaggerated. And I note with some amusement, that they've been going on since I've been in graduate school some 30-35 years ago. Yet people keep using it.