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

Memory usage in numerical hessian #26

Closed
davidsebfischer opened this issue Oct 5, 2018 · 11 comments
Closed

Memory usage in numerical hessian #26

davidsebfischer opened this issue Oct 5, 2018 · 11 comments
Assignees
Labels
enhancement New feature or request
Projects

Comments

@davidsebfischer
Copy link
Contributor

I have a peak memory load of 45GB on 500 cells, I believe this is during hessian estimation, on a test data set. That should not be the case I think, it s only 10 or so parameters? We should go over step by step whether really only the relevant parts of the overall hessian are computed.

@davidsebfischer davidsebfischer added the enhancement New feature or request label Oct 5, 2018
@davidsebfischer davidsebfischer added this to To do in models via automation Oct 5, 2018
@davidsebfischer davidsebfischer self-assigned this Oct 5, 2018
@Hoeze
Copy link
Contributor

Hoeze commented Oct 7, 2018

A possible point to improve could be to use the new map-reduce operations:
#1

I'll look at that problem again as soon as my thesis is over / extended.

@davidsebfischer
Copy link
Contributor Author

@Hoeze I am checking this now, I think there is a some other problem here, too.

@davidsebfischer
Copy link
Contributor Author

The memory load goes up here in diffxpy/testing/base.py:_fit()
model = estim.finalize()

@Hoeze
Copy link
Contributor

Hoeze commented Oct 7, 2018

Yes, this is due to calculating the Hessian for sure.
I did not expect that this would be such an issue...

@LuckyMD
Copy link

LuckyMD commented Oct 7, 2018

Maybe this will improve if a sparse matrix representation is used?

@LuckyMD
Copy link

LuckyMD commented Oct 7, 2018

I have a peak memory load of 45GB on 500 cells, I believe this is during hessian estimation, on a test data set. That should not be the case I think, it s only 10 or so parameters? We should go over step by step whether really only the relevant parts of the overall hessian are computed.

Do you get this memory load also when running on a single core? I assumed it might have something to do with private copies of the data in each thread.

@davidsebfischer
Copy link
Contributor Author

Yes, also on a single core. I also don't think that linear algebra multi-threading, ie. distributing matrix multiplications, should cause memory copying, but that is just a guess.

@davidsebfischer
Copy link
Contributor Author

/Users/david.fischer/miniconda3/lib/python3.6/site-packages/tensorflow/python/ops/gradients_impl.py:108: UserWarning: Converting sparse IndexedSlices to a dense Tensor of unknown shape. This may consume a large amount of memory.
"Converting sparse IndexedSlices to a dense Tensor of unknown shape. "

is thrown during
hess = tf.hessians(- model.log_likelihood, params)
that might be related to this.

@davidsebfischer
Copy link
Contributor Author

So I guess IndexedSlices are used in tf.map_fn to map the hessian function across the slices of X and param. I do not see why anything here would be sparse though if X is dense in the input. Where is sparsity of X handled in batchglm @Hoeze?

@Hoeze
Copy link
Contributor

Hoeze commented Oct 7, 2018

I think this is internally used by tf.hessians.
Tensorflow uses basically a tf.while_loop to differentiate each value of the gradient by a single parameter.
Probably these indexedslices will be used to generate the resulting hessian matrix.

@davidsebfischer
Copy link
Contributor Author

Accidently posted the the resolving comment in a related issue:
#27 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
models
  
Done
Development

No branches or pull requests

3 participants