Vlákno názorů k článku
Video z workshopu The One Billion Row Challenge: je PHP rychlejší než Java? od Uncaught ReferenceError: - boží. PHP je rychlejší než java, proto jsme...

boží. PHP je rychlejší než java, proto jsme si to napsali jako extension v C (protože IO v PHP je šíleně pomalé), pak použijeme zabugovaný neizolovaný PHP threads (nebo speciální thread safe verzi php, což je vtipné, protože běžné extension v tom dost plavou), abychom to nějak paralizovali na desítky threadů a pak tvrdíme, že jsme rychlejší než java.

Tímto nechci hejtovat jejich snahu, je to určitě pěkné, prošli si s tím, naučili se nové věci, prozkoumali to a zlepšili se. Stejný algoritmus na paralelizaci lze použít i v té Javě, tam se dostanou pravděpodobně na podobné časy. Bohužel ale jejich řešení nic nevypovídá o rychlosti (pomalosti) PHP a nelze to použít na běžné produkční aplikace.

Viděl jste to video vůbec? Napsání té extension dopadlo jako velká katastrofa (což tam bylo řečeno), autor to dokonce přiznal a nasypal si náležitě popel na hlavu. Problém s thread-safe extensions byl také zmíněn. Autor také rovnou řekl, že thready nechce v PHP používat. Jinak to, že Java je rychlejší, tam bylo několikrát zmíněno, dokonce je tam celý slide, který se tomu věnuje.

já tam dokonce byl osobně, video jsem si nepouštěl.

Ano, thready nechce používat, ale přitom je použil, aby měl dobré časy při měření, stejně jako ten céčkový modul, aby mohl data načíst rychleji než PHP umožňuje. Ono to pak vlastně moc už PHP není.

Já chtěl jen varovat ostatní, že to je dobré cvičení (kloub dolu kam se dostali a jak přistupovali k problému), ale pozor na použití v praxi.

Jestli jste tam byl tak víte, že ten "Céčkovy" modul ušetřil 0.23 sekund. :-D A že to za to nestojí. Takže ve finálním měření to byla nula k nule.

0.23s není zas tak málo.

"Ano, thready nechce používat, ale přitom je použil" - to je problém výzev, ale byl jste tam, takže dobře víte rozdíl mezi výzvou a produkčním kódem. Byl tam tomu taky věnovaný čas. Takže je to spíše kritika ve stylu "autor dostatečně nezmínil, že takhle se nemá v praxi programovat"?

To mate to same, jako numpy a cela AI saskarna v pythonu. Clovek by si myslel ze python je nejak specialne vykonny na tohle.. ale chyba - jedna se pouze o wrapper, aby byla dana vec rychleji napojitelna.

přesně. Python se dnes masivně používá pro analytiku, nejeden (i vývojář) si myslí, že je python na to skvělý a výkonný a přitom celé kouzlo je v tom, že se vlastně python nepustí vůbec k práci a vše se udělá v C/C++/Rust/ASM výrazně optimalizované knihovně a python je jen takový ovladač k tomu.

V tom pythonu mě to ale baví, je to tam tak pěkně udělané, schované a navenek pytnovské, že to vlastně ani dlouholetí vývojáří na první pohled nepoznají, neví, nevidí, že na pozadí není python.

Java má tu smůlu, že pouště z ní něco v C je dost nešikovné, takže se to nepoužívá tolik, ale někdy by to přišlo vhod.

Java má tu smůlu, že pouště z ní něco v C je dost nešikovné, takže se to nepoužívá tolik, ale někdy by to přišlo vhod.
Což se v posledních releases celkem mění. Java 22 má Foreign Function & Memory API https://openjdk.org/jeps/454 spolu s jextract https://github.com/openjdk/jextract

Prekvapí to možno ľudí, ktorí Python vôbec nepoznajú. Python bol ako glue jazyk vytváraný od prvopočiatku. GUI knižnice ako Tkinter, wxPython, PyQt, DB ovládače ako pycopg, Polars, numpy, OpenCV...

Tkinter bol dokonca wrapperom nad Tcl/Tk, čo že iný skriptovací jazyk. Dnes je to už ale binárka.

Niektoré z nich sú prevažne napísané v Pythone (Pandas, Matplotlib, Pytorch) ale majú kritické komponenty vytvorené v C/C++, a Python ich volá.

Ono sa to vždy takto riešilo, pretože autori si pochopiteľne uvedomovali, že Python ako skriptovací jazyk je príliš pomalý na grafiku, hry a komplexné výpočty.

Momentálne zrýchlujú aj čistý Python. Stále je to pomalé, ale už znesitelne. Sú za ním veľké firmy, ako Microsoft, Google, Red Hat, Meta a veľa peňazí. Uvidíme, kde to bude povedzme o rok.

Rýchlosť Pythonu nebola dlho priorita, na to jazyk neašpiroval. momentálne je to priorita.

..presne tak,..a na I/O stačí async/await, resp. "vlákna" ak uz sa inak nedá. Nechápem prečo tie tanecky s GILom stále..

Já jsem to jenom rychle přeletěl a neviděl jsem nikde ten Java kód - jestli by byl aspoň srovnatelný s tím, co dělal Php. Co použili za knihovny - třeba Jackson-csv byl podle mých měření asi dvakrát rychlejší než Apache commons-csv . Co se pak děje dál - konverze do nějakých nativních typů, parsování atd.

Kdysi jsem pracoval na projektu, který konzumoval externí data převážně v CSV. Před cca 10-ti lety vybrali Perl, bo měl nejlepší rychlost s regex (prakticky další krok za načtením CSV). Nedávno jsem dělal porovnání - Perl je stále rychlý na samotné parsování (nativní kód), ale Java je porovnatelná. Regex má Perl rychlejší, ale u Java se můžou lépe cachovat / připravit a navíc pro speciální konverze lze použít lepší přístup. Paralelizace je jednoznačně na straně Java. A ohledně dalších vrstev integrace bude Java už jednoznačná volba. Hlavní pointa je v tom, že doba parsování CSV obecně byla zanedbatelná část problému.

Co se týče statistik, Jackson-csv zvládal cca 1 M řádků za vteřinu (single thread, laptop 2020).

Je to "challenge" a s produkčními věcmi to nemá nic společného. Takže v té Javě pěkně ruční parsováníčko, a to dokonce bez použití floatu. Ve videu je to porovnávané s vítěznou implementací v Javě: https://github.com/gunnarmorling/1brc/blob/main/src/main/java/dev/morling/onebrc/CalculateAverage_thomaswue.java

P.S. Je snad jasné, že verze v Javě bude rychlejší, ne? :-D