4 ms·

> I tried to talk the Go and Rust people into putting in multidimensional arrays, but the discussion degenerated into bikeshedding, with arguments for fancy but

> I tried to talk the Go and Rust people into putting in multidimensional arrays, but the discussion degenerated into bikeshedding, with arguments for fancy but slower representations so you could take arbitrary N-dimensional slices from a multidimensional array. This is the most frustrating aspect of Rust, to me, as a developer of scientific software. Rust has great potential to challenge Fortran in this domain, but numerics is mostly an afterthought in Rust.

throwaway7645 10y ago
Agreed. I want to write numeric software, but don't want to use Fortran or C++. Rust looked great, but I couldn't find anything in this domain.
- goatlover 10y ago
  Julia has strong numerical and multi-dimensional array support, but it's JIT compiled. However, once a function is JITted, it has comparable performance to Go & Rust.
  - divbit 10y ago
    Seconded for Julia. I have been using it for math prototyping and it's recently replaced my old favorites like matlab / python / lua.
  - dnautics 10y ago
    I believe the multidimensional arrays are backended by Fortran
    - 3JPLW 10y ago
      Not really. They're just written in a way such that the memory layout is compatible with BLAS libraries — which are frequently written in Fortran. So they can be passed directly to functions that happen to have been written in Fortran.
      - photon-torpedo 10y ago
        Additionally, invoking BLAS/LAPACK only happens for dense arrays of specific types (single/double precision real/complex numbers). The great thing in Julia is that almost all of the array and linear algebra functionality is implemented completely generically, so that algorithms can be written using these higher-level concepts, and the low-level functionality will (very efficiently) dispatch to BLAS/LAPACK if possible; if not, the generic implementations still allow your algorithm to work for e.g. your user-defined number type.
      - dnautics 10y ago
        haha yeah I guess i should have been more precise with my wording. I'm currently prototyping a custom number system in julia, and obviously, the multidimensional array ops will not be backended in BLAS.
  - luthaf 10y ago
    Yep, Julia is a very nice language with very good performances. But I abandoned it because it is not (yet?) oriented toward library development, and more usable in exploratory style. I ran into issues a year ago when trying to organize a library with more than 8000 loc, when the "dump everything into a global namespace" started to be more a hassle and less a nice way to get stuff done. I am waiting for it to stabilize a bit before giving a second try.
    - photon-torpedo 10y ago
      Could you elaborate on why you felt the need to "dump everything into the global namespace"? For quite a long time now, you can use modules in Julia to keep things in separate namespaces. With "import MyModule" (instead of "using MyModule") things will not enter the global namespace, but will need to be qualified, like "MyModule.myfunction(...)". I feel this is very much like Python. You could even introduce abbreviations for the modules, using "const mm = MyModule" (admittedly, Python's "import...as" is cleaner).
      - luthaf 10y ago
        Yes, but `using MyModule` is (was?) the default and preferred way to use a module. Which is equivalent to recommend everyone to do `from module import *` in Python.
- bachmeier 10y ago
  There's a lot of activity for D in this area. For instance, there's a BLAS replacement[1] with good performance. Supporting numerical programming is a priority for Walter and Andrei. There's more work to do, but it is adding enough functionality that it will be a realistic option for those that like the language. [1] http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
  - deleted 10y ago
    [deleted]
- frozenport 10y ago
  Rust is like C++ but with better syntax for safer sharing of resources. If you don't like C++ you're not going to like Rust.
- david-given 10y ago
  Has anyone tried numerical programming in Ada? I haven't played with Ada arrays much, but I know it supports various different representations (so it can be binary compatible with Fortran column-first arrays and C row-first arrays), it's got nice array slicing semantics, it's got good support for generics which can operate on arbitrary sized arrays. I don't know whether it has Fortran-like aliasing guarantees, though. You can't take an address of an array element unless the array has been declared to support it, which helps, but I don't know whether you can e.g. pass the same array by mutable reference into a function twice. (It makes sense that this isn't supported, as it's kinda meaningless, but I can't find an actual reference.)
  - nickpsecurity 10y ago
    It might have changed in 2005 or 2012 revisions but here is Ada 95's take on that: http://www.adaic.org/resources/add_content/docs/craft/html/ch06.htm#6.7 http://www.adaic.org/resources/add_content/docs/craft/html/c... Also check out ParaSail language designed for easy, safe parallel and concurrent programming. It's an Ada variant from Tucker Taft at AdaCore. Might have something interesting on this topic. Might not.
- m_mueller 10y ago
  Why don't you want to use Fortran? If you want to get started, here's my recommendation: Program Kernels only in Modern Fortran, learn about f2py bindings and do the other parts in NumPy. If you use Fortran purely as a number crunching language - no I/O, no setup, no config code etc. - it's pretty sweet actually - IMO there isn't much need for replacing it with something new that has 50 years of compiler work to catch up (which is near impossible anyways).
  - keldaris 10y ago
    Not the OP, but a computational physicist writing a fairly decent sized codebase for a long term project, just went through the language choice and initial prototyping phase. I have extensively used Julia, Python, MATLAB, C99, C++98/11/14, Fortran and D for work and I believe in picking the right tool for the job. I chose C++ (writing in a fairly modern style, but not eschewing aliasing-restricted pointers, etc. where beneficial) because it handily beats everything except Fortran for performance and is vastly superior to Fortran in terms of zero-cost abstraction. I'm writing code that's largely portable between CPUs and accelerators (mostly GPUs) and has a lot of interchangeable parts. With C++ I can use templates to achieve compile time polymorphism and genericity, while retaining Fortran level performance on CPUs at the cost of higher code complexity. The Fortran story on GPUs has also been very disappointing initially, especially for those of us not interested in proprietary compilers, though I understand the situation is improving there. Ultimately, in my experience, while individual strengths of C++ can be reproduced in other languages, there's no other language that does it all. I hope that changes some day (for now, D looks like the most promising alternative to me) as writing C++ is often an exercise in frustration, but that's where we're at.
    - m_mueller 10y ago
      I'm in a similar situation as you, albeit with a large Fortran codebase that needs to stay - therefore I chose to write a transpiler in python that enables a Fortran codebase to be parallelised on CPU and GPU - see my profile link.
      - 10y ago
koverstreet 10y ago
Can you go into a bit about what specifically is missing? A lot of the people who work on the compiler/library support for this stuff aren't the primary consumers of it. I personally like working on this kind of code when I have time (I've done a bit of work on the rust bignum library), but it helps to know what's actually going to be useful to people.
- m_mueller 10y ago
  Basically, OPs article gives a good overview on what scientists want out of a language used for large scale numeric simulations. 1.) Multi-dim arrays supporting array math, slicing and flexible indexing, sizeof always known (internally solved through lookup tables). 2.) Fast-by-default rather than safe-by-default. A safe language is useless if it gives 2x or more runtime overhead. Make it safe where it doesn't give you any performance penalty (i.e. compile-time checks), otherwise make the default performant or leave the choice to the programmer. Example: Pass-by-reference as default, no GC. Essentially, I don't think Fortran will be replaced any time soon - maybe strong AI that can program all of this stuff from pure math specification will be here sooner than a Fortran replacement. To everyone not understanding this, read the article again. There's been a huge amount of effort going into this language the last 20 or so years - almost more than justified by the size of the HPC market, which is visible by all the compilers lagging behind the specs. If you want to help, go and improve gfortran (e.g. with better GPU support so people don't need the lagging PGI or locked down Cray compilers anymore).
stymaar 10y ago
> Rust has great potential to challenge Fortran in this domain, but numerics is mostly an afterthought in Rust. A common problem with Rust: many people from different backgrounds sees it as a godsend (for some good reasons) and they'd like to replace their former language with it, but the language can't evolve fast enough to satisfy everybody at the same time. It started as a language for desktop softwares (like a web browser, it's first use-case), and currently the focus is to evolve it to be suitable for back-end development (with asynchronous IO). I hope one day scientific software will become a first class citizen too.
- steveklabnik 10y ago
  While this is true in some sense, there's also a difference between the language changing to support a use-case, and the library ecosystem. The language doesn't _need_ to change for the async io stuff, though there is one feature that will be extremely helpful, "impl Trait". That feature is also needed for other reasons too, so it's not solely motivated by the async io stuff. It is totally true that there are many areas that can be improved, and it's gonna take time and effort to knock them out. It's tough! My personal pet area is OS dev...

throwaway7645 10y ago

Agreed. I want to write numeric software, but don't want to use Fortran or C++. Rust looked great, but I couldn't find anything in this domain.

goatlover 10y ago
Julia has strong numerical and multi-dimensional array support, but it's JIT compiled. However, once a function is JITted, it has comparable performance to Go & Rust.
- divbit 10y ago
  Seconded for Julia. I have been using it for math prototyping and it's recently replaced my old favorites like matlab / python / lua.
- dnautics 10y ago
  I believe the multidimensional arrays are backended by Fortran
  - 3JPLW 10y ago
    Not really. They're just written in a way such that the memory layout is compatible with BLAS libraries — which are frequently written in Fortran. So they can be passed directly to functions that happen to have been written in Fortran.
    - photon-torpedo 10y ago
      Additionally, invoking BLAS/LAPACK only happens for dense arrays of specific types (single/double precision real/complex numbers). The great thing in Julia is that almost all of the array and linear algebra functionality is implemented completely generically, so that algorithms can be written using these higher-level concepts, and the low-level functionality will (very efficiently) dispatch to BLAS/LAPACK if possible; if not, the generic implementations still allow your algorithm to work for e.g. your user-defined number type.
    - dnautics 10y ago
      haha yeah I guess i should have been more precise with my wording. I'm currently prototyping a custom number system in julia, and obviously, the multidimensional array ops will not be backended in BLAS.
- luthaf 10y ago
  Yep, Julia is a very nice language with very good performances. But I abandoned it because it is not (yet?) oriented toward library development, and more usable in exploratory style. I ran into issues a year ago when trying to organize a library with more than 8000 loc, when the "dump everything into a global namespace" started to be more a hassle and less a nice way to get stuff done. I am waiting for it to stabilize a bit before giving a second try.
  - photon-torpedo 10y ago
    Could you elaborate on why you felt the need to "dump everything into the global namespace"? For quite a long time now, you can use modules in Julia to keep things in separate namespaces. With "import MyModule" (instead of "using MyModule") things will not enter the global namespace, but will need to be qualified, like "MyModule.myfunction(...)". I feel this is very much like Python. You could even introduce abbreviations for the modules, using "const mm = MyModule" (admittedly, Python's "import...as" is cleaner).
    - luthaf 10y ago
      Yes, but `using MyModule` is (was?) the default and preferred way to use a module. Which is equivalent to recommend everyone to do `from module import *` in Python.
bachmeier 10y ago
There's a lot of activity for D in this area. For instance, there's a BLAS replacement[1] with good performance. Supporting numerical programming is a priority for Walter and Andrei. There's more work to do, but it is adding enough functionality that it will be a realistic option for those that like the language. [1] http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
- deleted 10y ago
  [deleted]
frozenport 10y ago
Rust is like C++ but with better syntax for safer sharing of resources. If you don't like C++ you're not going to like Rust.
david-given 10y ago
Has anyone tried numerical programming in Ada? I haven't played with Ada arrays much, but I know it supports various different representations (so it can be binary compatible with Fortran column-first arrays and C row-first arrays), it's got nice array slicing semantics, it's got good support for generics which can operate on arbitrary sized arrays. I don't know whether it has Fortran-like aliasing guarantees, though. You can't take an address of an array element unless the array has been declared to support it, which helps, but I don't know whether you can e.g. pass the same array by mutable reference into a function twice. (It makes sense that this isn't supported, as it's kinda meaningless, but I can't find an actual reference.)
- nickpsecurity 10y ago
  It might have changed in 2005 or 2012 revisions but here is Ada 95's take on that: http://www.adaic.org/resources/add_content/docs/craft/html/ch06.htm#6.7 http://www.adaic.org/resources/add_content/docs/craft/html/c... Also check out ParaSail language designed for easy, safe parallel and concurrent programming. It's an Ada variant from Tucker Taft at AdaCore. Might have something interesting on this topic. Might not.
m_mueller 10y ago
Why don't you want to use Fortran? If you want to get started, here's my recommendation: Program Kernels only in Modern Fortran, learn about f2py bindings and do the other parts in NumPy. If you use Fortran purely as a number crunching language - no I/O, no setup, no config code etc. - it's pretty sweet actually - IMO there isn't much need for replacing it with something new that has 50 years of compiler work to catch up (which is near impossible anyways).
- keldaris 10y ago
  Not the OP, but a computational physicist writing a fairly decent sized codebase for a long term project, just went through the language choice and initial prototyping phase. I have extensively used Julia, Python, MATLAB, C99, C++98/11/14, Fortran and D for work and I believe in picking the right tool for the job. I chose C++ (writing in a fairly modern style, but not eschewing aliasing-restricted pointers, etc. where beneficial) because it handily beats everything except Fortran for performance and is vastly superior to Fortran in terms of zero-cost abstraction. I'm writing code that's largely portable between CPUs and accelerators (mostly GPUs) and has a lot of interchangeable parts. With C++ I can use templates to achieve compile time polymorphism and genericity, while retaining Fortran level performance on CPUs at the cost of higher code complexity. The Fortran story on GPUs has also been very disappointing initially, especially for those of us not interested in proprietary compilers, though I understand the situation is improving there. Ultimately, in my experience, while individual strengths of C++ can be reproduced in other languages, there's no other language that does it all. I hope that changes some day (for now, D looks like the most promising alternative to me) as writing C++ is often an exercise in frustration, but that's where we're at.
  - m_mueller 10y ago
    I'm in a similar situation as you, albeit with a large Fortran codebase that needs to stay - therefore I chose to write a transpiler in python that enables a Fortran codebase to be parallelised on CPU and GPU - see my profile link.
    - 10y ago

koverstreet 10y ago

Can you go into a bit about what specifically is missing? A lot of the people who work on the compiler/library support for this stuff aren't the primary consumers of it. I personally like working on this kind of code when I have time (I've done a bit of work on the rust bignum library), but it helps to know what's actually going to be useful to people.

m_mueller 10y ago
Basically, OPs article gives a good overview on what scientists want out of a language used for large scale numeric simulations. 1.) Multi-dim arrays supporting array math, slicing and flexible indexing, sizeof always known (internally solved through lookup tables). 2.) Fast-by-default rather than safe-by-default. A safe language is useless if it gives 2x or more runtime overhead. Make it safe where it doesn't give you any performance penalty (i.e. compile-time checks), otherwise make the default performant or leave the choice to the programmer. Example: Pass-by-reference as default, no GC. Essentially, I don't think Fortran will be replaced any time soon - maybe strong AI that can program all of this stuff from pure math specification will be here sooner than a Fortran replacement. To everyone not understanding this, read the article again. There's been a huge amount of effort going into this language the last 20 or so years - almost more than justified by the size of the HPC market, which is visible by all the compilers lagging behind the specs. If you want to help, go and improve gfortran (e.g. with better GPU support so people don't need the lagging PGI or locked down Cray compilers anymore).

stymaar 10y ago

> Rust has great potential to challenge Fortran in this domain, but numerics is mostly an afterthought in Rust. A common problem with Rust: many people from different backgrounds sees it as a godsend (for some good reasons) and they'd like to replace their former language with it, but the language can't evolve fast enough to satisfy everybody at the same time. It started as a language for desktop softwares (like a web browser, it's first use-case), and currently the focus is to evolve it to be suitable for back-end development (with asynchronous IO). I hope one day scientific software will become a first class citizen too.

steveklabnik 10y ago
While this is true in some sense, there's also a difference between the language changing to support a use-case, and the library ecosystem. The language doesn't _need_ to change for the async io stuff, though there is one feature that will be extremely helpful, "impl Trait". That feature is also needed for other reasons too, so it's not solely motivated by the async io stuff. It is totally true that there are many areas that can be improved, and it's gonna take time and effort to knock them out. It's tough! My personal pet area is OS dev...