deepcrayon
/
tinygrab
1
0
Fork 0
Code

feat: reword contributing (#1131)

pull/1135/head
wozeparrot 2023-07-05 01:17:47 -04:00 committed by GitHub
parent 793a670187
commit 981d4980c4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
CONTRIBUTING.md
View File

@ -1,12 +1,12 @@
# Are you ready to write high quality code?
The idea of tinygrad is to build a <5000 line library capable of training a wide variety of ML models at 80%+ theoretical max speed across a huge variety of hardware.
The idea of tinygrad is to build a <5000 line library capable of training a wide variety of ML models at 80%+ max theoretical speed across a huge variety of hardware.
There is almost no boilerplate code anywhere in this library, and you should help keep it that way. If the code you are contributing to core tinygrad `tinygrad/` isn't some of the highest quality code you've written in your life, either put in the effort to make it great, or don't bother. (other directories have a slightly more relaxed standard)
There is almost no boilerplate code anywhere in this library, and you should help keep it that way. If the code you are contributing to core tinygrad, in `tinygrad/`, isn't some of the highest quality code you've written in your life, either put in the effort to make it great, or don't bother. (other directories have a slightly more relaxed standard)
There is a linter, but it's not complete. Spend a little time reading and getting a feel for the style.
There is a linter, but it's not complete. Spend a little time reading the existing code to get a feel for the style.
I love PRs where I look at them and can just say, yes, this will improve the codebase and click merge. If you have an incomplete PR, feel free to post it as a draft.
I love PRs where I can look at them and just say, yes, this will improve the codebase and click merge. If you have an incomplete PR, feel free to post it as a draft.
As my operating systems professor taught me, code is written to be read by humans. We value readability over performance and line count, but low line count is often a good proxy for readability. However, any PRs that look like code golf will immediately be closed.
@ -18,16 +18,16 @@ These are the most straightforward. Discover a bug. Add a test to reproduce it.
## Conceptual Cleanups
This is some of the highest value work in tinygrad. If you realize two 50 line functions are basically the same thing and you can merge them, amazing! Things that look confusing and are hard to follow probably are poorly written, if you can rewrite the code and be like, oh that's a ton simpler, by all means do so. Make sure you have good test coverage around what you are changing.
This is some of the highest value work in tinygrad. If you realize two 50 line functions are basically the same thing, and you can merge them, amazing! Things that look confusing and are hard to follow are probably poorly written. If you can rewrite the code and be like, oh that's a ton simpler, by all means do so. Make sure you have good test coverage around what you are changing.
## Better Testing
Always welcome! Think about how robust and fast your tests are though. How likely is this test to catch a bug? Tests that run in CI go in `test/`, except for the ones in `test/external`. We have a few things like fuzzers in there.
Always welcome! Think about how robust and fast your tests are though. How likely is this test to catch a bug? Tests that run in CI go in `test/`, except for the ones in `test/external/`. We have a few things like fuzzers in there.
## Speed improvements
tinygrad is a JIT compiler, so speed improvements refer to both compile-time and runtime. Speed improvements to the Python are welcome, but please include benchmarks and good tests. Speed improvements to the generated code usually come from conceptual cleanups. Generated code improvements are probably the hardest thing to work on in tinygrad, since they must be done in a very generic way.
tinygrad is a JIT compiler, so speed improvements refer to both compile-time and runtime. Speed improvements to the python based compiler are welcome, but please include benchmarks and good tests around the things that you are changing. If you are sacrificing readability for speed, don't bother. Speed improvements to the generated code usually come from conceptual cleanups. Generated code improvements are probably the hardest thing to work on in tinygrad, since they must be done in a very generic way.
## Features
This is a trickier one. If there is a feature in PyTorch and numpy that you have actually seen people use, we probably want it. All new features must include good robust tests, and in general matching the PyTorch API is good.
This is a trickier one. If there is a feature in PyTorch and numpy that you have actually seen people use, we probably want it. All new features must include good robust tests, and in general, matching the PyTorch API is good.