Get mxnet.symbol expression and dict for all params out of Gluon HybridBlock


#1

Hello,

in order to interface with older code, which creates a computation graph as mxnet.symbol and binds to an executor the old way, I’d like to get the mxnet.symbol expression for a HybridBlock, together with a dict for all the params the graph depends on, ideally with the shape information.

In short, I need all the info I can stick into bind(…) for an executor.

Even better if I could get the bound executor directly out of the HybridBlock, but that may be too. much to ask for. I still would like to have some freedom of which gradients are computed.

Can somebody point me to a complete example or doc where this is done?
BTW: We noted for this particular case (a fairly complex graph) also a substantial overhead of going with Gluon, autograd, and then hybridize, compared to the old code creating about the same graph. Order of 4x slower.


#2

use Hybridblock.export.

Could you share the graph so we can investigate?


#3

Hello,

an intern is working on this. He showed me what he is doing currently:

  • Call hybridize on the HybridBlock
  • Feed in mx.sym as inputs (instead of mx.ndarray)
    This gives him an mx.sym expression. In fact, we connect several of these. Then, we use the HybridBlock’s
    once more in order to obtain the args and args_grad dictionaries required to bind an executor.

Is HybridBlock.export equivalent to this, or better? Is there some documentation/example?

The graph is a bit complex. The story seems to be that with what he is doing, we get close to the speed of just building an mx.sym directly, while using mx.ndarray and autograd is quite a bit slower.

Given that there is not much detailed documentation on Gluon, HybridBlock, and how to speed up things if the usual “use mx.ndarray and autograd” is slow, it is likely we do something wrong. It would be very important to write such a documentation, given it does not exist yet (maybe I just don’t know).


#4

export basically does the same thing

HybridBlock is expected to be slower than Module for now. I’m working on this.