Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dense-linear-algebra : Weird memory and runtime behavior from generateSym #58

Open
Magalame opened this issue May 15, 2019 · 2 comments

Comments

@Magalame
Copy link
Contributor

Magalame commented May 15, 2019

The generateSym function is defined as:

generateSym :: Int -> (Int -> Int -> Double) -> Matrix
generateSym n f = runST $ do
  m <- unsafeNew n n
  for 0 n $ \r -> do
    unsafeWrite m r r (f r r)
    for (r+1) n $ \c -> do
      let x = f r c
      unsafeWrite m r c x
      unsafeWrite m c r x
  unsafeFreeze m

Running it with n=100, I noted we can note that the function allocates ~ 160 000 bytes of memory, which is around twice what we would expect when allocating one Matrix.
This allocation seems to be related to the dependence on c of x. If we change f r c to f r r, the allocation drops 80 000 bytes, and the runtime is divided by two.

@ocramz
Copy link
Member

ocramz commented May 30, 2019

If we change f r c to f r r

Doesn't this change the behaviour of the function as well? i.e. it would only read indices from the diagonal.
I think it would be better to introduce sparse formats, such as "lower triangular" matrices etc. and have specialized implementations for those. But this would also significantly increase the scope of this library.

@Magalame
Copy link
Contributor Author

Magalame commented May 30, 2019

Doesn't this change the behaviour of the function as well?

It does, it was just to point out that there is something weird happening with the dependence on c, because there seems to be no obvious reason why f r c would lead to twice the allocation induced by f r r.

But this would also significantly increase the scope of this library.

At some point we'll probably need these features in the Haskell ecosystem anyway :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants