This is the icache or code - not the data the code is accessing. > On Sep 17, 2021, at 8:12 AM, peterGo <go.peter...@gmail.com> wrote: > > > rmfr, > > What is your data, what is its structure, and what are the access paths and > frequencies? > > Your data is unlikely to be a randomly accessed blob of bits. Is there a set > of Pareto access paths that you can use to order your data by access > frequency? You want the most frequently accessed data to be adjacent. > > Peter > >> On Friday, September 17, 2021 at 5:09:32 AM UTC-4 rmfr wrote: >> One of our Golang applications has a very huge binary size and the size of >> the .text segment itself in the elf is approximately 34MB. The iTLB load >> miss reaches about 87% of all iTLB cache hits. >> >> Is there any advice for big Golang applications to reduce the iTLB cache >> miss? Two solutions come to me, PGO and using hugepages to load the .text >> segment. But they are both seem very difficult to implement in Golang. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/1778bb58-e2e1-4bba-a869-1effb1e3952an%40googlegroups.com.
-- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/75B195E6-F6BE-466D-A7FB-514EBADFB659%40ix.netcom.com.
