I can’t imagine the app has 34 mb of code in the hot path where this would 
matter - so I assume the application is partitioned with various Go routines 
doing a “type” of work.

Which encounters a problem with the Go design. You can’t partition Go routines, 
and you can’t set cpu/core affinity for a Go routine.

So it can be very difficult to manage the cache (code & data) in a large 
multipurpose app, or an app where there data is naturally partitioned (e.g. a 
financial exchange where different stocks and asset classes are independent).

I didn’t look but I believe there is a FR/issue to address the above 
deficiencies.

> On Sep 18, 2021, at 8:26 PM, rmfr <remus.clearwa...@gmail.com> wrote:
> 
> I have tried to disable the inline during compiling, but it results in no big 
> difference.
> 
> On Saturday, September 18, 2021 at 9:26:45 PM UTC+8 ren...@ix.netcom.com 
> wrote:
> I will add that over aggressive inlining can cause this - it explodes the 
> binary size.
> 
> 
>> On Sep 18, 2021, at 7:37 AM, Jesper Louis Andersen <jesper.lou...@gmail.com 
>> <applewebdata://CCC69237-F973-4E2E-8E1E-20CE97269919>> wrote:
>> 
> 
>> On Fri, Sep 17, 2021 at 11:09 AM rmfr <remus.cl...@gmail.com 
>> <applewebdata://CCC69237-F973-4E2E-8E1E-20CE97269919>> 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 
>> <https://en.wikipedia.org/wiki/Profile-guided_optimization> and using 
>> hugepages to load the .text segment. But they are both seem very difficult 
>> to implement in Golang.
>> 
>> 
>> 
>> Shot in the dark: is the application running next to some other application 
>> on the hardware which wipes the TLB?
>> 
> 
>> -- 
>> 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...@googlegroups.com 
>> <applewebdata://CCC69237-F973-4E2E-8E1E-20CE97269919>.
> 
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAGrdgiWDY%2Bjh2%3DPzAatJU5Ckit0_maex%3DgGC3E4M-t8VB94Qig%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/CAGrdgiWDY%2Bjh2%3DPzAatJU5Ckit0_maex%3DgGC3E4M-t8VB94Qig%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> 
> 
> -- 
> 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 
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/7de12443-2916-4190-a08d-0825605f6ca5n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/7de12443-2916-4190-a08d-0825605f6ca5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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/03F9275B-85F4-4E25-992A-108BFE01FA83%40ix.netcom.com.

Reply via email to