[go-nuts] Re: A Question about `unsafe.Slice`

for p to be a pointer to the current goroutine's stack. // Since p is a uintptr, it would not be adjusted if the stack were to move. //go:nosplit func findObject(p, refBase, refOff uintptr) (base uintptr, s *mspan, objIndex uintptr) ``` On Sunday, February 6, 2022 at 10:33:35 AM UTC+8 rmfr wrote

[go-nuts] Re: A Question about `unsafe.Slice`

interval was provided? So now I tend to believe that `Element1` is correct too, and the `underlyBuf` filed in `Element2` is redundant and is not quite necessary, am I correct? On Sunday, February 6, 2022 at 10:08:06 AM UTC+8 rmfr wrote: > Please take a look at the following code: > > ```go

[go-nuts] A Question about `unsafe.Slice`

Please take a look at the following code: ```go package main import ( "fmt" "runtime" "unsafe" ) func assert(b bool) { if b { } else { panic("unexpected") } } type Elementer interface { GetInt64Slice() []int64 GetByteSlice() []byte String() string }

Re: [go-nuts] The right way for golang binary to reduce iTLB cache miss

, at 7:37 AM, Jesper Louis Andersen < > jesper.lou...@gmail.com> wrote: > > On Fri, Sep 17, 2021 at 11:09 AM 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*

Re: [go-nuts] The right way for golang binary to reduce iTLB cache miss

The problem is this application is a quite big Golang project. It has about 500, 000 lines of Golang codes and didn't even count these required 3-rd party libraries. On Sunday, September 19, 2021 at 8:47:44 AM UTC+8 rmfr wrote: > One of our Golang applications has a very huge binary s

Re: [go-nuts] The right way for golang binary to reduce iTLB cache miss

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

Re: [go-nuts] Re: The right way for golang binary to reduce iTLB cache miss

ocs` option. I also tried libhugetlbfs, but it seems could not be applied to Golang. On Friday, September 17, 2021 at 9:34:52 PM UTC+8 ren...@ix.netcom.com wrote: > This is the icache or code - not the data the code is accessing. > > On Sep 17, 2021, at 8:12 AM, peterGo wrote: > >

[go-nuts] The right way for golang binary to reduce iTLB cache miss

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

Re: [go-nuts] What happens if Golang calls a shared .so library via cgo but this library is built from Golang?

rday, August 21, 2021 at 3:00:35 AM UTC+8 Ian Lance Taylor wrote: > On Thu, Aug 19, 2021 at 7:30 PM rmfr wrote: > > > > Thanks a lot, Ian :-) > > > > > Assuming you are running on an ELF system and control symbol > > visibility, this can work. > >

Re: [go-nuts] What happens if Golang calls a shared .so library via cgo but this library is built from Golang?

> Perhaps what you're trying to achieve can be done using Go Plugins instead, although beware of significant restrictions: Thanks Brian, I have looked at it, but I am afraid its usage conditions are too strict. On Friday, August 20, 2021 at 4:10:24 PM UTC+8 Brian

Re: [go-nuts] What happens if Golang calls a shared .so library via cgo but this library is built from Golang?

Golang runtime in future updates? On Friday, August 20, 2021 at 3:19:22 AM UTC+8 Ian Lance Taylor wrote: > On Thu, Aug 19, 2021 at 6:34 AM rmfr wrote: > > > > As the title describes, does this is allowed by the Golang's design? If > it is allowed, I think there would be at

[go-nuts] Re: What happens if Golang calls a shared .so library via cgo but this library is built from Golang?

I just test go1.17 call go1.16.6's application shared library, it works (one binary dumps two different golang's runtime version): ``` Go version: go1.16.6 Go version: go1.17 ``` On Thursday, August 19, 2021 at 9:36:43 PM UTC+8 rmfr wrote: > Please also consider what happens if this two Gol

[go-nuts] Re: What happens if Golang calls a shared .so library via cgo but this library is built from Golang?

I just test go1.17 call go1.16.6's application shared library, it works (one binary dumps two different golang's runtime version): ``` ha! Go version: go1.16.6 Go version: go1.17 ``` On Thursday, August 19, 2021 at 9:36:43 PM UTC+8 rmfr wrote: > Please also consider what happens if this

[go-nuts] Re: What happens if Golang calls a shared .so library via cgo but this library is built from Golang?

Please also consider what happens if this two Golang has two different version :-D On Thursday, August 19, 2021 at 9:33:39 PM UTC+8 rmfr wrote: > Hi, > > As the title describes, does this is allowed by the Golang's design? If it > is allowed, I think there would be at least two Go

[go-nuts] What happens if Golang calls a shared .so library via cgo but this library is built from Golang?

Hi, As the title describes, does this is allowed by the Golang's design? If it is allowed, I think there would be at least two Golang runtime running in the same process space, am I correct? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] A question about metric `/sched/latencies:seconds` in go1.17's package runtime/metrics

Hi, I am reading the description of metric `/sched/latencies:seconds` in runtime/metrics: ``` /sched/latencies:seconds Distribution of the time goroutines have spent in the scheduler in a runnable state before actually running. ``` I wonder such records are from all the goroutines'

[go-nuts] How to correctly set a larger maxTinySize ?

I want to set a larger maxTinySize and see what the runtime will behave. Then I made these changes to the sources of go1.16.6: // go/src/runtime/malloc.go const ( debugMalloc = false maxTinySize = _TinySize tinySizeClass = _TinySizeClass // Tiny allocator parameters, see "Tiny

Re: [go-nuts] Does the time cost of the mark phase in gc is mainly depending on the amount of the living objects and has very little to do with the amount of unused objects?

Thank you very much, Ian. You gave me a deeper understanding of Golang's internal :-D On Wednesday, July 28, 2021 at 6:23:02 AM UTC+8 Ian Lance Taylor wrote: > On Tue, Jul 27, 2021 at 4:56 AM rmfr wrote: > > > > Hi, I'm reading the GC implementation of Golang, and some questio

[go-nuts] Does the time cost of the mark phase in gc is mainly depending on the amount of the living objects and has very little to do with the amount of unused objects?

Hi, I'm reading the GC implementation of Golang, and some questions have come to me. As the title described: Proposition 1: The time cost of the mark phase in GC is mainly depending on the amount of the living objects. Proposition 2: The time cost of the mark phase in GC has very

[go-nuts] Re: How to Optimize A Golang Application Which Has More Than 100 Million Objects at Peak?

; fits naturally into the code. > > On Friday, July 16, 2021 at 8:27:03 AM UTC-4 rmfr wrote: > >> I run it at an 8 cores 16GB machine and it occupies all cpu cores it >> could. >> >> 1. It is ~95% cpu intensive and with ~5% network communications. >> >&g

[go-nuts] How to Optimize A Golang Application Which Has More Than 100 Million Objects at Peak?

I run it at an 8 cores 16GB machine and it occupies all cpu cores it could. 1. It is ~95% cpu intensive and with ~5% network communications. 2. The codebase is huge and has more than 300 thousands of lines of code (even didn't count the third party library yet). 3. The tool pprof tells nearly

[go-nuts] Re: Does current GC move object now?

14, 2021 at 2:11:18 PM UTC+8 rmfr wrote: > I am watching the implementation of syscall `writev` from [here]( > https://github.com/golang/sys/blob/bd2e13477e9c63125302cd9da2d61879c6aa1721/unix/zsyscall_linux.go#L1641), > > and comparing it with the [proposal]( > https://github.com/

[go-nuts] Does current GC move object now?

I am watching the implementation of syscall `writev` from [here](https://github.com/golang/sys/blob/bd2e13477e9c63125302cd9da2d61879c6aa1721/unix/zsyscall_linux.go#L1641), and comparing it with the [proposal](https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md) of

[go-nuts] Re: How to call a C `writev` styled library api via cgo without allocation and copying of the whole byte slice vector?

in a single function call is the number of arguments to the function.* So does it is correct that you cannot call some C api like `writev` safely without concatenating all the byte slices together into one big byte slice? On Saturday, March 13, 2021 at 10:24:52 PM UTC+8 rmfr wrote: > Say here is

[go-nuts] How to call a C `writev` styled library api via cgo without allocation and copying of the whole byte slice vector?

Say here is a C api like `ssize_t writev(const struct iovec *iov, int iovcnt)` which the definition of iovec is like below: ``` struct iovec { uint8_t *Base; /* Base address. */ uint64_t Len;/* Length. */ }; ``` For C api which like `ssize_t write(const void *buf, size_t

[go-nuts] Does go programmers should handle syscall.EINTR all by themselves after go1.9 when writing disk files?

Does go programmers should handle syscall.EINTR all by themselves after go1.9 when writing disk files? I just noticed this commit https://github.com/golang/go/commit/c05b06a12d005f50e4776095a60d6bd9c2c91fac#diff-b7452e0f27c15f140b5e86f88e2d43deL192 If the answer is 'yes', I wonder why deleted