Go 1.21: Vodič za optimizaciju profila

Početkom 2023. godine, otići 1.20 Nakon rješavanja poznatih ograničenja u pregledu i dodatnih poboljšanja zahvaljujući povratnim informacijama i doprinosima zajednice, PGO podrška u Go 1.21 je spremna za opću upotrebu u proizvodnji! Za potpunu dokumentaciju. Sljedeći članakProfil-guided optimization (PGO) Korisnički vodič za optimizaciju profila Proći ćemo kroz primjer korištenja PGO-a za poboljšanje performansi aplikacije. Prije nego što dođemo do toga, što je točno "optimizacija vodena profilom"? ispod Na primjer, stalna razmnožavanje može procijeniti konstantne izraze u vrijeme kompilacije, izbjegavajući troškove evaluacije vremena rada. Analiza izbjegavanja izbjegava gomilane raspodjele za objekte lokalno obuhvaćene, izbjegavajući GC nadglavlja. Inlining kopira tijelo jednostavnih funkcija u pozivače, često omogućujući daljnju optimizaciju u pozivaču (kao što je dodatna stalna razmnožavanje ili bolja analiza izbjegavanja). Devirtualization pretvara neizravne pozive na interfejsne vrijednosti čiji se tip može statički odrediti u izravne pozive na konkretnu metodu (što često omogućuje inlining poziva). Go poboljšava optimizacije od izdanja do izdanja, ali to nije lak zadatak. Neke optimizacije su prilagodljive, ali kompilator ne može jednostavno "pretvoriti do 11" na svakoj optimizaciji jer pretjerano agresivne optimizacije zapravo mogu povrijediti performanse ili uzrokovati prekomjerno vrijeme izgradnje. Druge optimizacije zahtijevaju da kompilator donese presudu o tome što su "obični" i "neobični" putevi u funkciji. Ili to može? Bez konačnih informacija o tome kako se kod koristi u proizvodnom okruženju, kompilator može raditi samo na izvornom kodu paketa. Ako kompilatoru pružimo profil, može donijeti informiraniju odluku: agresivnije optimizirati najčešće korištene funkcije ili preciznije odabrati uobičajene slučajeve. Profiliranje Korištenje profila ponašanja aplikacija za optimizaciju kompilera poznato je kao (Također poznato kao optimizacija usmjerena na povratne informacije (FDO)). Optimizacija pod vodstvom profila (PGO) Primjer Napravimo uslugu koja pretvara Markdown u HTML: korisnici preuzimaju izvor Markdown na , koji vraća HTML konverziju. možemo koristiti Da se to jednostavno provede. /render gitlab.com/golang-commonmark/markdown postaviti $ go mod init example.com/markdown $ go get gitlab.com/golang-commonmark/markdown@bf3e522c626a U : main.go package main

import ( "bytes" "io" "log" "net/http" _ "net/http/pprof"

"gitlab.com/golang-commonmark/markdown" )

func render(w http.ResponseWriter, r *http.Request) { if r.Method != "POST" { http.Error(w, "Only POST allowed", http.StatusMethodNotAllowed) return }

src, err := io.ReadAll(r.Body) if err != nil { log.Printf("error reading body: %v", err) http.Error(w, "Internal Server Error", http.StatusInternalServerError) return }

md := markdown.New( markdown.XHTMLOutput(true), markdown.Typographer(true), markdown.Linkify(true), markdown.Tables(true), )

var buf bytes.Buffer if err := md.Render(&buf, src); err != nil { log.Printf("error converting markdown: %v", err) http.Error(w, "Malformed markdown", http.StatusBadRequest) return }

if _, err := io.Copy(w, &buf); err != nil { log.Printf("error writing response: %v", err) http.Error(w, "Internal Server Error", http.StatusInternalServerError) return } }

func main() { http.HandleFunc("/render", render) log.Printf("Serving on port 8080...") log.Fatal(http.ListenAndServe(":8080", nil)) } Izgradnja i pokretanje servera: $ go build -o markdown.nopgo.exe $ ./markdown.nopgo.exe 2023/08/23 03:55:51 Serving on port 8080... Pokušajmo poslati neki Markdown iz drugog terminala. iz projekta Go kao uzorak dokumenta: README.md $ curl -o README.md -L "https://raw.githubusercontent.com/golang/go/c16c2c49e2fa98ae551fc6335215fadd62d33542/README.md" $ curl --data-binary @README.md http://localhost:8080/render The Go Programming Language Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

... Profiliranje Sada kada imamo radnu uslugu, hajde da prikupimo profil i rekonstruiramo s PGO-om kako bismo vidjeli možemo li postići bolje rezultate. U Uvozili smo Automatski se dodaje a Posjetite server za preuzimanje CPU profila. main.go Internet / HTTP / PPP /debug/pprof/profile Obično želite prikupiti profil iz proizvodnog okruženja kako bi kompilator dobio reprezentativan pogled na ponašanje u proizvodnji. za generiranje opterećenja dok prikupljamo profil. Fetch i pokrenite generator opterećenja (ovjerite se da je server još uvijek u tijeku!): Jednostavni program $ go run github.com/prattmic/markdown-pgo/load@latest Dok to radi, preuzmite profil s poslužitelja: $ curl -o cpu.pprof "http://localhost:8080/debug/pprof/profile?seconds=30" Nakon što se to završi, ubijte generator opterećenja i poslužitelj. Koristeći profil Go toolchain će automatski omogućiti PGO kada pronađe profil pod imenom u glavnom adresaru paketa. Alternativno, Zastava 2 uzima put do profila za korištenje za PGO. default.pgo -pgo go build Preporučujemo preuzimanje Skladištenje profila uz izvorni kod osigurava da korisnici automatski imaju pristup profilu jednostavno preuzimanjem repozitorija (ili putem sustava kontrole verzija, ili putem (a te građevine ostaju reproduktivne. default.pgo go get Hajde da gradimo: $ mv cpu.pprof default.pgo $ go build -o markdown.withpgo.exe Možemo provjeriti je li PGO bio uključen u izgradnju s : go version $ go version -m markdown.withpgo.exe ./markdown.withpgo.exe: go1.21.0 ... build -pgo=/tmp/pgo121/default.pgo evaluacija Mi ćemo koristiti Go benchmark kako bi se procijenio učinak PGO-a na performanse. Sljedeći Članak Load Generator Prvo ćemo usporediti server bez PGO-a. $ ./markdown.nopgo.exe Dok to radi, pokrenite nekoliko iteracija referentnih točaka: $ go get github.com/prattmic/markdown-pgo@latest $ go test github.com/prattmic/markdown-pgo/load -bench=. -count=40 -source $(pwd)/README.md > nopgo.txt Nakon što se to završi, ubijte izvorni server i pokrenite verziju s PGO-om: $ ./markdown.withpgo.exe Dok to radi, pokrenite nekoliko iteracija referentnih točaka: $ go test github.com/prattmic/markdown-pgo/load -bench=. -count=40 -source $(pwd)/README.md > withpgo.txt Nakon što se to završi, uspoređujmo rezultate: $ go install golang.org/x/perf/cmd/benchstat@latest $ benchstat nopgo.txt withpgo.txt goos: linux goarch: amd64 pkg: github.com/prattmic/markdown-pgo/load cpu: Intel(R) Xeon(R) W-2135 CPU @ 3.70GHz │ nopgo.txt │ withpgo.txt │ │ sec/op │ sec/op vs base │ Load-12 374.5µ ± 1% 360.2µ ± 0% -3.83% (p=0.000 n=40) Nova verzija je oko 3,8% brža! U Go 1.21, radna opterećenja obično dobivaju između 2% i 7% poboljšanja u korištenju CPU-a od omogućavanja PGO-a. Profili sadrže obilje informacija o ponašanju aplikacija i Go 1.21 tek počinje pucati površinu koristeći ove informacije za ograničen skup optimizacija. Buduća izdanja nastavit će poboljšavati performanse jer više dijelova kompilatora koristi PGO. Sljedeći koraci U ovom primjeru, nakon prikupljanja profila, obnovili smo naš poslužitelj pomoću istog izvornog koda koji se koristi u originalnoj izgradnji. U scenariju u stvarnom svijetu, uvijek je u tijeku razvoj. Tako da možemo prikupiti profil iz proizvodnje, koji radi kod prošlog tjedna, i koristiti ga za izgradnju s današnjim izvornim kodom. To je savršeno u redu! PGO u Go može upravljati manjim promjenama izvornog koda bez problema. Za mnogo više informacija o korištenju PGO, najbolje prakse i upozorenja biti svjesni, molimo pogledajte Ako ste znatiželjni o tome što se događa ispod poklopca, nastavite čitati! Korisnički vodič za optimizaciju profila Pod Hoodom Da bismo bolje razumjeli što je ovu aplikaciju učinilo bržom, pogledajmo ispod poklopca kako bi vidjeli kako se performanse promijenile. Inliniranje Da biste promatrali poboljšanja u liniji, analizirajte ovu aplikaciju s PGO-om i bez njega. Usporedit ću to pomoću tehnike koja se naziva diferencijalno profiliranje, gdje prikupljamo dva profila (jedan s PGO-om i jedan bez njega) i uspoređujemo ih. , ne istu količinu vremena, pa sam prilagodio poslužitelj da automatski prikuplja profile, a generator opterećenja da pošalje fiksni broj zahtjeva, a zatim napusti poslužitelj. work Promjene koje sam napravio na poslužitelju, kao i prikupljeni profili mogu se naći na Generator opterećenja je pokrenut s . https://github.com/prattmic/markdown-pgo -count=300000 -quit Kao brzu provjeru dosljednosti, pogledajmo ukupno vrijeme CPU-a potrebno za obradu svih 300k zahtjeva: $ go tool pprof -top cpu.nopgo.pprof | grep "Total samples" Duration: 116.92s, Total samples = 118.73s (101.55%) $ go tool pprof -top cpu.withpgo.pprof | grep "Total samples" Duration: 113.91s, Total samples = 115.03s (100.99%) CPU vrijeme je pala s ~118s na ~115s, ili oko 3%. To je u skladu s našim referentnim rezultatima, što je dobar znak da su ti profili reprezentativni. Sada možemo otvoriti diferencijalni profil kako bismo potražili uštede: $ go tool pprof -diff_base cpu.nopgo.pprof cpu.withpgo.pprof File: markdown.profile.withpgo.exe Type: cpu Time: Aug 28, 2023 at 10:26pm (EDT) Duration: 230.82s, Total samples = 118.73s (51.44%) Entering interactive mode (type "help" for commands, "o" for options) (pprof) top -cum Showing nodes accounting for -0.10s, 0.084% of 118.73s total Dropped 268 nodes (cum <= 0.59s) Showing top 10 nodes out of 668 flat flat% sum% cum cum% -0.03s 0.025% 0.025% -2.56s 2.16% gitlab.com/golang-commonmark/markdown.ruleLinkify 0.04s 0.034% 0.0084% -2.19s 1.84% net/http.(*conn).serve 0.02s 0.017% 0.025% -1.82s 1.53% gitlab.com/golang-commonmark/markdown.(*Markdown).Render 0.02s 0.017% 0.042% -1.80s 1.52% gitlab.com/golang-commonmark/markdown.(*Markdown).Parse -0.03s 0.025% 0.017% -1.71s 1.44% runtime.mallocgc -0.07s 0.059% 0.042% -1.62s 1.36% net/http.(*ServeMux).ServeHTTP 0.04s 0.034% 0.0084% -1.58s 1.33% net/http.serverHandler.ServeHTTP -0.01s 0.0084% 0.017% -1.57s 1.32% main.render 0.01s 0.0084% 0.0084% -1.56s 1.31% net/http.HandlerFunc.ServeHTTP -0.09s 0.076% 0.084% -1.25s 1.05% runtime.newobject (pprof) top Showing nodes accounting for -1.41s, 1.19% of 118.73s total Dropped 268 nodes (cum <= 0.59s) Showing top 10 nodes out of 668 flat flat% sum% cum cum% -0.46s 0.39% 0.39% -0.91s 0.77% runtime.scanobject -0.40s 0.34% 0.72% -0.40s 0.34% runtime.nextFreeFast (inline) 0.36s 0.3% 0.42% 0.36s 0.3% gitlab.com/golang-commonmark/markdown.performReplacements -0.35s 0.29% 0.72% -0.37s 0.31% runtime.writeHeapBits.flush 0.32s 0.27% 0.45% 0.67s 0.56% gitlab.com/golang-commonmark/markdown.ruleReplacements -0.31s 0.26% 0.71% -0.29s 0.24% runtime.writeHeapBits.write -0.30s 0.25% 0.96% -0.37s 0.31% runtime.deductAssistCredit 0.29s 0.24% 0.72% 0.10s 0.084% gitlab.com/golang-commonmark/markdown.ruleText -0.29s 0.24% 0.96% -0.29s 0.24% runtime.(*mspan).base (inline) -0.27s 0.23% 1.19% -0.42s 0.35% bytes.(*Buffer).WriteRune Kada se specifično , vrijednosti u prikazanim u pprof su Na primjer, između dva profila. koristio 0,46s manje CPU vrijeme s PGO nego bez. Sljedeći članakKako se riješiti problema sa štitnjačom: Kako se riješiti problema sa štitnjačom? i kolumne), jer postotak nije bitan. pprof -diff_base Razlika runtime.scanobject gitlab.com/golang-commonmark/markdown.performReplacements flat cum prikazuje glavne razlike kumulativnom promjenom. To jest, razlika u CPU-u funkcije i svih tranzicijskih ulica od te funkcije. Ovo će općenito prikazati najudaljenije okvire u grafu poziva našeg programa, kao što su: ili još jednu goroutinsku ulaznu točku. Ovdje možemo vidjeti da većina ušteda dolazi iz Upravljanje HTTP zahtjevima. top -cum main ruleLinkify prikazuje glavne razlike ograničene samo na promjene u samoj funkciji. To će općenito prikazati unutarnje okvire u grafiku poziva našeg programa, gdje se većina stvarnog rada događa. Funkcije su. top runtime Pogledajmo stack poziva kako bi vidjeli odakle dolaze: (pprof) peek scanobject$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.86s 94.51% | runtime.gcDrain -0.09s 9.89% | runtime.gcDrainN 0.04s 4.40% | runtime.markrootSpans -0.46s 0.39% 0.39% -0.91s 0.77% | runtime.scanobject -0.19s 20.88% | runtime.greyobject -0.13s 14.29% | runtime.heapBits.nextFast (inline) -0.08s 8.79% | runtime.heapBits.next -0.08s 8.79% | runtime.spanOfUnchecked (inline) 0.04s 4.40% | runtime.heapBitsForAddr -0.01s 1.10% | runtime.findObject ----------------------------------------------------------+------------- (pprof) peek gcDrain$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -1s 100% | runtime.gcBgMarkWorker.func2 0.15s 0.13% 0.13% -1s 0.84% | runtime.gcDrain -0.86s 86.00% | runtime.scanobject -0.18s 18.00% | runtime.(*gcWork).balance -0.11s 11.00% | runtime.(*gcWork).tryGet 0.09s 9.00% | runtime.pollWork -0.03s 3.00% | runtime.(*gcWork).tryGetFast (inline) -0.03s 3.00% | runtime.markroot -0.02s 2.00% | runtime.wbBufFlush 0.01s 1.00% | runtime/internal/atomic.(*Bool).Load (inline) -0.01s 1.00% | runtime.gcFlushBgCredit -0.01s 1.00% | runtime/internal/atomic.(*Int64).Add (inline) ----------------------------------------------------------+------------- tako Naposljetku dolazi iz • The Reci nam da To je dio kolektora smeća, tako da Ušteda mora biti GC ušteda. i drugi Njihove funkcije? runtime.scanobject runtime.gcBgMarkWorker Go GC vodič runtime.gcBgMarkWorker runtime.scanobject nextFreeFast runtime (pprof) peek nextFreeFast$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.40s 100% | runtime.mallocgc (inline) -0.40s 0.34% 0.34% -0.40s 0.34% | runtime.nextFreeFast ----------------------------------------------------------+------------- (pprof) peek writeHeapBits Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.37s 100% | runtime.heapBitsSetType 0 0% | runtime.(*mspan).initHeapBits -0.35s 0.29% 0.29% -0.37s 0.31% | runtime.writeHeapBits.flush -0.02s 5.41% | runtime.arenaIndex (inline) ----------------------------------------------------------+------------- -0.29s 100% | runtime.heapBitsSetType -0.31s 0.26% 0.56% -0.29s 0.24% | runtime.writeHeapBits.write 0.02s 6.90% | runtime.arenaIndex (inline) ----------------------------------------------------------+------------- (pprof) peek heapBitsSetType$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.82s 100% | runtime.mallocgc -0.12s 0.1% 0.1% -0.82s 0.69% | runtime.heapBitsSetType -0.37s 45.12% | runtime.writeHeapBits.flush -0.29s 35.37% | runtime.writeHeapBits.write -0.03s 3.66% | runtime.readUintptr (inline) -0.01s 1.22% | runtime.writeHeapBitsForAddr (inline) ----------------------------------------------------------+------------- (pprof) peek deductAssistCredit$ Showing nodes accounting for -3.72s, 3.13% of 118.73s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -0.37s 100% | runtime.mallocgc -0.30s 0.25% 0.25% -0.37s 0.31% | runtime.deductAssistCredit -0.07s 18.92% | runtime.gcAssistAlloc ----------------------------------------------------------+------------- Izgleda kao i neki od ostalih u top 10 konačno dolaze iz , što nam GC vodič govori je alokator memorije. nextFreeFast runtime.mallocgc Smanjeni troškovi u GC-u i alokatoru podrazumijevaju da dodjeljujemo manje u cjelini. $ go tool pprof -sample_index=alloc_objects -diff_base heap.nopgo.pprof heap.withpgo.pprof File: markdown.profile.withpgo.exe Type: alloc_objects Time: Aug 28, 2023 at 10:28pm (EDT) Entering interactive mode (type "help" for commands, "o" for options) (pprof) top Showing nodes accounting for -12044903, 8.29% of 145309950 total Dropped 60 nodes (cum <= 726549) Showing top 10 nodes out of 58 flat flat% sum% cum cum% -4974135 3.42% 3.42% -4974135 3.42% gitlab.com/golang-commonmark/mdurl.Parse -4249044 2.92% 6.35% -4249044 2.92% gitlab.com/golang-commonmark/mdurl.(*URL).String -901135 0.62% 6.97% -977596 0.67% gitlab.com/golang-commonmark/puny.mapLabels -653998 0.45% 7.42% -482491 0.33% gitlab.com/golang-commonmark/markdown.(*StateInline).PushPending -557073 0.38% 7.80% -557073 0.38% gitlab.com/golang-commonmark/linkify.Links -557073 0.38% 8.18% -557073 0.38% strings.genSplit -436919 0.3% 8.48% -232152 0.16% gitlab.com/golang-commonmark/markdown.(*StateBlock).Lines -408617 0.28% 8.77% -408617 0.28% net/textproto.readMIMEHeader 401432 0.28% 8.49% 499610 0.34% bytes.(*Buffer).grow 291659 0.2% 8.29% 291659 0.2% bytes.(*Buffer).String (inline) Naš Opcija nam pokazuje broj raspodjela, bez obzira na veličinu. Ovo je korisno jer istražujemo smanjenje upotrebe CPU-a, što ima tendenciju da se više korelira s brojem raspodjela nego veličinom. . -sample_index=alloc_objects mdurl.Parse Za referencu, pogledajmo ukupne brojeve raspodjele za ovu funkciju bez PGO-a: $ go tool pprof -sample_index=alloc_objects -top heap.nopgo.pprof | grep mdurl.Parse 4974135 3.42% 68.60% 4974135 3.42% gitlab.com/golang-commonmark/mdurl.Parse Ukupni broj prije bio je 4974135, što znači da Uklonili smo 100 posto odobrenih sredstava! mdurl.Parse Povratak u diferencijalni profil, prikupimo malo više konteksta: (pprof) peek mdurl.Parse Showing nodes accounting for -12257184, 8.44% of 145309950 total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- -2956806 59.44% | gitlab.com/golang-commonmark/markdown.normalizeLink -2017329 40.56% | gitlab.com/golang-commonmark/markdown.normalizeLinkText -4974135 3.42% 3.42% -4974135 3.42% | gitlab.com/golang-commonmark/mdurl.Parse ----------------------------------------------------------+------------- Pozivi na Dolaze iz i . mdurl.Parse markdown.normalizeLink markdown.normalizeLinkText (pprof) list mdurl.Parse Total: 145309950 ROUTINE ======================== gitlab.com/golang-commonmark/mdurl.Parse in /usr/local/google/home/mpratt/go/pkg/mod/gitlab.com/golang-commonmark/mdurl@v0.0.0-20191124015652-932350d1cb84/parse .go -4974135 -4974135 (flat, cum) 3.42% of Total . . 60:func Parse(rawurl string) (*URL, error) { . . 61: n, err := findScheme(rawurl) . . 62: if err != nil { . . 63: return nil, err . . 64: } . . 65: -4974135 -4974135 66: var url URL . . 67: rest := rawurl . . 68: hostless := false . . 69: if n > 0 { . . 70: url.RawScheme = rest[:n] . . 71: url.Scheme, rest = strings.ToLower(rest[:n]), rest[n+1:] Cijeli izvor za ove funkcije i pozivače može se naći na: Sljedeći članakParse Markdown.normalizeLink Poveznica Markdown.normalizirajLinkTekst Što se ovdje događa? u ne-PGO izgradnji, smatra se prevelikim da bi bio prihvatljiv za inline. međutim, budući da je naš PGO profil ukazivao na to da su pozivi na ovu funkciju bili vrući, kompilator ih je inline. mdurl.Parse $ go tool pprof -top cpu.nopgo.pprof | grep mdurl.Parse 0.36s 0.3% 63.76% 2.75s 2.32% gitlab.com/golang-commonmark/mdurl.Parse $ go tool pprof -top cpu.withpgo.pprof | grep mdurl.Parse 0.55s 0.48% 58.12% 2.03s 1.76% gitlab.com/golang-commonmark/mdurl.Parse (inline) Stvaranje A kao lokalna varijabilna na liniji 66 ( ), a zatim vraća kazaljku na tu varijantu na liniji 145 ( Obično to zahtijeva da se promjenjiva dodijeli na gomilu, kao referencu na to da živi izvan funkcije povratka. Uključen je u , kompilator može promatrati da varijabla ne pobjegne , što kompilatoru omogućuje da ga dodijeli na stack. Sličan je . mdurl.Parse URL var url URL return &url, nil mdurl.Parse markdown.normalizeLink normalizeLink markdown.normalizeLinkText markdown.normalizeLink Drugo najveće smanjenje prikazano u profilu, od To je sličan slučaj uklanjanja bijega nakon inline. mdurl.(*URL).String U tim slučajevima, poboljšali smo performanse zahvaljujući manjem broju skupnih raspodjela.Djelomična snaga PGO-a i optimizacije kompilera općenito je u tome što učinci na raspodjele uopće nisu dio implementacije PGO-a kompilera. Svi učinci za analizu izbjegavanja i raspodjelu gomile bili su standardne optimizacije koje se primjenjuju na bilo koju konstrukciju. Poboljšano ponašanje izbjegavanja je veliki downstream učinak inlininga, ali to nije jedini učinak. Mnoge optimizacije mogu iskoristiti inlining. Na primjer, konstantno širenje može biti u stanju pojednostaviti kod u funkciji nakon inlininga kada su neki ulazi konstantni. Devirtualizam Pored inlinga, koji smo vidjeli u gornjem primjeru, PGO također može pokrenuti uvjetnu devirtualiziranje poziva na sučelje. Prije nego što dođemo do PGO-vodene devirtualization, vratimo se natrag i definirati "devirtualization" općenito. f, _ := os.Open("foo.txt") var r io.Reader = f r.Read(b) Ovdje imamo poziv na Interfejs metoda Budući da su interfejsi mogu imati više implementacija, kompilator generira funkcija poziva, što znači da traži ispravnu metodu za pozivanje na vrijeme pokretanja od tipa u vrijednosti sučelja. indirektni pozivi imaju mali dodatni trošak vremena pokretanja u usporedbi s izravnim pozivima, ali što je još važnije, oni isključuju neke optimizacije kompilatora. io.Reader Read neizravno U gornjem primjeru, mi Saznajte kakav je to konkretan način djelovanja, to mora biti Od tada To je jedini način na koji se može dodijeliti U tom slučaju kompilator će izvršiti , gdje zamjenjuje neizravni poziv na U izravnom pozivu na To omogućuje i druge optimizacije. do os.(*File).Read *os.File r Devirtualizam io.Reader.Read os.(*File).Read (Vjerojatno mislite: "Taj kod je beskoristan, zašto bi ga netko napisao na taj način?"To je dobra točka, ali imajte na umu da kod poput gore može biti rezultat uvrštenja. Prebačen je u funkciju koja uključuje Nakon što je funkcija upotrijebljena, sada To postaje konkretno.) f io.Reader io.Reader PGO-driven devirtualization proširuje ovaj koncept na situacije u kojima betonski tip nije statički poznat, ali profiliranje može pokazati da, na primjer, Pozivni ciljevi većinu vremena. u ovom slučaju, PGO može zamijeniti S nečim poput: io.Reader.Read os.(*File).Read r.Read(b) if f, ok := r.(*os.File); ok { f.Read(b) } else { r.Read(b) } That is, we add a runtime check for the concrete type that is most likely to appear, and if so use a concrete call, or otherwise fall back to the standard indirect call. The advantage here is that the common path (using Može se uvrstiti i primijeniti dodatne optimizacije, ali mi još uvijek održavamo povratni put jer profil nije jamstvo da će to uvijek biti slučaj. *os.File U našoj analizi markdown servera nismo vidjeli PGO-drivenu devirtualizaciju, ali smo također pogledali samo najugroženija područja. PGO (i većina kompilatorskih optimizacije) općenito donose svoju korist u agregatu vrlo malih poboljšanja na mnogo različitih mjesta, tako da se vjerojatno događa više nego samo ono što smo pogledali. Inlining i devirtualization su dvije optimizacije zasnovane na PGO-u dostupne u Go 1.21, ali kao što smo vidjeli, često otvaraju dodatne optimizacije. Priznanja Dodavanje optimizacije pod vodstvom profila Go-u bio je timski napor, a ja svakako želim istaknuti doprinose Raj Barika i Jin Lin u Uberu, te Cherry Mui i Austin Clements u Googleu. Michael Pratt Ovaj članak je dostupan na The Go Blogu pod licencom CC BY 4.0 DEED. Blog o odlasku Blog o odlasku Fotografija: Ben Sweet na Unsplashu Ben Slatko Unsplash

Go 1.21: Vodič za optimizaciju profila

About Author

KOMENTARI

VIJESI OZNAKE

OVAJ ČLANAK JE PREDSTAVLJEN U

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps