"výsledkem by měly být rychlé a paměťově efektivní aplikace (alespoň teoreticky) srovnatelné s výsledky, které jsou produkované překladači jazyků C, C++, D či Rust"
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-go.html
Přesně tak, proto píšu teoreticky. V praxi je tam jeden problém: standardní Go dnes staví na vlastním překladači (protože se Go bootstrapuje), i když tedy existuje i gccgo. IMHO by bylo zajímavější ty benchmarky postavit na Go používajícím backend LLVM (llgo), protože v případě Go skutečně nejsou teoretické důvody, aby binárky byly pomalejší, zvláště u tak primitivních benchmarků, kde se GC ani nemusí projevit.
Go by mohlo být stejně rychle jako C/C++/Rust, pokud by mělo dokonalou escape analysis. Pokud se překladači nepodaří zjistit, že by proměnná mohla být na stacku a vytvoří ji zbytečně na heapu, je to velká režie navíc. Podle všeho má Go jen nějakou základní escape analysis: https://golang.org/doc/faq#stack_or_heap
Jj přesně tak. Právě proto si myslím, že by Go mohl pomoci ten překladač pro LLVM. Protože komunita okolo LLVM dokázala, že ví jak na to. Část o alokaci proměnných mám zatím rozpracovanou, ale oni se snaží cpát lokální proměnné na zásobníkové rámce, což by mělo pomoci právě v benchmarcích (klasika - počitadlo smyček, index do pole atd.).
Možná bys jim měl jít poradit jak na to. Tady je to samej erudovanej pseudovyvojar který hodnoti jazyk podle benchmarku. :)) Ti co uz neco napsali hodnotí i podle jinych kriterii jako produktivita, prenositelnost, citelnost, apod a tam přichází na scénu kompromisy. V realne aplikaci to visi na jinych operacich nez regexu, binarnich stromech. Doporucuju napr clanek od Roba Pika týkající se regexu. Je to mnohem komplikovanejsi a je to znovu o kompromisech. Lide co za go stoji zaklady zvladaji. Ver mi.
Ne, netýkalo. Jen jsem popletl autora. Už je to nějaký pátek co jsem to četl. Byl to Russ Cox. https://swtch.com/~rsc/regexp/regexp3.html