This repository has been archived by the owner on Nov 17, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
[MXNET-424] dtype option for multinomial #10970
Merged
Merged
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
9d191be
dtype option for multinomial
asitstands fdc2e1a
Add missing test for uint8
asitstands 9964521
Add check to ensure dtype has a sufficient precision.
asitstands 586cdb7
Fix lint
asitstands 7a127ff
Error message for the dtype precision check
asitstands 0966370
Retrigger CI
asitstands File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next
Next commit
dtype option for multinomial
- Loading branch information
commit 9d191be38ec5fbefba94d12d2d9ca709f23ce504
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of 2 layer switches is very slow to compile. Why do we need type support for output?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sometimes the multinomial samples need further processing in floating point arithmetic, so the samples need to be copied into a new array of floating point type. The copy slows down the training. For example, in RBM, the samples need to be applied by
linalg.gemm
which supports only floating point arrays.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A simple cast shouldn't cost that much?
This kind of nested switches are really slow to compile and makes the binary much bigger.
We need to make sure it really justifies the cost
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The binary size increases about 0.1% for both shared and static library (CUDA, CUDNN, MKL). Compiling mxnet already takes quite long time, so the relative increase of the compile time is also tiny.
I'm working with some variants of RBM and the use of
.astype('float32')
in several places increases training time over 20%. In the case of usual basic RBM, it increases about 10% of training time in my test for mnist. Of course, it depends on the hyperparameters and data. However, I think that, in general, the cost cannot be ignored for applications using heavy Monte Carlo samplings of discrete states.