Vlákno názorů k článku Užitečné balíčky pro každodenní použití Go (2), porovnání výkonnosti Go s céčkem od anonym - V C++ se da krasne skalovat pomoci OpenMP...

V C++ se da krasne skalovat pomoci OpenMP (#pragma omp parallel for schedule(static)) v nejvnejsejsi smycce.
Co je problem, ze to moc nefunguje s printfem(dokonce se to brutalne zpomali). Oplati se dokonce nasypat vysledky do alokovaneho pole a to pak seriove projit a vyblit ven. Vzdycky je ale output brutalne pomalej. Na mem systemu v 8 vlaknech samotny vypocet 4096x4096x255 trva cca 0.140s - kazde bliti vysledku udela minimalne 3.5s(serializuju nasypane pole).
Nevim, jestli se to vubec da na tom benchmarkovat, kdyz io dela takovy obrovsky rozdil.

Pozn.: data v poli opravdu jsou, vypocet se neodoptimalizo­vava... kontroloval jsem to nekolika vypisy z pole.

ulozit vypisy v prubehu smycek do bufferu a vyblit to ven mimo mereny casovy usek.
merit casy jen uvnitr smycek, ktere nic nevypisuji, aby kernel nedelal i/o jen cpu.

No on tenhle benchmark je prakticky stejnej jako benchmark "mandelbrot" z klasicky "The Computer Language Benchmarks Game". Konkretne reseni v C s pouzitim OpenMP je napriklad tady: https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-gcc-8.html

Dalsi reseni pro Go, Fortran atd se daji najit na ty samy strance.

Přesně tak, je to jen základní výpočet s floaty (ať se překladač vyřádí na optimalizacích tří vnořených smyček s podmínkou uvnitř) + miliony I/O operací.

Souhlasím s nulou že ten samotný výpočet mandelbrota se utopí v těch milionech IO operací, a do nemalé míry i v samotném printf formátování. Odkazovaný benchmark na benchmarksgame téměř žádný výstup nedělá, takže se naplno můžou projevit právě kvality optimalizací.

JJ a přesně proto jsou tam obě části, aby bylo vidět, jak se ovlivňují a že primitivní I/O v Go je v tomto ohledu limitující a výsledky úplně změní v neprospěch Go (i když opět říkám, že Go nedělá tak dobré optimalizace jako gcc a llvm). Můžeme si to samozřejmě přepsat naopak - načíst bitmapu s očekávaným výsledkem, potom provést výpočet a nakonec porovnat výsledek se vstupní bitmapou (to porovnání bude součástí benchmarku samozřejmě kvůli případným lazy výpočtům, načtení bude mimo).

Možná ještě doplním info, které jsem v článku nedopsal: ty výsledky jsou do posledního pixelu shodné, ovšem v C/C++ jde používat optimalizace typu --ffast-math apod., které dodají výsledky jiné, protože se přesně nedodrží IEEE 754. Proto tyto optimalizace v Makefile nejsou, naschvál samozřejmě.