1. 14
  1. 5

    The whole premise of this effort is not credible. There are far more reasonable approaches than rewriting everything in Rust™, for instance, in this case, just providing modern Fortran wrappers around the (assumed) FORTRAN 77 source. Then, implementing ISO C binding interfaces to these function in order to call the Fortran code from C, Python, Lua, … But then, it would’t have been Rust, right?

    1. 3

      Frankly I think the analysis of whether the rewrite is justified is pretty impressive for an undergrad. It seems perfectly reasonable for a couple-semester research project or something of that scope, and sounds like they learned a lot of useful optimization info about the problem space of the program totally unrelated to the implementation language. How would providing language wrappers around the existing code have helped with threading, anyway?

      1. 2

        The wrappers may not be useful for threading, but instead, for providing a user interface, as the author didnʼt want to call ncurses from Fortran. Due to the original version beeing written in Fortran 90, parallelisation could have been added easily with Fortran 2003 intrinsic concurrency, OpenMP, or CoArrays.

      2. 2

        I noticed that you had some extra spaces in your comment. I can’t read it. Have you considered rewriting your comment in Rust? It would detect that sort of problem for you at posting time.

        1. 1

          Now you can simply provide a c-binding too.. And their job was to rewrite it, so I wouldn’t even bother explaining why you do it.

          1. 1

            Then, Fortran 2018 would have been a more logical choice for a port/rewrite. I mean, the field is still numerical simulations.

            1. 1

              I wouldn’t have rewritten it in Rust either; the author started with a Fortran 90 program. It has global variables but otherwise doesn’t seem that hard to work with.

              1. 2

                Depends, for example if you want to have rusts memory constraints or want new students to add features, you may want to move away from fortran. Even more in research, if I want to give less experienced people the job to add things.

        2. 3

          The conclusion mentions being happy with the performance improvements but the chart suggests they’re more or less the same. Did I miss something?

          1. 2

            Kinda faster for smaller inputs and overall same speed. When rewriting simulation code that was used for ages in fortran, a language we still rely on for pythons math libs, because it’s “unmatched” (and kinda is), I call that a win.

            1. 2

              Similar question was asked on reddit thread

              Well currently the researchers are using the Fortran version, but plan to use the Rust version for the range of inputs that are faster.

              I mean happy is probably putting it strongly, obviously I’d have liked to have achieved more, but any simulations that need to be run at that size can now be done significantly faster.

              1. 1

                I thought it looked like a “rounding error”.