[HN Gopher] Tinygrad 0.9.0
       ___________________________________________________________________
        
       Tinygrad 0.9.0
        
       Author : wozeparrot
       Score  : 101 points
       Date   : 2024-05-28 18:58 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | dhruvdh wrote:
       | What's the point of the 8000 LOC limit? Has anyone worked in a
       | project with a LOC limit? Why was the limit in place?
        
         | torlok wrote:
         | It's just a way to keep the code size in check, make sure it
         | can be read and understood relatively easily. Don't overthink
         | it. I doubt much, if any, research went into picking the limit.
         | The line width is over 120 in many places, and the code
         | inevitably ends up looking like                 cache_key =
         | (device, st, dtype, op, arg, tuple(ref(x) for x in srcs)) if
         | base is None else (st, ref(base))
        
           | kthxb wrote:
           | Seems the code sample contradicts your first statement
        
             | torlok wrote:
             | Indeed, I was making a point.
        
             | Lerc wrote:
             | I think this might be an example of
             | https://en.m.wikipedia.org/wiki/Goodhart's_law
             | 
             | The line count probably does still act as a limit on
             | complexity overall but perhaps less than hoped for.
        
         | ofou wrote:
         | To stay Tiny
        
         | jorlow wrote:
         | To keep it "tiny". (IIRC geohot started it because he thought
         | pytorch and others were bloated and a simple ml framework would
         | be inherently better)
        
         | vinkelhake wrote:
         | Right now there doesn't seem to be much point. IIRC they had a
         | 1000 LOC limit on the core part of the code when the project
         | was early.
         | 
         | The README no longer mentions the limit and it looks like they
         | just raise it whenever needed. Three months ago it was bumped
         | to 6500 LOC. One month ago it was bumped to 8000 lines.
        
           | rifty wrote:
           | A tech debt ceiling so to speak then. There might be some use
           | to it. It's still inevitably increased, but only after
           | debate, discussion, and a lot of time in-between really
           | considering the form and impact of the code being entered to
           | fit within the constraint
        
         | gkbrk wrote:
         | To compare, the PyTorch repo has ~400k lines of C, ~850k lines
         | of C++ and more than 1.5 million lines of Python code.
         | 
         | PyTorch does more than tinygrad, but does it really do 343x
         | more things?
        
           | danielmarkbruce wrote:
           | Probably.
        
           | adolph wrote:
           | If PyTorch does the 1-2 things you need and Tinygrad doesn't
           | do, then what are you going to use?
           | 
           |  _The Python source distribution has long maintained the
           | philosophy of "batteries included" - having a rich and
           | versatile standard library which is immediately available,
           | without making the user download separate packages._
           | 
           | https://peps.python.org/pep-0206/
           | 
           | OTOH:                 Simple is better than complex.
           | Complex is better than complicated.
           | 
           | https://peps.python.org/pep-0020/
        
           | jejeyyy77 wrote:
           | uh, ya? lol
        
         | matternous wrote:
         | It used to be a 1,000. I guess it's just a reminder to be
         | succinct.
        
         | entrep wrote:
         | Cyclomatic complexity would be a better measurement.
        
       | dventimihasura wrote:
       | You might consider posting not the release page, but rather the
       | repo page:
       | 
       | https://github.com/tinygrad/tinygrad
       | 
       | Another good alternative would be:
       | 
       | https://tinygrad.org/#tinygrad
        
       | Havoc wrote:
       | >experimental backends for not requiring any userspace components
       | like ROCm or CUDA.
       | 
       | That's pretty wild
        
       | jarbus wrote:
       | I see they have experimental AMD backends that don't use ROCm. Is
       | ROCm that bad that they wrote their own, or was there some other
       | justification for this?
        
       ___________________________________________________________________
       (page generated 2024-05-28 23:00 UTC)