Pan tam chyba mówił, że pełne generacje kodu zajęły więcej niż ma do dyspozycji na prezentacji.
Pewnie cała wiedza o gcc jest na irc i listach dyskusyjnych rozłożona na wiele lat. Pewnie dlatego niektórzy trenują pisząc coś w oparciu o sam kod źródłowy zamiast o dokumentację. Nawet rozwijają w tym kierunku swoje narzędzia wyszukiwania i analizy.
Jak duże są większe fragmenty? To coś co wymaga już jakiejś ogólnej struktury? Wiele osób też nie umie kodować bez ciągłego uruchamiania kompilacji lub jakiegoś serwera wskazującego błędy podczas pisania. Ktoś jednak powiedział, że to psuje umysł. Najlepsze dla umysłu jest podobno “najpierw pomyśl, potem dobrze napisz”.
Nawet rozwijają w tym kierunku swoje narzędzia wyszukiwania i analizy.
Właśnie po to analizuję IR gcc :-)
Jak duże są większe fragmenty? To coś co wymaga już jakiejś ogólnej struktury?
To zależy od złożoności zadania. Ogólnie nie ma problemu ze składnią kodu z LLMa. Kompilacja C++ prawie zawsze się udaje.
W przypadku łatwiejszych zadań zdarza się, że kilkaset linijek boilerplate’u nie zawiera istotnych problemów.
Ale czasem nawet 5 linijek z bardziej złożoną manipulacją na IR (generowanie wywołaia funkcji, obsługa wyjątków) potrafi spowodować Internal Compiler Error.
W takich przypadkach przetworzony IR narusza zazwyczaj wewnętrzne założenia w GCC. Np. zaburza postać static single-assignment.
Człowiek może takie problemy można dość prosto rozwiązać.
Na przykład mój plugin ma automatycznie dodawać w określonych miejscach wywołania hooków.
Najpierw piszę sobie wzorcowy kod C/C++ z wstawionymi hookami i dumpuję jego prawidłowy IR do pliku.
Potem porównuję go z tym co wygenerował mój plugin dla kodu bez hooków.
LLM (bez trybu agenta) takiego porównania nie zrobi, bo nie ma możliwości uruchomienia tych narzędzi.
Wiele osób też nie umie kodować bez ciągłego uruchamiania kompilacji lub jakiegoś serwera wskazującego błędy podczas pisania.
Carmack nie pisze testów, ale uruchamia każdą nową funkcję pod debuggerem i sprawdza jej działanie linijka po linujce.
Ktoś jednak powiedział, że to psuje umysł.
Nie wątpię, ale nadal zdobywam wiedzę o dużym projekcie komercyjnym i nie dałbym rady robić równolegle podobnej analizy dla gcc bez wspomagania.
Jestem pewien, że sobie poradzisz. Ciekawią mnie dalsze etapy tego co robisz.
Czy w clang/LLVM byłoby łatwiej ze względu na jawność języków pośrednich? Przynajmniej tak mi wynika z prezentacji MOS, którą wklejałeś. Że za clang jest prosty IR i tam można łatwo wstawiać takie rzeczy.
Pan tam chyba mówił, że pełne generacje kodu zajęły więcej niż ma do dyspozycji na prezentacji.
Pewnie cała wiedza o gcc jest na irc i listach dyskusyjnych rozłożona na wiele lat. Pewnie dlatego niektórzy trenują pisząc coś w oparciu o sam kod źródłowy zamiast o dokumentację. Nawet rozwijają w tym kierunku swoje narzędzia wyszukiwania i analizy.
Jak duże są większe fragmenty? To coś co wymaga już jakiejś ogólnej struktury? Wiele osób też nie umie kodować bez ciągłego uruchamiania kompilacji lub jakiegoś serwera wskazującego błędy podczas pisania. Ktoś jednak powiedział, że to psuje umysł. Najlepsze dla umysłu jest podobno “najpierw pomyśl, potem dobrze napisz”.
Właśnie po to analizuję IR gcc :-)
To zależy od złożoności zadania. Ogólnie nie ma problemu ze składnią kodu z LLMa. Kompilacja C++ prawie zawsze się udaje.
W przypadku łatwiejszych zadań zdarza się, że kilkaset linijek boilerplate’u nie zawiera istotnych problemów.
Ale czasem nawet 5 linijek z bardziej złożoną manipulacją na IR (generowanie wywołaia funkcji, obsługa wyjątków) potrafi spowodować Internal Compiler Error.
W takich przypadkach przetworzony IR narusza zazwyczaj wewnętrzne założenia w GCC. Np. zaburza postać static single-assignment.
Człowiek może takie problemy można dość prosto rozwiązać.
Na przykład mój plugin ma automatycznie dodawać w określonych miejscach wywołania hooków.
Najpierw piszę sobie wzorcowy kod C/C++ z wstawionymi hookami i dumpuję jego prawidłowy IR do pliku.
Potem porównuję go z tym co wygenerował mój plugin dla kodu bez hooków.
LLM (bez trybu agenta) takiego porównania nie zrobi, bo nie ma możliwości uruchomienia tych narzędzi.
Carmack nie pisze testów, ale uruchamia każdą nową funkcję pod debuggerem i sprawdza jej działanie linijka po linujce.
Nie wątpię, ale nadal zdobywam wiedzę o dużym projekcie komercyjnym i nie dałbym rady robić równolegle podobnej analizy dla gcc bez wspomagania.
Jestem pewien, że sobie poradzisz. Ciekawią mnie dalsze etapy tego co robisz.
Czy w clang/LLVM byłoby łatwiej ze względu na jawność języków pośrednich? Przynajmniej tak mi wynika z prezentacji MOS, którą wklejałeś. Że za clang jest prosty IR i tam można łatwo wstawiać takie rzeczy.