YOLO9 Speedups

[atunSensei]

@EHxuban11
I made a new branch in my fork for some small tweaks in loss, nn, and transform of YOLO9. Wanted to share in case you're interested. Won't do a PR for this since I know too little about YOLO math and can't be 100% sure this doesn't really affect the math at all.

In loss: 
- Cache for the tensor "self.proj". As I understand it, this tensor only needs to be calculated once. (CPU savings).
- Cache for the tensor "self.target_scale". As I understand it, this tensor only needs to be calculated when resolution changes. (CPU savings).

In transform:
- Using LUT to pre-calculate saturation change values, which is calculated once unless augmentation changes. (CPU savings).
- Changed "np.ones" to "np.full" when calculating padded_img. Do math once, and propagate. (CPU savings).
- Changed to in-place math at "padded_img /= 255.0" (Memory savings).
- Changed "boxes_norm" to vectorized operation (CPU savings).
 - Added ".float32" to "r = np.float32(np.random.beta(32.0, 32.0))" to avoid float64 math in "img" calc (CPU savings).
- Changed "clamp" to "clamp_" for in-place operation (Memory savings).

In nn:
- Added "inplace=True" argument to "default_act = nn.SiLU()" to allow in-place calcs. (Memory savings).

I started training using this branch. Have not measured the performance increase. Trained model looks identical however. I'll keep on adding small tweaks here and there to this branch. I want to squeeze as much speed as possible as training times are only going to increase for my use case.

[EHxuban11]

Hello @fegonzalezg , interesting propositions. This microoptimizations put together can make the difference. Right now I'm heads down preparing the v1.2.0 release and don't have time for anything that is not a low hanging fruit, so I can't give attention they deserve to this microoptimizations that you are presenting.

YOLO9 was ported from multimediatechlab/YOLO as faithfully as possible, so what you're proposing here is genuinely the cherry on the top of an already working port.

The ideal next step, if you're down for it: run the benchmark locally measure the times with coco val 2017 5000 images, so that we have both mAP parity check as well as timings. and the if the numbers hold up, you can open an isue with the measurements. This could be a scientifically solid contribution from your part.

[atunSensei]

Hey @EHxuban11. I'm currently focused on getting my model working so haven't worked on Libre much. Made a bunch of other tweaks (and reverted some) and while I haven't tested speed, I saw a BIG reduction in VRAM usage. Not sure if this is because I'm now training in WSL2 + using torch compiler to fuse NVIDIA kernels (I also tweaked some functions in Libre to avoid breaking graphs AND allow using pretrained weights that were trained with torch compile, as original code flat out ignored your .pt file without warning if it doesn't perfectly match its expected weight structure upon loading) but I can now run a batch of 12 while before could only do 8.

Once I'm happy with the model, I'll focus on documenting all the changes and create a dedicated Pull Request so we can all review. Right now the "optimized yolo9 branch" of my fork is "highly experimental" 😂

[EHxuban11]

Sure don't worry. Sounds like you are doing interesting work. let's keep in touch 💪💪💪