Te cuento un poco de lo que he aprendido con un proyecto open source..
En el octoberfest de github la hackathon, en los proyectos open source este llamo la atención porque los bounties eran pagos, descargue el repo y un par de meses después fue que pude comenzar a trabajar en el.
Estas personas también tienen un canal de discord, donde a diario se postea todo lo referente a el proyecto y donde todos podemos comunicar nuestros avances o ideas, es como si estuviera trabajando con un equipo que desarrolla un framework o biblioteca de aprendizaje automático
Al leer la documentación y descubrí que comparado con mi repo local faltaban algunos archivos importantes que trataban de como tinygrad convertía el tensor en código maquina (kernel gpu).
Actualizar el repo porque tenia 520 commits atrasados: ver el ultimo commit o los últimos commits de la rama master
git log -1 origin/master --format="%h%n%an%n%ad%n%s" --date=iso
guardar cambios locales: git stash save "aqui el mensaje"
descargar cambios: git fetch (o pull) origin master
aplicar cambios descargados: git merge master
recuperar cambios locales: git stash apply stash@{#}
Ahora con la copia actualizada en los bounties escojo uno que llame la atención
-
buscamos en los archivos locales con find y grep partes claves del mensaje del bounties, si no encontramos nada entonces buscamos con git log:
find . -name "speed_v_torch" -type f
grep -r "test_sum" .github/workflows/
git log -1 --pretty=format:"%cd" -- test/test_speed_v_torch.py
Lo primero es entender el problema, quien lo causa y porque?
Ahora que encontramos el archivo toca aplicar técnicas de ingeniería para comprender que hace cada parte del código:
Identificar las clases principales:
- Cual es la entrada principal? (args, tensores)
- Cual es la salida principal? (return, resultado)
- Que transformacion hace? (suma, compilacion, optimizacion)
- Que estado mantiene? (cache, contadores)
- Que dependencias tiene? (imports, otras clases)
Una función misteriosa?: mira de donde viene, analiza los imports, busca su definición y responsabilidad, que hace la clase a la que pertenece y cual es su responsabilidad particular.
Sigue la pista de las variables, busca todos los usos y contexto
- quien lo crea?
- que contiene?
- quien lo usa?
- donde se modifica?
- encuentra factory methods (from_, create_, build_)
- identifica patrones de diseño (singleton, factory, etc.)
- traza flujos de datos (inputs -> outputs): mapas mentales de cual es el flujo
- encuentra configuraciones (constants, settings)
- busca tests para ejemplos (test/)
- analiza excepciones (try/except blocks)
- documenta lo que entiendes (explica como si tuvieras 5 años)
... Hasta aquí he aplicado git, pdb para debug (si, uso vim y edebugueo con pdb: n, l, p, w, r) y he mejorado la forma en la que leo el código de alguien mas mejorando mi lógica de programación
próximamente hablare del flujo de datos de un tensor en tinygrad, por ahora...
gracias por leer...
Continuando y buscando en la descripcion encontramos la user guide for amd gpu: kernel-descriptor
Top comments (0)