Describe the bug
When HarmonicResonanceClassifier_BEAST_18D runs on a dataset using GPU acceleration (cupy or torch), it becomes painfully slow in some parts of the code.
The Problem in simple words: The GPU is like a super-fast sports car, and the CPU is like a normal car. To get maximum speed, you want the data to stay in the sports car as long as possible. However, in our codebase (specifically around the EntropyMaxwellUnit and some fallback logic), the code frequently converts GPU arrays back to CPU arrays inside repetitive loops using commands like cp.asnumpy() or torch.Tensor.cpu().numpy().
Every time this happens, the CPU has to completely stop and wait for the GPU to finish passing the data over the motherboard (a synchronization block). Because this stop-and-go happens repeatedly during training/prediction on large datasets, the GPU utilization drops to almost 0%, making the code even slower than if we had just used a CPU from the start!
Steps to reproduce
Switch to the gssoc-2026 branch.
Ensure you have a CUDA-enabled GPU and CuPy installed.
Initialize the HarmonicResonanceClassifier_BEAST_18D model on a relatively large dataset (e.g., 20,000+ rows).
Run the .fit() or .predict() function.
Monitor the GPU usage in your task manager or terminal (nvidia-smi). You will notice that the GPU usage is extremely low (bottlenecked) and the execution takes much longer than it mathematically should.
Expected behavior
The code should keep data natively on the GPU (as cupy arrays or torch tensors) throughout the entire mathematical process.
The Solution: We need to refactor the internal loops to perform all matrix operations directly on the GPU stream. We should only call cp.asnumpy() exactly once at the very end of the pipeline when we absolutely need to return the final array to Scikit-Learn. By removing these frequent CPU-GPU sync blocks, the model's speed will increase dramatically.
Describe the bug
When HarmonicResonanceClassifier_BEAST_18D runs on a dataset using GPU acceleration (cupy or torch), it becomes painfully slow in some parts of the code.
The Problem in simple words: The GPU is like a super-fast sports car, and the CPU is like a normal car. To get maximum speed, you want the data to stay in the sports car as long as possible. However, in our codebase (specifically around the EntropyMaxwellUnit and some fallback logic), the code frequently converts GPU arrays back to CPU arrays inside repetitive loops using commands like cp.asnumpy() or torch.Tensor.cpu().numpy().
Every time this happens, the CPU has to completely stop and wait for the GPU to finish passing the data over the motherboard (a synchronization block). Because this stop-and-go happens repeatedly during training/prediction on large datasets, the GPU utilization drops to almost 0%, making the code even slower than if we had just used a CPU from the start!
Steps to reproduce
Switch to the gssoc-2026 branch.
Ensure you have a CUDA-enabled GPU and CuPy installed.
Initialize the HarmonicResonanceClassifier_BEAST_18D model on a relatively large dataset (e.g., 20,000+ rows).
Run the .fit() or .predict() function.
Monitor the GPU usage in your task manager or terminal (nvidia-smi). You will notice that the GPU usage is extremely low (bottlenecked) and the execution takes much longer than it mathematically should.
Expected behavior
The code should keep data natively on the GPU (as cupy arrays or torch tensors) throughout the entire mathematical process.
The Solution: We need to refactor the internal loops to perform all matrix operations directly on the GPU stream. We should only call cp.asnumpy() exactly once at the very end of the pipeline when we absolutely need to return the final array to Scikit-Learn. By removing these frequent CPU-GPU sync blocks, the model's speed will increase dramatically.