Tak, Python jest wolny, ale mnie to nie obchodzi

1. Wydajność nie jest już ważna.
2. Liczy się szybkość.
3. Porozmawiajmy o mikroserwisach
4. Procesor nie jest twoim wąskim gardłem
5. Co jeśli nadal będziemy wpadać na procesor?
6. Więc Python jest szybki?
7. Ale co jeśli prędkość jest naprawdę ważna?
8. Zastrzeżenie
9. Optymalizacja Pythona

Наша команда-партнер Artmisto

Oryginał: „Tak, Python jest wolny i nie obchodzi mnie to” Nick Humrich; tłumaczenie zostało opublikowane po raz pierwszy Habrahabre .

Zatrzymuję się w dyskusji na temat asyncio w Pythonie, aby porozmawiać o szybkości Pythona. Pozwólcie, że się przedstawię, jestem gorącym fanem Pythona i używam go wszędzie, gdzie mogę. Jednym z powodów, dla których ludzie sprzeciwiają się temu językowi, jest to, że jest powolny. Niektórzy odmawiają nawet pracy nad tym, ponieważ „X jest szybszy”. Oto moje przemyślenia na ten temat.

Wydajność nie jest już ważna.

Wcześniej programy były uruchamiane przez bardzo długi czas. Zasoby procesora i pamięci były drogie, a czas pracy był ważnym wskaźnikiem. I ile zapłacili za energię elektryczną! Jednak te dni już dawno minęły, ponieważ główną zasadą jest:

Zoptymalizuj wykorzystanie swoich najdroższych zasobów.

Historycznie najdroższy był czas procesora. To jest dokładnie to, co przywołuje się podczas studiowania informatyki, koncentrując się na skuteczności różnych algorytmów. Niestety, nie jest już tak - żelazo jest teraz tańsze niż kiedykolwiek, a po nim czas wykonania staje się tańszy. Najdroższy jest czas pracownika, czyli ciebie. O wiele ważniejsze jest rozwiązanie problemu niż przyspieszenie wykonania programu. Powtarzam dla tych, którzy tylko przeglądają artykuł:

O wiele ważniejsze jest rozwiązanie problemu niż przyspieszenie wykonania programu.

Możesz się spierać: „Moja firma dba o szybkość. Tworzę aplikację internetową, w której wszystkie odpowiedzi pojawiają się w czasie krótszym niż x milisekund ”lub„ klienci opuścili nas, ponieważ uważali, że nasza aplikacja jest zbyt wolna ”. Nie mówię, że szybkość pracy w ogóle nie jest ważna, chcę tylko powiedzieć, że przestała być najważniejsza; to nie jest twój najdroższy zasób.

Liczy się szybkość.

Kiedy używasz słowa „prędkość” w kontekście programowania, najprawdopodobniej masz na myśli wydajność procesora. Ale gdy twój dyrektor używa go do programowania, oznacza szybkość działania. Najważniejszą miarą jest czas na rynek. Ostatecznie, bez względu na to, jak szybko twoje produkty działają, bez względu na to, w jakim języku programowania są napisane lub ile zasobów jest wymaganych do ich pracy. Jedyną rzeczą, która sprawi, że Twoja firma przetrwa lub umrze, jest czas na rynek. Nie mówię już więcej o tym, jak szybko pomysł zacznie generować przychody, ale o tym, jak szybko można wydać pierwszą wersję produktu. Jedynym sposobem na przetrwanie w biznesie jest szybszy wzrost niż konkurencja. Nie ma znaczenia, ile pomysłów masz, jeśli konkurenci wdrażają je szybciej. Musisz być pierwszy na rynku, a przynajmniej nadążać. Nieznacznie zwolnij - i zgiń.

Jedynym sposobem na przetrwanie w biznesie jest szybszy wzrost niż konkurencja.

Porozmawiajmy o mikroserwisach

Duże firmy, takie jak Amazon, Google czy Netflix, rozumieją znaczenie szybkiego rozwoju. Swoją działalność budują tak, aby mogli szybko wprowadzać innowacje. Pomagają im w tym mikroserwisy. Ten artykuł nie ma nic wspólnego z tym, czy należy na nich budować swoją architekturę, ale przynajmniej zgodzić się, że Amazon i Google powinny z nich korzystać. Mikrousługi mają powolny charakter. Ich koncepcja polega na korzystaniu z połączeń sieciowych. Innymi słowy, zamiast wywoływać funkcję, idziesz na spacer po sieci. Co może być gorsze pod względem wydajności? Połączenia sieciowe są bardzo powolne w porównaniu z cyklami procesora. Jednak duże firmy nadal wolą budować architekturę opartą na mikroserwisach. Naprawdę nie wiem, co może być wolniejsze. Największą wadą tego podejścia jest wydajność, a plusem będzie czas na rynek. Tworząc zespoły wokół małych projektów i baz kodu, firma może znacznie szybciej iterować i wprowadzać innowacje. Widzimy, że nawet bardzo duże firmy dbają o czas wprowadzania produktów na rynek, a nie tylko start-upy.

Procesor nie jest twoim wąskim gardłem

Jeśli piszesz aplikację sieciową, taką jak serwer WWW, najprawdopodobniej procesor nie jest wąskim gardłem aplikacji. Podczas przetwarzania żądania wykonanych zostanie kilka połączeń sieciowych, na przykład do bazy danych lub pamięci podręcznej. Serwery te mogą być dowolnie szybkie, ale wszystko zależy od szybkości transmisji danych w sieci. Oto naprawdę fajny artykuł, który porównuje czas wykonania każdej operacji. W nim autor liczy jedną sekundę na zegar procesora. W takim przypadku prośba z Kalifornii do Nowego Jorku potrwa 4 lata. Oto taka powolna sieć. Przy obliczeniach przybliżonych zakładamy, że transmisja danych przez sieć wewnątrz centrum danych trwa około 3 ms, co odpowiada 3 miesiącom w naszej skali odniesienia. Teraz weź program, który ładuje CPU. Załóżmy, że potrzebuje 100 000 cykli do przetworzenia jednego połączenia, będzie to równoważne 1 dniu. Załóżmy, że piszemy w języku, który jest 5 razy wolniejszy - zajmie to 5 dni. Dla tych, którzy chcą czekać 3 miesiące, różnica w ciągu 4 dni nie jest tak ważna.

Ostatecznie fakt, że python jest wolny, nie ma już znaczenia. Szybkość języka (lub czasu procesora) prawie nigdy nie stanowi problemu. Google to opisało jego badania . A tak przy okazji, mówi o rozwoju systemu o wysokiej wydajności. Podsumowując, należy dojść do następującego wniosku:

Decyzja o użyciu interpretowanego języka programowania w aplikacjach o wysokiej wydajności może być paradoksalna, ale mamy do czynienia z faktem, że procesor rzadko jest środkiem odstraszającym; Ekspresyjność języka oznacza, że ​​większość programów jest niewielka i większość czasu spędza na I / O, a nie na własnym kodzie. Co więcej, elastyczność interpretowanej implementacji była przydatna, zarówno w prostocie eksperymentów na poziomie językowym, jak i dając nam możliwość zbadania sposobów, w jakie obliczenia są dystrybuowane na wielu maszynach.

Innymi słowy:

Procesor rzadko jest środkiem odstraszającym.

Co jeśli nadal będziemy wpadać na procesor?

Co z tymi argumentami: „Wszystko jest w porządku, ale co, jeśli CPU stanie się wąskim gardłem i zacznie wpływać na wydajność?�� Lub „Język x jest mniej wymagający dla sprzętu niż y”? Mają też miejsce, w którym mogą być, jednak można skalować aplikację w nieskończoność w poziomie. Wystarczy dodać serwery, a usługa będzie działać szybciej :) Bez wątpienia Python jest bardziej wybredny pod względem sprzętu niż ten sam C, ale koszt nowego serwera jest znacznie niższy niż koszt twojego czasu. Oznacza to, że taniej będzie kupować dodatkowe zasoby i nie spieszyć się z optymalizacją za każdym razem.

Więc Python jest szybki?

W całym artykule powtarzałem, że najważniejszą rzeczą jest czas programisty. Pozostaje więc pytanie: czy Python X jest szybszy podczas programowania? To zabawne, ale ja Google i niektórzy ludzie więcej może potwierdzić jak produktywny Python. Ukrywa przed tobą tak wiele rzeczy, pomagając skupić się na głównym zadaniu i nie rozpraszać się żadnymi drobiazgami. Spójrzmy na niektóre przykłady z życia.

W większości, wszystkie kontrowersje wokół wydajności Pythona sprowadzają się do porównania typowania dynamicznego i statycznego. Myślę, że wszyscy zgodzą się, że statycznie typowane języki są mniej produktywne, ale na wszelki wypadek dobry artykuł wyjaśniając dlaczego. Jeśli chodzi o sam Python, to dobrze raport z badań który rozważa, ile czasu zajęło napisanie kodu do przetwarzania ciągów w różnych językach.

W powyższym badaniu Python jest ponad 2 razy bardziej wydajny niż Java. Wiele innych języków programowania daje podobne wyniki. Kod Rosetty był dość obszerny badania różnice w uczeniu się języków programowania. W artykule porównują Pythona z innymi językami interpretowanymi i stwierdzają:

Python jest ogólnie najbardziej zwięzły, nawet w porównaniu z językami funkcjonalnymi (średnio 1,2-1,6 razy krótszy).

Najwyraźniej implementacja w Pythonie ma zwykle mniej linii kodu niż w jakimkolwiek innym języku. Jednak może się to wydawać okropną metryką kilka badań w tym te wymienione powyżej, pokazują, że czas spędzony na każdej linii kodu jest w przybliżeniu taki sam w każdym języku. Zatem im mniej linii kodu, tym większa wydajność. Nawet sam kodowanie (programista C #) napisałem artykuł że Python jest bardziej produktywny.

Myślę, że można śmiało powiedzieć, że Python jest bardziej produktywny niż wiele innych języków programowania. Wynika to głównie z faktu, że pochodzi on „z bateriami”, a także ma wiele bibliotek innych firm na każdą okazję. Oto jest mały artykuł porównywanie Pythona i X. Jeśli mi nie wierzysz, możesz przekonać się, jak bardzo ten język programowania jest prosty i wygodny. Oto twój pierwszy program:

import __hello__

Ale co jeśli prędkość jest naprawdę ważna?

Powyższe rozumowanie może dodać opinię, że optymalizacja i szybkość wykonywania programu w ogóle nie mają znaczenia. W wielu przypadkach tak nie jest. Na przykład masz aplikację internetową i jakiś punkt końcowy, który jest bardzo wolny. Możesz nawet mieć na to pewne wymagania. Nasz przykład opiera się na pewnych założeniach:

1. jest jakiś punkt końcowy, który działa powoli
2. Istnieją pewne wskaźniki, które określają, jak może być przetwarzane wolne zapytanie.

Nie zajmiemy się mikro-optymalizacją całej aplikacji. Wszystko powinno być „wystarczająco szybkie”. Użytkownicy mogą zauważyć, że przetwarzanie żądania zajmuje kilka sekund, ale nigdy nie zauważają różnicy między 35 ms a 25 ms. Wystarczy, że aplikacja stanie się „wystarczająco dobra”.

Zastrzeżenie

Powinienem zauważyć, że istnieją aplikacje, które przetwarzają dane w czasie rzeczywistym, które wymagają mikro-optymalizacji, a każda milisekunda jest ważna. Ale to raczej wyjątek niż reguła.

Aby zrozumieć, jak zoptymalizować, musimy najpierw zrozumieć, co dokładnie trzeba zoptymalizować. W końcu:

Wszelkie ulepszenia dokonane gdziekolwiek indziej niż wąskie gardło są iluzją. - Gene Kim.

Jeśli optymalizacja nie wyeliminuje wąskiego gardła aplikacji, to po prostu marnujesz czas i nie rozwiązujesz prawdziwego problemu. Nie musisz kontynuować rozwoju, dopóki nie naprawisz hamulców. Jeśli próbujesz coś zoptymalizować, nie wiedząc dokładnie co, wynik prawdopodobnie nie zadowoli cię. Nazywa się to „przedwczesną optymalizacją” - poprawa wydajności bez żadnych wskaźników. D. Knutowi często przypisuje się następujący cytat, chociaż twierdzi, że nie jest jego:

Przedwczesna optymalizacja jest źródłem wszelkiego zła.

Dokładniej mówiąc, bardziej kompletny cytat:

Musimy zapomnieć o wydajności, powiedzmy, 97% czasu: przedwczesna optymalizacja jest źródłem wszelkiego zła. Nie powinniśmy jednak przegapić naszych szans w tym krytycznym 3%.

Innymi słowy, mówi tutaj, że przez większość czasu nie trzeba myśleć o optymalizacji. Kod jest tak dobry :) A w przypadku, gdy tak nie jest, nie więcej niż 3% będzie musiało Cię przepisać, jeśli przetwarzanie żądania zostanie wykonane kilka nanosekund szybciej. Optymalizuj to, co jest mierzalne.

Przedwczesna optymalizacja z reguły polega na wywoływaniu szybszych metod. Najwyraźniej sugerowane są wkładki montażowe> lub wykorzystanie określonych struktur danych z powodu ich wewnętrznej implementacji. Na uniwersytecie nauczono nas, że jeśli dwa algorytmy mają takie same asymptotyki Big-O, to są one równoważne. Nawet jeśli jeden z nich jest 2 razy wolniejszy. Komputery są teraz tak szybkie, że nadszedł czas, aby zmierzyć złożoność obliczeniową na dużej ilości danych. Oznacza to, że jeśli masz dwie funkcje O (log n), ale jedna jest dwa razy wolniejsza od drugiej, to nie ma to większego znaczenia. Wraz ze wzrostem rozmiaru danych oba zaczynają wyświetlać w przybliżeniu ten sam czas wykonania. Dlatego przedwczesna optymalizacja jest źródłem wszelkiego zła; To spędza nasz czas i prawie nigdy nie pomaga naszej ogólnej wydajności.

Jeśli chodzi o Big-O, wszystkie języki programowania mają złożoność O (n), gdzie n jest liczbą linii kodu lub instrukcji. Nie ma znaczenia, jak powolny będzie język lub jego maszyna wirtualna - wszystkie mają wspólny asymptot. <ok. per. Autor oznacza, że ​​nawet jeśli język X jest teraz dwa razy wolniejszy niż Y, to w przyszłości będą one w przybliżeniu równe prędkości po optymalizacji. jakie metryki.

Optymalizacja Pythona

W Pythonie podoba mi się to, że pozwala na optymalizację niewielkiej części kodu naraz. Załóżmy, że masz w Pythonie metodę, którą uważasz za wąskie gardło. Zoptymalizowałeś go kilka razy, być może przestrzegając wskazówek stąd i stąd , a teraz doszedłem do wniosku, że sam Python jest wąskim gardłem. Ale ma możliwość wywołania kodu w C, co oznacza, że ​​możesz przepisać tę metodę w C, aby zmniejszyć problem z wydajnością. Możesz łatwo użyć tej metody z resztą kodu.

Pozwala to na pisanie dobrze zoptymalizowanych metod wąskiego gardła w dowolnym języku, który kompiluje się do kodu asemblera, to znaczy kontynuujesz pisanie w Pythonie przez większość czasu i przechodzisz do programowania na niskim poziomie, tylko naprawdę go potrzebujesz.

Istnieje również Cython, który jest supersetem Pythona. Jest to mieszanka z wpisanym C. Każdy kod Pythona jest również poprawnym kodem w Cythonie, który jest tłumaczony na C. Możesz mieszać typy C i typowanie kaczki. Używając Cythona, uzyskasz wzrost wydajności tylko w wąskim miejscu, bez przepisywania reszty kodu. Na przykład EVE Online . Ta gra MMoRPG używa tylko Pythona i Cythona dla całego stosu, optymalizując tylko tam, gdzie jest to wymagane. Ponadto istnieją inne sposoby. Na przykład Pypy - Implementacja JIT Python, która może zapewnić znaczne przyspieszenie podczas wykonywania długotrwałych aplikacji (na przykład serwera WWW), po prostu zastępując CPython (domyślna implementacja) PyPy.

Główne punkty:

• zoptymalizować wykorzystanie najdroższego zasobu - czyli ciebie, a nie komputera;
• Wybierz język / strukturę / architekturę, która pozwoli Ci tworzyć produkty tak szybko, jak to możliwe. Nie powinieneś wybierać języka programowania tylko dlatego, że programy działają szybko;
• jeśli masz problemy z wydajnością, ustal, gdzie dokładnie;
• i najprawdopodobniej nie są to zasoby procesora lub Pythona;
• jeśli nadal jest Python (i już zoptymalizowałeś algorytm), zaimplementuj punkt problemowy w Cython / C;
• i szybko wróć do głównej pracy.

Dziękuję za uwagę!