Re: [go-nuts] Bitmask is slower than modulo calculation

Your test is benchmarking int->any conversions more than it is testing the underlying modulo/mask difference. When you pass an integer to Enqueue, it is converted to any, which (usually) involves an allocation. That will swamp the cost of any single arithmetic operation. There are a few ways

[go-nuts] Re: all.bash fails on Ubuntu 24.04?

The first issue there could very well be an incompatibility with the gdb version. On Thursday, April 25, 2024 at 11:02:00 PM UTC-7 Uli Kunitz wrote: > Hi, > > I have installed Ubuntu 24.04 yesterday and there are two failures running > all.bash compiling go from source. I want to check whether

Re: [go-nuts] Congrats to the Go team

> There is a pretty significant degradation in AddFixed() which may be concerning to the Go team What is the benchmark for this? I am usually suspicious of sub-nanosecond benchmark times. Generally that indicates that the benchmark completely optimized away and all you are measuring is an

[go-nuts] Re: pprof CPU profiles missing inlined frames

This is a problem with your test. pprof is correct here. Since you never use n, when double is inlined its body is compiled completely away. On Thursday, February 15, 2024 at 10:18:07 PM UTC-8 Prashant V wrote: > Is it expected that CPU profiles taken with pprof don't include inlined > frames?

[go-nuts] Re: Bound check optimization with "computed" index

I'm not sure, but I suspect that the prove pass does not propagate known ranges through divides. On Tuesday, February 6, 2024 at 7:39:56 AM UTC-8 Leonard Mittmann wrote: > I am trying to optimize the loop performance by reducing the number of > bound checks. Inside the loop I compute a slice

Re: [go-nuts] code optimization bug in s390x (Go 1.21.4) ?

It seems strange that the bad result is ABCDEF1200 and not ABCDEF12. i.e., 6 zeros and not 8. Can you confirm? Definitely sounds like a bug to me. You should open an issue. On Tuesday, November 28, 2023 at 1:44:59 PM UTC-8 Timothy Olsen wrote: > A coworker suggested I try with

Re: [go-nuts] Generic zero value for compiler optimization

It would be nice if the compiler could figure this out (both for *new(T) and zeroT). When 61372 is implemented it will certainly be easier to just detect the zero builtin. Perhaps we should just wait for that. On Monday, August 14, 2023 at 5:31:16 PM UTC-7 Diego Augusto Molina wrote: > Thank

[go-nuts] Re: Maybe a Bug? The Go compiler stores a stack pointer into a global object

Yes, that looks very, very wrong. It looks like this issue goes back to at least 1.16. If you can open an issue at https://github.com/golang/go/issues we can investigate. On Wednesday, August 2, 2023 at 10:03:31 AM UTC-7 Jinbao Chen wrote: > I use go1.20.5 to compile the following code. >

[go-nuts] Re: unsafe.Pointer conversions

On Wednesday, July 26, 2023 at 9:56:54 AM UTC-7 Nigel van Keulen wrote: Since unsafe.Pointer can convert between types that have the same underlying type, can unsafe.Pointer also convert between function types who's arguments & return values have the same underlying type? The code I would

Re: [go-nuts] Is there any way to force Go to call asm function using register-based arguments?

There is still no way to do this in a supported manner. We may at some future time freeze ABIInternal and call it ABI1, at which point you could use that. But we have no plans or schedule for that at the moment. On Sunday, July 2, 2023 at 10:44:20 PM UTC-7 opennota wrote: > Ok Google, so one

[go-nuts] Re: Performance of byte-arrays as map keys

Key sizes 4 and 8 have special case hashing code. They are intended for int32, int64, and pointers, but your [4]byte and [8]byte take advantage of it as well. On Sunday, March 26, 2023 at 3:05:52 AM UTC-7 Amit Lavon wrote: > Hi gophers, > > Some code I am writing uses byte-arrays ([X]byte) as

[go-nuts] Re: alignment of stack-allocated variables?

If you're using unsafe anyway, I'd go the other direction, casting from the larger alignment to the smaller one. That avoids any alignment concerns. var x uint32 b := (*[4]byte)(unsafe.Pointer())[:] r.buff.Read(b) return x I would encourage you to use encoding/binary though. It all works out

[go-nuts] Re: Go 1.19 stack size optimization

Currently: - All stack sizes are a power of 2. - The minimum size is 2KB, hardcoded. - We reserve ~800 bytes of goroutine stacks for the runtime. So 1KB stacks are feasible, but just barely. I don't think you could fit much of a goroutine in 200 bytes of stack. So smaller sizes are possible,

Re: [go-nuts] Clarification of memory model behavior within a single goroutine

Just to be clear, to get what you want just write data normally for steps 1-4 and use an atomic store for step 5. That guarantees that other processes will see steps 1-4 all done if they see the write from step 5. (But you *do* have to use an atomic read appropriate to your language to do

Re: [go-nuts] Clarification of memory model behavior within a single goroutine

On the write side, you write your mult-GB data using normal writes, then atomic.Store for the final flag uint. On the read side, you use an atomic.Load for the flag uint followed by regular loads for the remaining multi-GB of data. Reading a particular flag value ensures that the following

[go-nuts] Re: Why there are eight bytes pad in the stack frame of main function?

Q1: stack frames are rounded to a multiple of 8 bytes, to keep the stack pointer 8-byte aligned. Part of that is rounding argsize to 8 bytes. (It's not strictly necessary, and we could report 4, I think, if there are no return values.) Q2: I think 4 are from rounding argsize up to 8 bytes, and

[go-nuts] Re: checkptr reports error in lfstack_64bit.go

On Thursday, November 10, 2022 at 1:59:11 PM UTC-8 David Pacheco wrote: > Hi Keith, > > Thanks for the helpful (and quick) reply! I gather you're right about not > applying checkptr to Go's own test suite. I applied your patch, tried > again, and started hitting failures in tests that were

[go-nuts] Re: Which one is the latest optimization: ASM/Pure Go implementations?

I'm not sure exactly what the question is that you're asking here. "latest and right optimization direction" doesn't make any sense to me. The stdlib is organized to take advantage of hardware instructions when they are available and falls back to portable Go code when they aren't. It sounds to

[go-nuts] Re: checkptr reports error in lfstack_64bit.go

Should be fixed by https://go-review.googlesource.com/c/go/+/448899 On Tuesday, November 8, 2022 at 4:34:00 PM UTC-8 Keith Randall wrote: > (Although normally lfstack nodes should not be heap allocated in the first > place?) > > > On Tuesday, November 8, 2022 at 4:32:11 PM UTC-8 Keith Randall

[go-nuts] Re: checkptr reports error in lfstack_64bit.go

(Although normally lfstack nodes should not be heap allocated in the first place?) On Tuesday, November 8, 2022 at 4:32:11 PM UTC-8 Keith Randall wrote: > I don't think checkptr is intended to be applied blindly inside the > runtime. The lfstack code is definitely doing things that checkptr

[go-nuts] Re: checkptr reports error in lfstack_64bit.go

I don't think checkptr is intended to be applied blindly inside the runtime. The lfstack code is definitely doing things that checkptr was designed to catch and flag. Maybe the lfstack routines need a go:nocheckptr annotation? On Tuesday, November 8, 2022 at 11:21:30 AM UTC-8 David Pacheco

Re: [go-nuts] Re: Atomic pointers to arrays and sequenced-before guarantees for array elements

> Given the above, is it guaranteed that A's stores to X, Y and Z are synchronized-before B's loads from X, Y and Z? Yes. The writes of X, Y, and Z are sequenced before the atomic write to M, the atomic write to M is synchronized before the atomic read of M (assuming the read returns the

[go-nuts] Re: Confused about heap usage for empty slices

(Actually, that address is an address on the stack, but that's only because the backing store for emptySlice does not escape. It should also take ~no space.) On Wednesday, September 7, 2022 at 4:53:12 PM UTC-7 Keith Randall wrote: > That address is not in the heap. It is the address of a

[go-nuts] Re: Confused about heap usage for empty slices

That address is not in the heap. It is the address of a special word in the runtime, called runtime.zerobase, which is explicitly for this purpose. It is a place to point things that need to be non-nil but have no size. On Wednesday, September 7, 2022 at 12:01:28 PM UTC-7 me...@pobox.com wrote:

Re: [go-nuts] How to use atomic.Int64?

There's a difference only on platforms that wouldn't normally 8-byte align an int64. Those are the 32-bit platforms, e.g. linux/386. On those platforms your program prints 4 8. On Thursday, September 1, 2022 at 5:15:29 AM UTC-7 axel.wa...@googlemail.com wrote: > I'm not sure under what

[go-nuts] Re: abort assembly code profile

For #1, that is https://github.com/golang/go/issues/15808 For #2, the Go compiler is generally not great at optimizing arrays, particularly copies of them (in your case, from ret to the return slot). I would recommend using either slices ([]int) or structs (struct {x, y int}), or even pointer

[go-nuts] Re: Go generics and bloating

On Tuesday, August 16, 2022 at 1:03:22 PM UTC-7 guil.l...@gmail.com wrote: > Hello, > > I remember a paper about Go Generics but I cannot find it again. > It was a scientist paper (with a lot of maths far beyond my understanding > ^^). > Title was something like "Lightweigh generics for Go" or

[go-nuts] Re: Go 1.19 average goroutine stack

On Wednesday, August 17, 2022 at 8:18:35 PM UTC-7 tapi...@gmail.com wrote: > I'm a bit wondering about how the following case will be affected by the > change: > 1. Initially, there is one goroutine, which stack size is large at the > time of a GC process. > 2. After the GC process, a large

[go-nuts] Re: Go 1.19 average goroutine stack

The initial allocation size is exported, you can use the runtime/metrics package to look at it. Something like this: package main import ( "fmt" "runtime/metrics" ) func main() { s := []metrics.Sample{{Name: "/gc/stack/starting-size:bytes"}} metrics.Read(s)

Re: [go-nuts] concurrent read/write different keys in map

Updating existing keys in parallel is not guaranteed to be safe. If you want to modify values, you'd have to do the trick mentioned above where instead of a map[K]T you use a map[K]*T and to do modification you do *m[k] = T{...} or whatever. Go maps do incremental growth work on every update,

Re: [go-nuts] noinline is 25% faster than inline on apple m1 ?

Yes, I think this is the extra LEAQ that appears in the loop. Ideally it would be lifted out of the loop. I think that is https://github.com/golang/go/issues/15808 On Friday, July 22, 2022 at 7:33:47 PM UTC-7 Taj Khattra wrote: > i get similar results with 1.18 (inline slower than noinline) >

Re: [go-nuts] Aligning loops in Go assembly

I don't think PCALIGN is supported for x86. The assembler can parse the instruction, but the x86 assembler backend can't generate machine code for it. Wouldn't be hard to add, I think. There's already disabled experimental code in there for aligning loops. On Friday, February 25, 2022 at

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

couldn't a simple way be to use e.g. > > f(x) = 2xfor x < 1024 > f(x) = x + x/4 + 768 otherwise > > Then > > f(1023) = 2046 > f(1024) = 2048 > > So the function is monotonic (and kind of "smooth") > > On Tue, 7 Sep 2021, 02:17 'K

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

I don't think this is an important thing to fix, but I agree it is a bit odd. If there's a simple way to restore monotonicity we'll consider it. A similar issue: https://github.com/golang/go/issues/41239 On Sunday, September 5, 2021 at 8:59:01 AM UTC-7 jake...@gmail.com wrote: > You are 100%

[go-nuts] Re: various go-assembler code is generated

The Go compiler is not very good at eliminating redundant copies of large temporaries (structs with many fields, or arrays with length>1). On Tuesday, July 13, 2021 at 2:51:32 PM UTC-7 buro...@gmail.com wrote: > https://go.godbolt.org/z/G8K79K48G - small > https://go.godbolt.org/z/Yv853E6P3 -

[go-nuts] Re: What is 4*PtrSize extra space on goroutine stack for?

I'm not sure it is necessary. The intent is to make sure we don't access off the top of the stack. sys.MinFrameSize should really handle that, I think. My guess is that the 4*sys.PtrSize was from before we had the MinFrameSize concept defined. On Monday, July 12, 2021 at 12:32:09 AM UTC-7

Re: [go-nuts] Operator precedence

Yes, Go will evaluate as specified in the spec. So it can't do (a*3.0)/2.0 as a*(3.0/2.0). At least, it always needs to produce results *as if* the former was used. Normally for floats that means it does the ops exactly in the order specified. For integers there are often rewrites that will

Re: [go-nuts] How to cast a multi-value?

You can use a function call to do the cast: func byteErr2stringErr(b []byte, e error) (string, error) { return string(b), e } content, err := byteErr2stringErr(os.ReadFile(path)) It's still using additional variables, but they are hidden inside the helper function. On Sunday, May 16, 2021

Re: [go-nuts] Re: go routines not being deallocated

This might be https://github.com/golang/go/issues/34457 (at least, Brian's repro). When a goroutine finishes, we deallocate its stack, and that deallocation will eventually be given back to the OS. The Goroutine descriptor, however, will live forever. We'll reuse it for new goroutines, but it

Re: [go-nuts] Strange behaviour with loops #45192, #45175

If you look at CL 304251, there's one place where we added "return false". Put a panic just before that line (in 1.15.11 or 1.16.3), rebuild the compiler, then rebuild your program and see if your program triggers that panic. On Wednesday, April 7, 2021 at 2:37:53 PM UTC-7 Ian Lance Taylor

[go-nuts] Re: meaning of SSA operation

On Tuesday, March 23, 2021 at 9:11:13 AM UTC-7 Ge wrote: > > Hi, > Recently I encountered a problem which seems to be related to SSA > optimization > and feels hard to figure out what some SSA operation means. > > Code: > case1: > func main() { > var x int > go func() { > for

Re: [go-nuts] Re: Compiler treatment of infinite loops

The fact that "for{}" is a terminating statement and "for true {}" is not, parallels the fact that "return" is a terminating statement and "if true { return }" is not. On Friday, March 5, 2021 at 4:25:17 PM UTC-8 Ian Lance Taylor wrote: > On Fri, Mar 5, 2021 at 4:11 PM 'Axel Wagner' via

Re: [go-nuts] efence and changing the read-validity of memory pages on darwin/amd64

On Tuesday, February 9, 2021 at 11:05:23 AM UTC-8 Evan Jones wrote: > I just spent a solid day debugging memory corruption with a Cgo library > that was passing a pointer as uintptr, which failed in rare cases when the > stack was copied then overwritten. The GODEBUG=efence=1 flag actually

Re: [go-nuts] How to get hold of GOARM at runtime?

You should also consider using x/sys/cpu to query the cpu features directly (not sure if that applies to your use case or not). On Tuesday, January 19, 2021 at 1:00:55 PM UTC-8 Ian Lance Taylor wrote: > On Tue, Jan 19, 2021 at 11:36 AM jan.f...@gmail.com > wrote: > > > > Short question:

Re: [go-nuts] Runtime cost of type assertions

Go currently doesn't do any optimizations based on the universe of types seen in the program. This is both because reflect can create new ones, as you mentioned, and also because package plugin can effectively "discover" new ones. The Go compiler + "go build" are organized to compile one

[go-nuts] Re: Interfaces holding integers and memory allocations

Unfortunately for you, interfaces are immutable. We can't provide a means to create an interface from a pointer, because then the user can modify the interface using the pointer they constructed it with (as you were planning to do). You could use a modifiable reflect.Value for this. var i

Re: [go-nuts] Ballooning Executable Sizes

This was traced down to passing very large (multi-MB) types by value. TL;DR, don't do that. See the issue for more details. On Thursday, November 19, 2020 at 12:59:32 PM UTC-8 ren...@ix.netcom.com wrote: > Based on the OP it is occurring with 1.13,14,15 > > > On Nov 19, 2020, at 2:19 PM, Ian

[go-nuts] Re: Conditional move & hoist optimizations

> My questions: Is any form of loop/invariant-hoisting performed? Yes, but not much. We hoist simple things like constants and spill restores. The big kahuna, loads, are typically not lifted because they depend on memory and we don't have the alias analysis to prove that that is safe. We

Re: [go-nuts] Re: Register spilling size

Ah, arm64. That code jesper points to looks like the culprit. The whole stack frame alignment should be handled separately from the alignment of individual variables, so the total alignment needed shouldn't matter. Not sure why we do that. A small archaeology dive indicates this code dates

[go-nuts] Re: Register spilling size

It don't think it does. For instance, an int16 will be spilled to a 2-byte slot in the stack frame. Can you show us what you are seeing? This is what I tried: package main func f(p, q *int16) { x := *p y := *q g() *p = y *q = x } func g() go tool compile -S tmp.go 0x001d 00029 (tmp1.go:4)

Re: [go-nuts] Re: Slice reuse + GC

It's common practice to *write* to elements between the length and capacity of a slice. Usually, you use append to do that. It's bad practice to *read* elements between the length and capacity. Which you can't do with a simple indexing op, of course. You would have to reslice larger and then

Re: [go-nuts] Learning the runtime

There are a bunch of talks from Gophercon and elsewhere that cover pieces of the runtime: Channels: https://www.youtube.com/watch?v=KBZlN0izeiY Scheduler: https://www.youtube.com/watch?v=YHRO5WQGh0k Maps: https://www.youtube.com/watch?v=Tl7mi9QmLns [shameless self plug] Goroutines, defers,

[go-nuts] Re: Converting *byte to unsafe.Pointer and back to *byte

On Tuesday, February 25, 2020 at 4:10:46 AM UTC-8 dmitry@jetbrains.com wrote: > What is the meaning of the conversion > > var b []byte > var p *byte = (*byte)(unsafe.Pointer(*b[0])) > You mean [0] at the end there, not *b[0]. > > It is used for example in >

[go-nuts] Re: cmd/vet: "possible misuse of unsafe.Pointer" on C pointer -> uintptr -> different package -> unsafe.Pointer -> C pointer

Why all the conversions? Why not just pass the C pointer from one package to another? Or an unsafe.Pointer? You can use a placeholder type, even. Make procAddr a *byte, for example. The pointer conversion rules are intended to ensure safety when playing with Go pointers (by that, I mean

Re: [go-nuts] Re: float behaviour on arm64 v amd64

multiply and add (which on amd64, it probably isn't). > Dan > > On Mon, 2020-01-13 at 15:45 -0800, 'Keith Randall' via golang-nuts > wrote: > > Note: discussion at https://github.com/golang/go/issues/36536 . TL;DR > > fused > > floating point multiply-add gives higher preci

[go-nuts] Re: float behaviour on arm64 v amd64

Note: discussion at https://github.com/golang/go/issues/36536 . TL;DR fused floating point multiply-add gives higher precision results. On Sunday, January 12, 2020 at 8:19:54 PM UTC-8, kortschak wrote: > > I am going through failures that I see in Gonum tests when we build on > arm64 (Travis

[go-nuts] Re: Attaching a Finalizer to a struct field holding a slice or the slice's underlying array

It should work to just set the finalizer on the first byte of an allocation. i.e.: s := make([]byte, N) runtime.SetFinalizer([0], func(b *byte) { ... }) Note that the spec of runtime.SetFinalizer doesn't actually guarantee that this will work. But I think in the current implementation it will.

Re: [go-nuts] Clarification on unsafe conversion between string <-> []byte

In the runtime we use structs like these, but with unsafe.Pointer data fields (runtime.stringStruct and runtime.slice). They are much safer to use than reflect's types with uintptr Data fields. Unfortunately we can't change reflect's types because of the Go 1 compatibility guarantee. You can

[go-nuts] Re: SSA-able and canSSA meaning in Go compiler's SSA backend?

On Wednesday, September 18, 2019 at 1:50:27 PM UTC-7, Mohit Verma wrote: > > Hi All, > > I was reading Go compiler's SSA backend code at > cmd/compile/internal/gc/ssa/go > > & > cmd/compile/internal/ssa >

Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

On Fri, Jul 5, 2019 at 9:16 PM Mohit Verma wrote: > Thanks Keith. > > Yes, the function call takes a variadic interface argument, so it would > cause the variables to escape if it existed before. To take care of this, I > allocate space for the interface during buildSSA & then call >

Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

On Fri, Jul 5, 2019 at 2:05 PM Mohit Verma wrote: > Thanks Keith, Ian. > > Specifically, I am trying to catch all the memory stores/moves during the > build SSA phase, and instead call a function that can do things like record > the old/new values in a journal. > So I changed the methods like

Re: [go-nuts] Tools for developing Go compiler/ Go code from SSA

On Wed, Jul 3, 2019 at 9:04 PM Ian Lance Taylor wrote: > [ +khr ] > > On Wed, Jul 3, 2019 at 4:46 PM Mohit Verma wrote: > > > > Hi All, > > > > I am trying to change the ssa phase of Go compiler to do extra work > during memory stores. > > For example whenever there is a memory store, I want to

[go-nuts] Re: Concurrent Routines in WASM

No, it doesn't. Do wasm threads exist yet? When the wasm port was first developed, they didn't exist. If the spec is now complete, we would just need a builder than can test threads, and then we would implement threading support in tip (for 1.14, presumably). Feel free to submit patches. It

Re: [go-nuts] Go if else syntax .. suggested replacement

On Wednesday, April 24, 2019 at 2:03:01 PM UTC-7, Kurtis Rader wrote: > > On Wed, Apr 24, 2019 at 1:14 PM andrey mirtchovski > wrote: > >> Here's the lore associated with the subject: Ken wanted ternary, Rob >> and Robert did not. They overruled Ken (remember, early on all three >> had to agree

Re: [go-nuts] Re: Accessing *[]uint64 from assembly - strange memory corruption under heavy load - any ideas?

Your assembly looks ok to me. At least, the sections you've shown us. It would help if we could see all of it and/or the whole program. You might want to try putting a len>0 test in the pop and a len > On Fri, Mar 22, 2019 at 10:55 AM Robert Johnstone > > wrote: > > > > I don't see any memory

Re: [go-nuts] sync/atomic and zero-initialization

The garbage collector ensures that after it has zeroed memory, it does proper synchronization to hand off that memory to an allocator. That allocator (and the goroutine on whose behalf it is working) is then guaranteed to see the zeroed memory. That's how heap memory works. Stack memory is a

[go-nuts] Re: runtime CallerFrames and FuncForPC miss some infomation

FuncForPC misses the test function because it is inlined. Using FuncForPC on the results of Callers does not work correctly in the presence of inlining. That is essentially why CallersFrames was introduced. The function name is missing because you're using the wrong expression for it. You

[go-nuts] Re: Providing more detail after a nil pointer dereference

27605 is more about providing the values that caused the panic, not the source location. It is still the case that even with 27605 multiple indexing operations on the same line are not distinguished (unless knowledge of the application lets you disambiguate using the values). For nil pointer

Re: [go-nuts] Is WASM support planned in go 1.12 ?

To answer the OP, wasm support is in 1.12 and is still experimental. There have been some changes to the wasm support but nothing major. (See the syscall/js section of https://tip.golang.org/doc/go1.12 for details.) On Wednesday, February 6, 2019 at 2:27:53 PM UTC-8, Tharaneedharan Vilwanathan

Re: [go-nuts] Is conversion between int and uint a no-op i.e. is it free

int<->uint conversions should never generate any machine code. They are free. On Saturday, November 24, 2018 at 10:55:50 AM UTC-8, Andy Balholm wrote: > > There is nothing in the language spec that guarantees anything about > performance. But if logic tells you that it should be a no-op, and >

Re: [go-nuts] Limit goroutine resource usage?

There's no equivalent of the methods you mentioned. You can't limit a goroutine from another goroutine, because (among other reasons) there's no way to name it. A goroutine can limit itself a bit by calling runtime.Gosched, or more forcefully using time.Timer. Andrey's suggestion of limiting

Re: [go-nuts] implementation of sync.atomic primitives

On Monday, March 19, 2018 at 9:30:39 AM UTC-7, thepud...@gmail.com wrote: > > Hi Ian, > > I know you were not giving any type of definitive treatise on how go > treats atomics across different processors... > > but is a related aspect restricting instruction reordering by the compiler >

[go-nuts] Re: Why gc compiler treat slice and custom type differently in garbage collection?

This ideally shouldn't happen. For some reason the compiler is keeping t.y alive across the printMemStat calls, even when it only needs to keep t.x alive. I've opened an issue https://github.com/golang/go/issues/24263 On Monday, March 5, 2018 at 8:08:59 AM UTC-8, di...@veryhaha.com wrote: > > >

Re: [go-nuts] GC Internals Questions

Pointers that point from a Go object to somewhere outside the Go heap are perfectly fine. The Go runtime will not try to dereference them. unsafe.Pointer is ok, but so are concrete types, like *byte. One caveat: the pointer must be a real pointer. Don't store a bunch of bitfields in a Go

Re: [go-nuts] corrupt stack?

package main // Convert an *A to a *B, using a data race. // Works for any types A and B. func cast(a *A) *B { var x interface{} go func() { for i := 0; i < 10; i++ { x = a } }() go func() { var b *B for i := 0; i < 10; i++ { x = b } }() for i := 0; i < 10; i++ { b, ok := x.(*B) if

Re: [go-nuts] Can I interpret the Go 1 memroy model as the following described?

I don't think the Go memory model provides any guarantee here. In particular, x==0, y==1 is allowed at the end. There is no happens-before relationship between both of the final reads and either of their writes. So those reads are allowed to observe those writes, or not. The fact that x=1

Re: [go-nuts] How to remove a struct value from a struct slice without memory leak?

I see a couple of issues with your code. The code you use for removal of an element is right. You've correctly made sure there is no leak. You never return the clients slice back to the caller. Any length shortening of the clients slice will be lost when the function returns. You might want

[go-nuts] Re: Question regarding compiler internals

On Wednesday, September 20, 2017 at 7:51:28 AM UTC-7, Jacob McCollum wrote: > > All, > > This is my first time posting to the golang-nuts mailing list, but I've > hit a wall and I'm not sure where else to reach out for some assistance. > > I'm knee-deep in a research implementation of

[go-nuts] Re: [Assembler] How can I call SIMD immediate by FP?

The immediate goes first, like this: SHUFPD $1, X1, X2 Note that SHUFPD takes an immediate for the shuffle - I don't see how you can implement the function you want; it takes a dynamic shuffle argument. Unless you do a switch on all possible values of the immediate. On Tuesday, June 13, 2017

[go-nuts] Re: Unexpected need to use runtime.KeepAlive().

On Sunday, May 7, 2017 at 8:21:38 AM UTC-7, Bruno Albuquerque wrote: > > I have this struct that has an associated method that simply call a C > function that might take a long time to use. It is defined more or less > like this: > > import "C" > > type Indexer struct { > cIndexer *C.Indexer

Re: [go-nuts] Re: Will deleting a key from a map in an iteration prevent some keys being iterated in the same iteration?

Yes, all keys present in the map at the start of iteration, that aren't deleted during iteration, will be returned during iteration. On Monday, May 1, 2017 at 4:51:56 AM UTC-4, T L wrote: > > > > On Monday, May 1, 2017 at 3:56:51 PM UTC+8, Paul Jolly wrote: >> >> I think the part of the spec

[go-nuts] Re: Large GC pauses with large map

It is almost never a good idea to call runtime.GC explicitly. It does block until a garbage collection completes. This behavior is sometimes useful in tests, but almost never otherwise. If it weren't for go1 compatibility, we'd rename this function to something that more clearly spells out

[go-nuts] Re: about the []byte -> string comversion optimization, is it some weird?

On Wednesday, April 19, 2017 at 3:56:21 AM UTC-7, T L wrote: > > > > On Wednesday, April 19, 2017 at 3:37:29 AM UTC+8, Keith Randall wrote: >> >> This is a weird corner case in string concatenation optimization. >> >> runtime.concatstrings (what the + in this code gets rewritten to) has an >>

[go-nuts] Re: about the []byte -> string comversion optimization, is it some weird?

This is a weird corner case in string concatenation optimization. runtime.concatstrings (what the + in this code gets rewritten to) has an optimization where if all the strings but one that it is concatenating are 0 length, then it returns the remaining one without doing any allocation. Because

Re: [go-nuts] Re: memclr optimization and structs

AM UTC-7, T L wrote: > > > > On Saturday, April 15, 2017 at 7:18:51 PM UTC+8, Konstantin Khomoutov > wrote: >> >> On Sat, 15 Apr 2017 01:31:27 -0700 (PDT) >> "'Keith Randall' via golang-nuts" <golan...@googlegroups.com> wrote: >> >>

[go-nuts] Re: Assembly jump instruction operands

https://github.com/golang/go/issues/19718 On Saturday, March 25, 2017 at 4:42:31 PM UTC-7, Keith Randall wrote: > > I think you're talking about conditional branches > > 0x008c 00140 (s.go:7) JLT $0, 55 > > There is sometimes an optional constant $0 or $1 in addition to the > destination. $0

Re: [go-nuts] Re: Unsafe string/slice conversions

> overwritten by subsequent functions that are pushed on the stack. > > On Thursday, March 23, 2017 at 9:05:48 PM UTC-4, Caleb Spare wrote: >> >> Filed: https://github.com/golang/go/issues/19687 >> >> On Thu, Mar 23, 2017 at 4:41 PM, 'Keith Randall' via golang-nuts >

[go-nuts] Re: Unsafe string/slice conversions

On Thursday, March 23, 2017 at 4:24:40 PM UTC-7, Caleb Spare wrote: > > That's very good to know. Thanks, Ian. > > Unfortunately if I use this KeepAlive-based fix, p escapes and so the > function now allocates. I guess I'll stick with the original version > from my first email. > > Does this

Re: [go-nuts] Re: Is there a reason go doesn't use the small string optomization

to me. (Google-internal?) > > On Wed, Feb 1, 2017 at 5:18 PM, 'Keith Randall' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > I wrote up a proto-proposal for something like this a while ago. > > > > https://docs.google.com/a/google.com/document/d/18nu6QTr- > A

Re: [go-nuts] Re: Is there a reason go doesn't use the small string optomization

I wrote up a proto-proposal for something like this a while ago. https://docs.google.com/a/google.com/document/d/18nu6QTr-ACYr5AiyP6x31SkXvuJZZaZ12lnvPTEQfgQ/pub It has a few numbers worth looking at in it. This proposal was before the fully precise GC we have today. It needs to have special

[go-nuts] Re: Accessing an slice is too slow than Array

You're not really testing what you think you are testing. When you do "_ = load something", the compiler just throws away the load. You have to use the result somehow to keep the load in the final assembly. What you are actually timing is the speed of the modulo operator (%). For the pointer

[go-nuts] Re: Another runtime.KeepAlive question

On Friday, December 30, 2016 at 1:26:26 PM UTC-8, Justin Israel wrote: > > Hi, > > Regarding this thread: > https://forum.golangbridge.org/t/curious-about-runtime-keepalive-usage/3530 > > And also the original problem example from Russ: >

[go-nuts] Re: Simple Go program that doesn't seem to free memory as it should...

I think what is going on is this. y := []*int{[0]} compiles to: var z [1]*int // allocate backing array p = // take its address p[0] = [0] // initialize it y := z[:]// slice it Because z has its address taken, we conservatively assume that z lives

Re: [go-nuts] Re: Eliminating redundant map lookups

Yes, it currently requires two lookups (two hashes, two bucket searches, etc.). This general problem is issue 17133 (https://github.com/golang/go/issues/17133). Your example has the extra complication that the update operation is an append, not just a +=. On Sunday, November 27, 2016 at

Re: [go-nuts] CFG for a Go program

You can get the CFG (control flow graph) for a function by setting the environment variable GOSSAFUNC to the function in question when building. It will generate a file named ssa.html in the current directory which you can load into a browser. It doesn't draw the CFG explicitly but the nodes

[go-nuts] Re: Concurrently read map entries into a channel

On Saturday, November 5, 2016 at 7:48:27 AM UTC-7, leob...@gmail.com wrote: > > Hey, > > I have a scenario where I need to iterate over (as many as possible) map > entries and send them into a channel. > The operation on the other end of the channel can take a long time, so > sends on the

[go-nuts] Re: Two Related Questions. (1) Map Concurrency (2) Making Multidimensional Arrays

Tamás's suggestion of using [4]string as the key is a good one. You could use any struct you want as well, if you want to name the parts of the key. How are you using the map? If you're only reading the map, then concurrent access is allowed. Concurrent access is only forbidden if one of the

Re: [go-nuts] Will go compiler do optimization here if "bytes" is a global variable?

Yes, it is. The optimization occurs for any occurrence of m[string(expression of type []byte)]. Where the byte slice came from (global or otherwise) is irrelevant. On Monday, July 25, 2016 at 8:37:03 AM UTC-7, T L wrote: > > @Randall, thanks for answer. > You mean the answer is yes, right?

Re: [go-nuts] Will go compiler do optimization here if "bytes" is a global variable?

This was a concern when we originally implemented the m[string(b)] optimization. If someone is simultaneously modifying b, then weird things happen during the lookup. But it won't crash anything, just maybe not return what you expect. And that's ok in cases of a data race, the spec makes no

Re: [go-nuts] Bitmasks on signed types

I do x & (0x - 1<<32). On Tuesday, June 14, 2016 at 1:44:14 PM UTC-7, Michael Jones wrote: > > I have fought this many times. > > What I almost always do is cast all variables involved as unsigned so that > I can express the logical operations as desired. The exception is right > shift

  1   2   >