Vlákno názorů k článku Programovací jazyk Go a assembler (2.část) od MSBOSS - Já tomu asi nějak nerozumím. Nejprve se vytvoří...

Já tomu asi nějak nerozumím. Nejprve se vytvoří jazyk Go s tím, že je to jednodušší než C, má to garbage collector, bezpečnější alokování paměti a obecně práci s pamětí, vyšší míru abstrakce... a pak se tam narve assembler. Když se podívám, že Go kompilátor umí kompilovat jen pro AMD64 + IA-32 a pro ostatní platformy spoléhá na gccgo, tak si říkám, k čemu ten jazyk vlastně je. Takhle mi to připadá, že se v podstatě akorát znovuvynalézá kolo místo toho, aby se raději třeba udělala nějaká práce přímo na GCC, což by bylo pro všechny mnohem užitečnější.

K tomu překladači: podívej se znovu a pořádně.

Já to chápu tak, že právě tím, že se jedná o jazyk s vyšší mírou abstrakce (nad nějakým obecným CPU, který je v případě Go konkrétnější, než v C), tak se ztrácí vyjadřovací schopnosti pro nízkoúrovňové operace. Tím trpí prakticky všechny vyšší programovací jazyky, protože "semantical gap" mezi assemblerem a jakýmkoli vyšším jazykem je obrovská (snad nikde v žebříčku jazyků není větší). Řeší se to různě - nějakými intrinsic popř. možností přejít do assembleru, ZA PŘEDPOKLADU, že je to nutné pro vyřešení problému (například potřebuji extra dobrý výkon při SIMD operacích).

Konkrétně v samotné základní knihovně Go je assembler použit jen tam, kde je to prakticky nezbytné:
1) věci okolo CPUID
2) balíček crypto (různé bitové posuny, rotace, masky, interleave, speciální crypto instrukce)
3) balíček hash (dtto)
4) samozřejmě math
5) bytes - pěkná je například funkce equal, která má uvnitř smyčku, kde se v každé iteraci porovná celých 64 bajtů (na AMD64)

Kde bych assembler použil dnes já, kdyby bylo vyžadováno (jako že na našem projektu není):
1) vše okolo SIMD operací (SSE1-4, AVX, ...)
2) možná kdyby bylo skutečně nutné si nějak hrát s bitíky (FFT?, ale to už určitě někdo v asm. pro Go napsal)