You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In concrete quantitative terms, the example provided here shows that replacing np_random.choice(...) with another function of equivalently simple syntax results in 27x speedup of the random choice, and for this example program, 4x speedup overall.
Researching the issue on stack overflow, the issue is known and appears on several posts in various forms: np_random.choice() - presumably derived from numpy.random.choice() - is not terribly efficient in the first place, ranging from complete bottleneck to only moderately inefficient under the ideal conditions of large vectorized operations.
When used like it is in the blackjack.py::draw_card function of open.ai gym, it is astonishingly slow: by a factor of 27x to be specific.
Example
When implementing a blackjack player with a fixed strategy (provided by Udacity) I noticed neither server nor local machine was getting the speed-performance I'd expect. I ran cProfile on toy(text) problem for 50000 iterations:
After changing the code, as shown in Apppendix, 27x local and 4x program total speedup
The random_sample() function effectively replaces np.random.choice() and now appears as the fifth-ranked time-consumer, taking 0.15 sec for the same number of calls that took 3.92 sec using the np.random.choice(...) function (about 27x speedup).
Thanks for the writeup! If anyone wants to make a PR with something like deck[int(len(deck)*np.random.random_sample())] in there, we could review that.
The inefficiency lies not within np_random.choice() itself but rather in the conversion of the Python list deck into a NumPy array. And the resolution is not to use random_sample() and convert its floating point to an int on 13-point integer scale, but rather to use randint() with the range 0...13 (exclusive). See e.g. https://stackoverflow.com/questions/29574605/performance-of-choice-vs-randint
Alternatively, the deck could be created directly as a NumPy array, which avoids the conversion altogether.
WHAT TO DO
Change the draw_card(...) function to the revised form shown, which will greatly speedup the Blackjack env:
Proposed change
The commented-out portion is the existing / unmodified code:
Why?
In concrete quantitative terms, the example provided here shows that replacing np_random.choice(...) with another function of equivalently simple syntax results in 27x speedup of the random choice, and for this example program, 4x speedup overall.
Researching the issue on stack overflow, the issue is known and appears on several posts in various forms:
np_random.choice()
- presumably derived from numpy.random.choice() - is not terribly efficient in the first place, ranging from complete bottleneck to only moderately inefficient under the ideal conditions of large vectorized operations.When used like it is in the blackjack.py::draw_card function of open.ai gym, it is astonishingly slow: by a factor of 27x to be specific.
Example
When implementing a blackjack player with a fixed strategy (provided by Udacity) I noticed neither server nor local machine was getting the speed-performance I'd expect. I ran cProfile on toy(text) problem for 50000 iterations:
Profile with original code using
choice
(sorted by time-in-function ex time-in-children):Of the 6.56 seconds that the code ran, the calls toe
choice(...)
take 3.92 seconds:After changing the code, as shown in Apppendix, 27x local and 4x program total speedup
The random_sample() function effectively replaces np.random.choice() and now appears as the fifth-ranked time-consumer, taking 0.15 sec for the same number of calls that took 3.92 sec using the
np.random.choice(...)
function (about 27x speedup).APPENDIX: profiled code (calculate state-value function Q for fixed-strategy:
Very slow code using np.random.choice(...) is commented out:
The text was updated successfully, but these errors were encountered: