Názory k článku Základní optimalizace v Go aneb pomáháme překladači

To předávání hodnotou může být často rychlejší, u malých struktur je kopie v rámci procesorové cache rychlá a člověk se často vyhne GC (data zůstanou na zásobníku). Akorát se to nikdy neví předem, jenže kdo se má furt psát z benchmarkama…

A pokiaľ vytváraš knižnicu, tak potom ako postupovať, ak má byť aj „Thread safety“?

s tim předávání hodnotou/odkazem vůbec nijak nepomůže, prostě nesdílet nic jiného než kanály (jo, lehko se to řekne, takže na atomicy a mutexy stejně jednou dojde).

"Don't communicate by sharing memory;
share memory by communicating."

Rob Pike

jj přesně tak, kde to jde vyřešit přes kanály, tak je to nejčistší řešení. My máme atomicy a mutexy vlastně jen v jedné službě, jeden z nejhůře testovatelných částí kódu .-)

v teto oblasti bohuzel bez benchmarku a profileru tezko odhadovat. Proste jsme SW engineering a ne computer science, kde si teoretici vystaci s asymptotickou slozitosti :-p

Knuth: "Beware of bugs in the above code; I have only proved it correct, not tried it." :)

najdu link, ale v nekterem dile golangweekly byl odkaz na zajimavy clanek, jak zvysili vykon jen tim, ze presunuli & na jine misto v kodu :-)

To by me zajimalo, protoze to asi je docela mozny :) Ten prekladac Go skutecne neni uplne to nejlepsi, co ve svete prekladacu vzniklo. Samozrejme Go bez problemu valcule jakykoli interpret, ale proste LLVM optimalizace nekdy chybi (zase na druhou stranu dokaze optimalizovat i na urovni linkeru, to je tusim mozna ne unikatni, ale ne zcela bezne).

golangweekly ma ted nejaky vypadek, ale myslim, ze ten odkaz na clanek nebyl v dile starsim, nez 3 dily zpet.

To je ošemetné, v reálných aplikacích, kde jsem dělal benchmarky, jsem většinou zjistil, že pomalost (částí) kódu nebývá často způsobená přímo kódem, ale něčím "externím". Třeba Rust se standardním alokátorem je šnek, ale člověk tam dá Mimalloc a najednou všechny válcuje. Go má alokátor optimalizovaný pro více vláken, takže test v rámci jednoho vlákna taky nedopadne oslnivě. Kromě alokátoru se často projeví runtime, třeba traity v Rustu jsou poměrně pomalé (dispatch na nich) a std::Any je úplně napikaču, kdežto typový switch v Go (a vůbec jeho typový runtime s asercemi apod.) je rychlý. Jó, kdybychom měli kód bez dynamické alokace paměti a bez dynamického dispatche, tak cokoliv založené na LLVM s přehledem vyhraje co do rychlosti (Rust, Julia), ale většina programů drhne jinde. (Na kód bez dynamické alokace paměti a bez dynamického dispatche ale zase stačí bohatě C).

s dynamickou alokaci souhlas, ale je fakt dynamicky dispatch takovy problem v realnych aplikacich? Treba v Go se to az tak moc neuzije ne?

Zrovna Go má docela dost rozhraní ve standardní knihovně, ale v Go je rychlý.

Nevím o žádné statistice, možná k němu v reálném světě fakt moc nedochází, to v Go nedokážu posoudit.

@Pavel Tišnovský
“To by me zajimalo, protoze to asi je docela mozny :)”

https://hmarr.com/blog/go-allocation-hunting/

8. 12. 2022, 15:51 editováno autorem komentáře

Díky!

Extrémem je psát tzv. zero-allocation code (jsou takové například loggery), kdysi jsem o tom viděl článek. To už tak triviální není.

jj pro Go je to například zerolog, ten (i přes některé podivnosti) používáme ke všeobecné spokojenosti. Taky v Kafce se snaží předávat reference kde to jde, takže na JVM-based nástroj je to až pekelně rychlé.

Tady je ten článek: https://medium.com/@muroon/the-reason-why-zap-and-zerolog-make-it-zero-allocation-3ee8f69f660?source=user_profile---------0----------------------------

Takže problém céčka (manuální alokace), kterou se Go snaží řešit přes GC a Rust přes ownership, se vlastně obejde? :-)

Jo, obejde, do určité míry. V Rustu se takto šaškovat nemusí, tam rozhoduje autor kódu, jestli bude instance na haldě, ale v Go na to nejsou garance a escape analýza funguje v každé verzi jinak.

V kontextu článku zajímavé je, že nová knihovna pro strukturované logování slog která míří do standardní knihovny (momentálně v balíčku experimental) vytváří nové struktury typu Record takto:

https://cs.opensource.google/go/x/exp/+/732eee02:slog/record.go;l=63-75;drc=732eee02a75a571a8347fdf60af8c8b9e3ca9254

func NewRecord(t time.Time, level Level, msg string, calldepth int, ctx context.Context) Record {
    // ...
    return Record{
        Time:    t,
        Message: msg,
        Level:   level,
        Context: ctx,
    }
}

Tady si nejsem jistý, jak to vlastně dopadne, není ukazatel takže teoreticky to kompilátor může ponechat na zásobníku i jako návratovou hodnotu ne? Samozřejmě kromě řetězce což je odkaz na heap.

Mimochodem, ja jaře 2023 má vyjít 1.20 s multi error wrappingem, námět na článek :-) https://lukas.zapletalovi.com/posts/2022/wrapping-multiple-errors/

Je to lepší než multierr Uberu?