Purpose of (Column)TreeBuilderTrait?
vmx opened this issue · comments
We currently have two tree builders, TreeBuilder and ColumnTreeBuilder, both with their own traits. AFAICT, there are only those implementations of those traits. Hence I wonder what the purpose of the ColumnTreeBuilderTrait and TreeBuilderTrait traits is?
I propose removing those traits and moving the implementation directly into the structs. Benefits:
- Users of this library don't need to import those traits: Both tree builders, don't make much sense without implementing those traits. Usually users would import those structs as well as their traits.
- No search/guessing where other implementations might be.
- Easier to understand code, due to less abstractions.
Downsides:
- Breaking change, users of the library would need to update their code.
The historical reason for these traits is that originally we had specialized ways of building the trees on the GPU. In theory this could give better throughput by minimizing data being moved on and off the GPU. For example, the entire top of the tree should be buildable on the GPU without needing to move hashes back and forth to the CPU.
However, in practice (as then implemented at least), this wasn't showing benefits and led to less predictable use of RAM. So we moved to a simpler implementation where only batch hashing happens on the GPU, with the idea that batch sizes can be optimized to take advantage of GPU throughput.
If you don't anticipate ever wanting to revisit this in pursuit of even better throughput, we could change it. I suspect that with the right effort, it's probably still possible to do better — but I don't feel strongly that we must do so. If we intend to try at some point, it probably makes sense to retain the traits.
Thanks for the background information. I actually just thought about doing more of the tree building on the GPU as I think we could do better. As I'd love to take a look at that (although I probably won't have the time), let's keep them for now.