-
- Downloads
Thinning: bug fixes
There are two different “namespaces” referring to module names: normalized and de-normalized. Normalized module names are module names that have the same format for both data-parallel and data-serial models. De-normalized module names are the “raw” PyTorch module names that reflect the full model graph. So if there is a container module such as nn.DataParallel in the model, then a sub-module’s name will have the “module” substring somewhere in it. SummaryGraph operates by converting the PyTorch to ONNX, and I’ve have issues handling nn.DataParallel in this process. Therefore, SummaryGraph uses only normalized names internally. PruningRecipe, on the other hand, uses de-normalized names because it needs to operate on the model itself. This is a sticky situation that can create really annoying bugs and makes for some ugly code. Nonetheless, this is the best I can do right now, and I’ll probably revisit this soon to make it nicer. For now, I’m pushing this commit that fixes the distinction between the two namespaces, and fixes related bugs – in the hope that it is not too brittle. append_module_directive – now uses denormalize_module_name to ensure recipe module names are denormalized. append_param_directive – because we are dealing with parameters, I can’t use denormalize_module_name as easily as in append_module_directive. The clean solution is kept for later :-(
Loading
Please register or sign in to comment