[JamesJoyce]

#programista15k #programowanie #it #sztucznainteligencja

Robiliśmy niedawno projekt, w którym model okazał się trochę za duży do deployu, na jakiejś starej platformie. Uzyskiwanie wyników klasyfikacji przez userów trwało zwyczajnie za długo.

Skonwertowaliśmy więc dla testu znacznie mniejszy (6linijek kodu) model i przepisaliśmy go na c++. Wrzuciliśmy na platformę obydwa, python i c++. Efekt? Różnica w szybkości c++ kolosalna. Niemal real time.

Pisał o tym Andriy Burkov, tylko on konwertował Pythona na c:

Napisałem klasę w Pythonie, aby wykonać intensywne przetwarzanie dużego korpusu tekstu. Upewniłem się, że działa zgodnie z oczekiwaniami. Potem poprosiłem Claude'a, aby przepisał moją klasę w C (język, którego nie znam) i wyjaśnił, jak ją uruchomić.

Wynik: Czas przetwarzania Pythona: 63 minuty. Czas przetwarzania C: 2,3 minuty. To jest przyszłość dla oszczędności kosztów produkcji.

Procedura działania wg. Burkova

1. Use LLM to write Python.
2. Debug and fix Python.
3. Use LLM to generate unit tests for Python.
4. Make sure all unit tests pass.
5. Use LLM in a separate call to rewrite unit test from Python to C.
6. While true:
6.1 Use LLM to rewrite Python to C.
6.2 If C passes all unit tests, break.
7. Compile C for prod, deploy.

Dla obecnego klienta nie możemy konwertować kodu w llmie, więc ta opcja odpada, nie przekażemy całego modelu na c++, ale patrząc szerzej brzmi bardzo ciekawie. Zwlaszacza, gdy llmy będą lepsze w pisaniu i konwertowaniu kodu.

[groman43]

@JamesJoyce: C++ jest szybsze od Pythona. Ale hamerykę odkryłeś xDDD

[Saly]

@JamesJoyce: można też pisać w jakimś języku o podobnej wygodzie pisania jak Python np. Kotlin i mieć dużo lepszy performance od samego początku.

[JamesJoyce]

@groman43 byku, ale nie o to chodzi. C czy c++ nie mają bibliotek czy narzędzi do robienia takich rzeczy, plus nie są natywnie wspierane przez niektóre platformy. Dodatkowo pisanie od zera aplikacji w c jest o wiele żmudniejszym zadaniem niż napisanie tego samego w Pythonie. Autokonwersja przez llmy jest tu kluczem.

[JamesJoyce]

@vviktor123488 no oczywiście. O to mi chodzi. Nie o to że c jest szybsze od Pythona, ale że napisanie czegoś w Pythonie vs w C to ogromna różnica w zaangażowaniu i czasie pracy. Natomiast autokonwersja już nie.

[Strus]

1. Use LLM to write Python.

2. Debug and fix Python.

3. Use LLM to generate unit tests for Python.

4. Make sure all unit tests pass.

@JamesJoyce: Swietny sposob na uzyskanie kodu co do ktorego masz zerowa pewnosc, ze

[c137]

@JamesJoyce:

1. Use LLM to write Python.

2. Debug and fix Python.

3. Use LLM to generate unit tests for Python.

4. Make sure all unit

[JamesJoyce]

@Strus byku, ale ja to wiem. To jest tylko przykład. Wiem, że to nowa nazwa starych rzeczy, że nie musi być c, że wiele bibliotek, w tym tych do ai to wrappery na c itd. Podaje jedynie przykład tego, co jak się okazuje (po późniejszym researchu) robi się modne. I tyle.

1. Co do pewności i jakości kodu, to niestety nie zgadzam się. Wiadomo, zależy od zadania. Ale posługując się dobrze

[JamesJoyce]

@c137 bo bez spełnienia wielu wymagań do tego się jedynie nadaje. Lub do prostych skryptów, które są „duże” przez liczbę features, albo dane.

W przykładzie Burkova nie chodziło o cały program. Ja też o nim nie myślę. Myślę, że tego nie napisałem jasno. Jemu (mam nadzieję) i mnie chodzi o coś, co jest znane (w kontekście ai). Różnią się jedynie dane i pewne zmienne w parametrach, czy preprocessingu danych wejściowych. Problemem

[Strus]

Ale posługując się dobrze dobrymi modelami, do programowania, można osiągnąć świetne rezultaty.

@JamesJoyce: Wiele osob tak pisze, ale jak dotad nie widzialem dowodu ( ͡° ͜ʖ ͡°)

[JamesJoyce]

@Strus: Musisz uwierzyć bez dowodu bracie ( ͡° ͜ʖ ͡°)

[p.....s]

@JamesJoyce: czemu nie https://github.com/oracle/graalpython ?

[Saly]

czemu nie https://github.com/oracle/graalpython ?

@proteina_sin_huevos: wątpie, że grall osiągnie wydajność porównywalną z C. Problemem są struktury danych. Co z tego, że grall ogarnie super optymalizacje do jakiejś pętli jak pod spodem i tak będą wołane wolne operacje na listach, gdzie każdy element jest dynamiczny.

Szybkie języki nie koniecznie są szybkie dlatego, że mają dobry JIT/optymalizacje tylko dlatego, że design języka naturalnie wymusza na tobie pisanie optymalnego kodu. Tak samo jest

[wafel93]

@JamesJoyce: przeciez te wieksze biblioteki do data w pythonie są napisane w C wlasnie

[JamesJoyce]

@wafel93: nie zawsze w C. Czasem w cpp czy czymś jeszcze innym niż Python. Wiem i pisałem o tym.

[Krolik]

@vviktor123488: napisanie w asemblerze nie gwarantuje że będzie szybciej niż w C++ chyba że jesteś mega ogarniaczem asemblera i znasz bardzo dokładnie mikroprocesor na który piszesz kod. Najczęściej daje się pobić kompilatory w takich kwestiach jak użycie instrukcji SIMD ale w „zwykłym kodzie” gra jest niewarta świeczki.

Napisanie czegoś w "tych wolnych" technologiach zajmuje np godzine, a to samo w c++ 4h albo i więcej. Koszt utrzymania aplikacji?

Stwierdzenie niepoparte