Feda /dev/ - No Javascript allowed

me van a hacer una técnica que ya me anticiparon tendrá mucha carga de sql (en plan agnóstico, nada de cosas concretas del engine)

qué cosas debería repasar? transaction isolation levels top 1 de cosas que estoy seguro se comentarán, query plan/query execution y query plan hinting también, quizás algo de troubleshooting de carga en prod? supongo que algo de ORMs (mítica mierda n+1 y problemas del palo que sólo les pasan a los abuelos deprecated)

alguna idea más? todo esto para que luego me pregunten si sé hacer un join, me la veo venir

edit: table/row locks, select for update y similares son cosas obvias tb imho

Bueno, vamos por partes.

Por ahora hay poco hardware custom para LLMs en embebidos (algo más avanzado que una pseudogpu).

Cuantizar es un arte, y los drops de accuracy y artefactos en operadores raros/fusiones que te salen como no sepas lo que haces son curiosos.

#49290desu:

yo te podria hacer algo que va x1000 mas rapido que el estado de arte actual...

Cuando no mirábamos te has vuelto un artista de -como minimo- de x86-AMX (MKL) y aarch64-Neon o técnicas de compilación moderna para escribir tus propios passes en MLIR?

Esta tarde hago mi primera entrevista técnica, en principio enfocada en react. No me la he preparado, voy a mirar algun repo con preguntas tipicas y ale. Cuento con responder bien porque trabajo todos los dias con react, pero a saber.
Algun consejo?

#49294 no funciona así. las librerías de transformación a bajo nivel no son composables.

idealmente deberíamos tener un grafo de operaciones. minimizarlos y aplicarlo.

lo que pasa es que hoy en día todas las operaciones tienen un overhead de encoding compression resizing y demás que no son necesarios

si hoy exportar un vídeo en premier a 4K te tarda 1 minuto. Te puedo hacer que tarde 10 segundos. Pero la industria prefiere venderte hardware con más corea en lugar de hacer mejor software.

#49292 Ya que nadie te lo ha puesto (y le haces tu la entrevista a ellos)

EDIT: Me pasa por no leer. Si lo pusiste tú hace días xDD pensaba que lo había visto por Xwitter

#49302 este me lo leí cuando lo puse y tampoco me pareció tan "insightful" en el fondo, eran mucho memes (al nivel de la equality matrix de javascript) y algún corner case no intuitivo (ej null del tipo json no es el null de la db, que lo piensas y es obvio pero es normal cortocircuitar).

me parece mucho más core todo lo que he mencionado en #49292 que hay alguna cosa que no sale y las que salen están desperdigadas por todas las capas del iceberg, el librito que puse en #49131 también está bastante bien

al final en el fondo me siento muy verde con estas cosas (con todo en general a quién voy a engañar) pero de sql para un dev me parece core entender las "race conditions" de escritura/lectura, los distintos niveles de locking (isolation levels, table/row locks, pessimistic locking, etc), cositas de indexado y alguna cosa aparte como distintas estructuras de datos para los índices (como los inverted indexes), que no deja de ser todo muy básico si lo piensas bien

Viva .NET y sus errores de referencias al compilar que solo se solucionan mediante rituales de magia negra

Construyo algo y permito que se use mal.

Da fallos

Culpo al usuario por usar lo que he construido como se permite.

#49315 elabora para darte la razón o no

#49314 pues no es así, la mayoría de veces al actualizar dlls la gente sigue referenciado versiones antiguas. Que si, q a veces en visual studio se han metido Bugs, pero la mayoría de veces es que la gente no entiende como funcionan las copias locales de las dlls referenciadas, cambiar entre compilar a 64 o 32 bit, o mierdas así.