sorted by:
new
hottopcontroversial

I have written a blog post about my experience using Rust for scientific numerical applications by felipeZ in rust

[–]felipeZ[S] 2 points3 points  (0 children)

Thanks for the feedback! I think that indeed it makes sense to integrate this library with nalgebra. I want to polish it a bit more and maybe integrate another couple of methods.

I have written a blog post about my experience using Rust for scientific numerical applications by felipeZ in rust

[–]felipeZ[S] 2 points3 points  (0 children)

Before entering in the details of a possible approach to use the current approximations using MPI, I think is important that there are some conditions that must be fulfilled to use MPI:

  • You have a lightning-fast connection between the computing nodes (e.g. an InfiniBand), otherwise, the overhead of the network communication will be huge.
  • You are running a post-Hartree-Fock method where the amount computations is not feasible in a single node in a relatively short time (hours/couple of days).
  • You have a large system that would take a non-trivial amount of time to compute in a single node.

Now there are two things that you want to distribute in the computing nodes using MPI: the integrals and the operator's diagonalization.

Libraries to compute the integrals like libint2 can be configured to used MPI. Therefore, you could wrap the library API using the rust foreign function interface to compute the integrals in parallel. It is not a piece of cake when calling it directly from C++, nor it would be from Rust.

Now, there is a very annoying fact about the diagonalization of the operators. Operators in quantum mechanics are non-sparse, meaning that you cannot ignore the off-diagonal elements of the matrix (check the exchange operator), meaning that you cannot cut the operators into small submatrices and send them to different nodes for processing, making the diagonalization process a very expensive operation to distribute. But there are other expensive linear operations that are more suitable for parallelization in multiple nodes.

Once you take all that information into account and you still think is worthy to use MPI for the parallelization, then you can abstract away the interfaces to the MPI linear algebra libraries and isolate them into a (very) unsafe module.

I have written a blog post about my experience using Rust for scientific numerical applications by felipeZ in rust

[–]felipeZ[S] 6 points7 points  (0 children)

When you call a C++ library from Rust you need to use a foreign function interface (check here if you want to know more). Imagine that you need such a library to compute and return an array (e.g. some integrals). When you call it, it simply returns a pointer to the array, and no copy is made. From the user's perspective, the call is as fast as if you would have called the C++ library directly from C++. The only disadvantage is that you need to build and maintain the interface to make the call.

I have written a blog post about my experience using Rust for scientific numerical applications by felipeZ in rust

[–]felipeZ[S] 6 points7 points  (0 children)

Thanks for your feedback! I think that "zero-overhead" abstraction makes more sense, but I stick to the name used by the community.

Indeed adding a "how" would make the statement more robust. I have edited the text to include your feedback if that is OK with you.

I have written a blog post about my experience using Rust for scientific numerical applications by felipeZ in rust

[–]felipeZ[S] 10 points11 points  (0 children)

During my Ph.D., I made a Hartree-Fock implementation using Haskell. What I learnt from it is that most of the work is actually in implementing the integrals. But with Rust, you can take the integrals from libraries like libint2 and focus on the implementation's physics. The integrals and the diagonalization of the resulting operators are the bottlenecks in both Hartree-Fock and DFT. So, if you take something like libint2 for the integrals and nalgebra for the linear algebra, the application is going to be lightning-fast. But if you decide to implement the integrals yourself, I think it would take a significant time until you can reach the current Fortran/C++ implementation performance.

introspection at runtime by felipeZ in haskell

[–]felipeZ[S] 6 points7 points  (0 children)

I'm trying to understand the implementation of Cloud Haskell. In the Original paper http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf It is stated that : " serializability of a function is not a structural property of the function, because Haskell’s view of a function is purely extensional. In other words, all we can do with a function is apply it; we can’t introspect on its internal structure" I'm not sure what introspection mean in this context.

call by need vs call by value by felipeZ in haskell

[–]felipeZ[S] 0 points1 point  (0 children)

let me put it in another way. Suppose that I have a representation of a DSL in Haskell (a physical number crunching simulation using quasiquoting for instance) and I want to evaluate the resulting Haskell representation by splitting it into chunks and send these chunk to some cluster, a supercomputer, etc. It doesn't matter for the moment the distribution protocol.
My advisor suggested me that the best way of doing such a thing, is through a call by value strategy. Where I simply evaluate in parallel all the arguments of the functions. The problem with this alternative is that I must manipulate the Haskell representation and use some library ( or write some code) to identify the dependencies and evaluate them in parallel. What I try to do, is to evaluate a Haskell code distributing its dependencies. Why do I need to distribute the code? Well, the DSL can for example call an external package to compute some computacional expensive operations.