Jedná se o microbenchmarky a tak je k tomu potřeba přistupovat. Vezměme třeba ten pro Go nejhorší, binary-tree.
Ve své podstatě se jedná o benchmark testující průchodnost GC. Tady je výtah z podmínek testu:
Use default GC, use per node allocation or use a library memory pool.
As a practical matter, the myriad ways to tune GC will not be accepted.
As a practical matter, the myriad ways to custom allocate memory will not be accepted.
Please don't implement your own custom "arena" or "memory pool" or "free list" - they will not be accepted.
To ve své podstatě značně diskvalifikuje jakýkoliv jazyk s GC. Jednoduchým nastavením GC zrychlíte tento test pro Go zhruba 2,3x. Ale toto není akceptováno. Co se potom poměřuje mi ale není jasné.
Díval jsem se na testy výkonosti jazyka Go a oproti C je dost pomalý. Samozřejmě je i pomalejší než Java nebo C#.
Možná se díváme na jiné testy, ale pokud myslíte benchmarksgame, nevidím, že by bylo Go samozřejmě pomalejší než Java nebo C#. Je srovnatelné a dokonce bych podle srovnání řekl v průměru i krapánek rychlejší.
http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest-firstlast.svgzA to nemluvíme o tom, že GC v Go je optimalizován pro latenci, což se v žádném benchmarku neprojeví a minimalizuje alokace na haldě, což se v těchto microbenchmarcích taky moc neprojeví.
A v neposlední řadě by stálo za to se podívat i na sloupeček mem. Java tam má 2,5-30x větší čísla než Go. (Nepsal tu někdo před nedávnem, že Java je stejně paměťově náročná, jako každý jiný jazyk?) No a C# je na tom v této kategorii ještě hůře než Java.
80 Odpovědí
27646 Zhlédnutí