[go-nuts] Re: runtime swiss maps

There is an implementation in progress. For the most part it has not been checked in yet. There is a stack of CLs starting at https://go-review.git.corp.google.com/c/go/+/582415 On Saturday, August 17, 2024 at 1:56:06 PM UTC-7 Leah Stapleton wrote: > Hi, > The code in the map_swiss.go and map_

[go-nuts] Re: gc: optimize JMP to RET instructions

We generally don't do optimizations like that directly on assembly. In fact, we used to do some like that but they have been removed. We want the generated machine code to faithfully mirror the assembly input. People writing assembly have all kind of reasons for laying out instructions in partic

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 to

[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 empty

[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 in

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 optimi

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 yo

[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. > pack

[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 lik

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 ca

[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 ke

[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(&x))[:] r.buff.Read(b) return x I would encourage you to use encoding/binary though. It all works out j

[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, but

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 reade

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 loads

[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 4

[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?) >&g

[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-

[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 th

[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 wrote

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 result

[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 addr

[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 situati

[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 t

[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 qu

[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) fmt.Printf("%d\n"

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, s

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) > b

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 1:25:3

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

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% cor

[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 - lo

[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 peng.

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 make

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 at

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 ne

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 wro

[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 golang-

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 mad

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: GOARCH

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 packag

[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 int6

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 L

[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 defin

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 from

[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) MOVQ

Re: [go-nuts] Heap allocation found in function prolog

That looks like something escaped to the heap. If you pass the -S option to the compiler, the assembly output will have the symbolic name of the type being allocated (at the LEAQ 2 instructions before the call to newobject). If you pass the -m option to the compiler, it will tell you what escaped

Re: [go-nuts] Re: what is empty block mean in ssa.Block?

On Tue, Aug 25, 2020 at 3:10 AM xie cui wrote: > so what's dead value means? in my mind, dead value can be ignore, why we > need to append it to b.Values? > > Dead means no longer used. Their values are ignored. We put them in b.Values so that they get cleaned up properly. See the deadcode pass f

[go-nuts] Re: what is empty block mean in ssa.Block?

Empty here means has-only-dead-values. All the values still in s0 and s1 are known to be dead. On Monday, August 24, 2020 at 8:24:06 AM UTC-7, xie cui wrote: > > > https://github.com/golang/go/blob/master/src/cmd/compile/internal/ssa/fuse.go#L130 > it mention empty block here. in my knowledge, em

[go-nuts] Re: which pass of SSA will transform a ssa.Value(op=OpPhi) phi operations to a normal(not phi operations)?

The regalloc pass does that. It ensures that all the inputs and the output of a phi are all in the same register (or memory location), so the phi becomes a no-op. The regalloc pass doesn't actually remove the phi, though. Removal is actually in genssa in cmd/compile/internal/gc/ssa.go. Look for

[go-nuts] Re: why the values in ssa block can be unordered?

All the ordering required is explicit in the representation. If x is an argument of y, then x must come before y (in the eventual assembly output). There is no other need for ordering within a basic block. Any order consistent with the argument ordering I mentioned above is ok. On Friday, August

[go-nuts] Re: What's the basic block layout algorithm ?

It's not a fancy algorithm. It tries to layout blocks connected by high-likelihood edges together. It also tries to keep panic paths at the end. I don't know of any documentation for it, other than the code. There's nothing particularly important in the layout pass to help with register allocat

Re: [go-nuts] what is walk(fn *Node) for?

In addition to what Jesper said, the walk pass does a variety of lowerings and optimizations on the ast. For example, it rewrites the builtin `new` to a runtime call, rewrites switches to a tree of `if` statements, etc. On Monday, July 20, 2020 at 2:11:08 AM UTC-7 jesper.lou...@gmail.com wrote:

[go-nuts] Re: casting arbitrary int to unsafe.Pointer: go test -race (checkptr) complains

Just write a wrapper on the C side (in the import "C" code) that takes a uintptr and casts it to void*. func wrapper(a uintptr, b, c, d, e ...) { op_open_callbacks((void*)a, b, c, d, e) } Then you can call C.wrapper and pass it s.id directly. On Thursday, July 9, 2020 at 4:17:08 PM UTC-7, Hra

Re: [go-nuts] [Arm32] float/NaN/int issue (fixed for me, posting for info/discussion/bug report?)

On Wednesday, July 8, 2020 at 4:50:30 PM UTC-7, simon place wrote: > > wait a minute, so this... https://play.golang.org/p/x5SQVgSJsIs > > could return anything! > > I think float -0 should be guaranteed to convert to integer 0. Just like -0.25 and 0.25. The spec says "fraction discarded" but I

[go-nuts] Re: who is mike?

Mike Burrows https://en.wikipedia.org/wiki/Michael_Burrows On Sunday, June 28, 2020 at 3:51:27 PM UTC-7, Bill Morgan wrote: > > who is mike wrt this commit? > > commit bc0b4f0d2a610059afb95ef0360704714815187d > Author: Ken Thompson > > Date: Thu Nov 13 10:35:44 2008 -0800 > > mike's map code

Re: [go-nuts] [runtime] gostring question

Yes, we can't depend on the data at *p to remain constant. We need to snapshot it at the moment of the gostring call. On Tuesday, June 23, 2020 at 5:52:23 PM UTC-7, Kurtis Rader wrote: > > On Tue, Jun 23, 2020 at 5:32 PM Bill Morgan > wrote: > >> I'm a C programmer so maybe this is a dumb questi

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

On Wed, Jun 10, 2020 at 4:15 AM Viktor Kojouharov wrote: > Thanks Ian. Adding to that allocation to cover the element size did the > trick. Out of curiosity, the momery allocated by mallocgc is still tracked > by the gc, right? > A brief look at the code seems to indicate that this is the case,

Re: [go-nuts] Re: Preventing SIGBUS errors when memmove-ing an unsafe.Pointer to multiple destinations

Showing us some code would really help. It's hard to understand what you are doing from this brief description. Also, where does the SIGBUS occur? What pc, and what address? What types are you passing as the first argument to typedmemmove? Where did you get them from? This is a fine question f

Re: [go-nuts] Why do we use xchg rather than lock mov to inplement atomic.StoreX?

Ah, so I guess we don't need a barrier at all on x86 for the release semantics. Presumably we still need something for Dekker-style algorithms, although I don't think we use those anywhere in the stdlib, at least. I guess it's just a question of which is faster? On Tue, Apr 28, 2020 at 8:24 PM Cho

Re: [go-nuts] Why do we use xchg rather than lock mov to inplement atomic.StoreX?

It looks like the mechanism used by C's std::atomic would not be useful for us. We require release semantics on atomic stores. That is, if one thread does: .. some other writes ... atomic.StoreInt32(p, 1) and another thread does if atomic.LoadInt32(p) == 1 { .. some other reads ... } If t

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 in

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, stacks

[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 &b[0] at the end there, not *b[0]. > > It is used for example in > https://github.com

[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 pointer

[go-nuts] Re: Proposed additions to maphash documentation

I mailed a small CL for this. It now says "uniform distribution on 64-bit integers". That should imply reduction by masking (or other methods) is fine. https://go-review.googlesource.com/c/go/+/219340 On Sunday, February 9, 2020 at 10:52:22 AM UTC-8, Juliusz Chroboczek wrote: > > It would be hel

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

a separate 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 m

[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 now

Re: [go-nuts] Is the GC recovering storage when full slice expression reduce capacity ?

It can get expensive to do that. Instead of just a mark bit per object, and a queue of pointers to mark, you need a mark bit per word and a queue of ptr+len. You can also end up doing more than constant work per mark. x := [10]*int{ ... 10 pointers ... } a := x[:3:3] b := x[7::] x is now dead, bu

Re: [go-nuts] Is the GC recovering storage when full slice expression reduce capacity ?

On Friday, January 10, 2020 at 1:02:22 AM UTC-8, Jan Mercl wrote: > > On Fri, Jan 10, 2020 at 9:52 AM Christophe Meessen > > wrote: > > > > It is possible to reduce the capacity of a slice by using the full slice > expression (https://golang.org/ref/spec#Slice_expressions). > > > > Now cons

[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(&s[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] Map of structs vs Array of structs

Note: this issue - assigning to a field of a compound map value - is a proposal at https://github.com/golang/go/issues/3117 > Ian, can you clarify that for me, so the GC tracks interior pointers (to a slice of structs) so that even if there are no references to the outer slice it will not be GC

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 do

[go-nuts] Re: Testing changes to Go SSA?

In addition to the tests you saw, there are a bunch of tests in test/codegen that makes sure specific sequences of instructions are or are not generated. Tests for specific issues that have been fixed are in test/fixedbugs. Generally the whole test suite is one giant compiler test. Run all.bash a

[go-nuts] Re: Testing changes to Go SSA?

In addition to the tests you saw, there are a bunch of tests in test/codegen that makes sure specific sequences of instructions are or are not generated. Tests for specific issues that have been fixed are in test/fixedbugs. Generally the whole test suite is one giant compiler test. Run all.bash a

[go-nuts] Re: Testing changes to Go SSA?

In addition to the tests you saw, there are a bunch of tests in test/codegen that makes sure specific sequences of instructions are or are not generated. Tests for specific issues that have been fixed are in test/fixedbugs. Generally the whole test suite is one giant compiler test. Run all.bash a

[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

invoked > during compileSSA() in gc/pgen.go. > > It's inserted by the compiler, I believe. cmd/internal/obj.Flushplist is called from (*Progs).Flush in cmd/compile/internal/gc/gsubr.go > > Thanks a lot! > Mohit > > > On Fri, Jul 5, 2019 at 11:32 AM Keith Randall wrote: >

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

ntime > seemed inefficient to me, and I thought the Go team might be doing things > differently during their development/debug. > > Thanks! > Mohit > > On Wed, Jul 3, 2019 at 9:24 PM Keith Randall wrote: > >> >> >> On Wed, Jul 3, 2019 at 9:04 PM Ian Lance Taylor wrote

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 loo

Re: [go-nuts] Any way to prevent gc emitting AVX256 and AVX512 instructions for amd64?

By the way, these instructions are not generated by the compiler. They are part of the assembly in the stdlib (runtime or internal/bytealg, probably). On Tuesday, May 14, 2019 at 7:37:44 AM UTC-7, Amnon Baron Cohen wrote: > > OK. > Thanks for the explanation and pointers. > > On Tuesday, 14 May 2

Re: [go-nuts] If Go is using libc instead of syscalls on macOS now, why is it not shown via otool -L?

I don't have hard numbers on slowdowns. It will depend a lot on the binary in question. At the time I checked the compiler and linker and it did not slow those down (to the accuracy of our benchmarks). The linker particularly is fairly read syscall intensive. We've seen benchmarks that have sig

[go-nuts] Re: There is definitely a race condition, why it can't be detected by race condition detector?

The race detector has many special cases for packages like sync and runtime, so it can detect synchronization operations. I haven't looked, but I wouldn't be surprised if the race detector ignored package sync's code bodies and just hard coded the semantics of each operation. On Monday, April 2

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

[go-nuts] Re: Using the CX register on 386 and AMD64 in Go Assembly

Fixed memory location is a global variable. This only applies to 386, not amd64. This applies only to (SB) dereferences, not to any other (SP, FP, or standard register). The text doesn't really say it, but it applies to LEAL as well as loads and stores. On Saturday, March 30, 2019 at 2:40:28 PM

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 sp

[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 shoul

[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 der

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] Huge map[string]*Object and GC where *Object is from sync.Pool

On Thu, Sep 27, 2018 at 11:26 PM Peter Mogensen wrote: > > > On 09/28/2018 08:17 AM, Peter Mogensen wrote: > > > > > > On 09/28/2018 03:04 AM, keith.rand...@gmail.com wrote: > >> Objects returned by Get() are not special in any way. They will be GCd > >> just like an object returned by new(). In

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Objects returned by Get() are not special in any way. They will be GCd just like an object returned by new(). In fact, they will often be just a new()'d object. There is no association of such an object with the pool. A pool is just a fancy free list. Get might return a previously Put'd object

  1   2   >