-
Notifications
You must be signed in to change notification settings - Fork 482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Breaking] Refactor Backend Names #904
Conversation
The description lacks mention of the fundamental rules or principles being followed. Please summarize all changes in terms of rules or principles, so others can easily follow and review your changes. This request stems from the fact that many people are accustomed to the previous convention, so adapting to the new changes will require a shift in both mindset and the code/APIs. |
Agreed! I'm still working on it after an earlier self-review. More descriptions and changes are expected to better follow the Rust naming conventions! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's especially great when long lines like ADBackendDecorator<WgpuBackend<...
become Autodiff<Wgpu<...
I also like the fact that the backend word is now reserved for traits only. It's very wordy to say that NdArrayBackend implements Backend, when NdArray implements Backend is enough
@@ -420,8 +419,7 @@ operation nodes. | |||
The only remaining part is to implement our autodiff-decorated backend trait for our WGPUBackend. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should write WGPU backend
burn-core/src/lib.rs
Outdated
|
||
#[cfg(feature = "std")] | ||
#[cfg(test)] | ||
pub type TestADBackend = burn_autodiff::ADBackendDecorator<TestBackend>; | ||
pub type TestADBackend = burn_autodiff::Autodiff<TestBackend>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we aim at changing every mention of 'AD'?
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #904 +/- ##
==========================================
- Coverage 86.50% 86.49% -0.01%
==========================================
Files 471 471
Lines 44142 44217 +75
==========================================
+ Hits 38183 38244 +61
- Misses 5959 5973 +14
☔ View full report in Codecov by Sentry. |
This refactor aims to improve the clarity of Burn when selecting a backend. Also, it aims to make it easier to create new backends without having to deal with unreadable associative types through the use of type aliases (
FloatTensor
,IntTensor
,BoolTensor
,FloatElem
,IntElem
, andDevice
).There are breaking changes, but only for the naming. The type aliases don't break anything but simplify the process of creating new backends!
Also, some other changes are made to be more in line with the Rust way of naming things, namely having
UpperCamelCase
for acronyms and contractions, as well as for types.ADBackend
=>AutodiffBackend
ADModule
=>AutodiffModule
ADTensor
=>AutodiffTensor
TestADBackend
=>TestAutodiffBackend
TestADTensor
=>TestAutodiffTensor
ADBackendDecorator
=>AutodiffDecorator
One of the main changes for backend names is to remove the
Backend
suffix, since the types are now available throughburn::backend
. Also, I think it's way cleaner to haveAutodiff<LibTorch>
than to haveADBackendDecorator<TchBackend>
. TheLibTorch
change is also motivated by better clarity. Yes, we usetch
for the bindings, but the most interesting part of the backend isn't the binding, but the code that is used!I removed the re-exported backend type alias such as
WgpuAutodiffBackend
since now the name of the autodiff backend isn't as obscure as before. The biggest benefit is that users will have access to the actual documentation of the backend they use instead of the small doc on top of each alias.The autodiff backend name
ADBackendDecorator
was bothering me for some time. Including the pattern in the name isn't something really bad in some cases, but we don't add amacro
suffix to all macros orderive
to allDerive
, so I think it's better to emphasize the actual behavior that is added instead of the pattern used. I think it's more appropriate to describe the pattern in the documentation.