Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.14 release notes

tip.golang.org

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Go 1.14 release notes

#31

Post by tandr »

e12e wrote: post #27
Scaevolus wrote: post #2

Maybe link the changelog instead? https://tip.golang.org/doc/go1.14 Selected changes: - This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. - Goroutines are now asynchronously preemptible. As a result, loops without function calls no longe…

> This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. Anyone happen to know why there used to be overhead here/what changed? From my comfortable sofa, it seems that there should be little difference between a defer-ed and direct call?

defer-ed calls are (in a very simplified way) pushed on a "stack" of methods to be called just before parent function exists. The mechanics of retrieval-call-repeat_if_more_available are cheap, but not free. They have reduced costs of these interactions.

Re: Go 1.14 release notes

#32

Post by sethammons »

> When the main module contains a top-level vendor directory and its go.mod file specifies go 1.14 or higher, the go command now defaults to -mod=vendor for operations that accept that flag.

Thank you! Modules and vendoring has been a royal pain. This should help a lot.

Re: Go 1.14 release notes

#33

Post by typical182 »

typical182 wrote: post #12
Scaevolus wrote: post #2

Maybe link the changelog instead? https://tip.golang.org/doc/go1.14 Selected changes: - This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. - Goroutines are now asynchronously preemptible. As a result, loops without function calls no longe…

As far as I understand, I don't think it is officially released as of this moment. (It is getting close, though). For example, as of now, the standard release note url for 1.14 currently 404s: https://golang.org/doc/go1.14

It looks like it has been released now.

Re: Go 1.14 release notes

#34

Post by Scaevolus »

e12e wrote: post #27
Scaevolus wrote: post #2

Maybe link the changelog instead? https://tip.golang.org/doc/go1.14 Selected changes: - This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. - Goroutines are now asynchronously preemptible. As a result, loops without function calls no longe…

> This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. Anyone happen to know why there used to be overhead here/what changed? From my comfortable sofa, it seems that there should be little difference between a defer-ed and direct call?

Defers can happen in a loop, so you need a stack for correctness. This change is that the compiler will now automatically inline the defer-ed call so they appear much the same as a direct call at the end of a function if they happen at most once.

The full design doc is here: https://github.com/golang/proposal/blob/master/design/34481-...

> Go 1.13 implements the defer statement by calling into the runtime to push a "defer object" onto the defer chain. Then, in any function that contains defer statements, the compiler inserts a call to runtime.deferreturn at every function exit point to unwind that function's defers.

> We propose optimizing deferred calls in functions where every defer is executed at most once (specifically, a defer may be on a conditional path, but is never in a loop in the control-flow graph). In this optimization, the compiler assigns a bit for every defer site to indicate whether that defer had been reached or not. The defer statement itself simply sets the corresponding bit and stores all necessary arguments in specific stack slots. Then, at every exit point of the function, the compiler open-codes each deferred call, protected by (and clearing) each corresponding bit.

Re: Go 1.14 release notes

#35

Post by jpdb »

Wish the json.Register funcion had been in 1.14. Desperately need it for a project I'm working on. If anyone has any ideas for overriding structs in a pkg I'd love to hear them!

Re: Go 1.14 release notes

#36

Post by kstenerud »

Go with warning flag patch also upgraded to 1.14: https://github.com/kstenerud/go#the-go-programming-language

The warning flag patch allows you to do:

    go build -gcflags=-warnunused
    go test -gcflags=-warnunused
which causes the compiler to only warn about unused things instead of stopping the build:

    $ go test -gcflags=-warnunused
    # github.com/kstenerud/go-describe
    ./describe_unsafe.go:8:2: Warning: imported and not used: "fmt"
    ./describe.go:329:2: Warning: isInUnsignedArray declared but not used

    ...

    PASS
    ok   github.com/kstenerud/go-describe 0.002s
I use this when debugging or for exploratory coding.

Re: Go 1.14 release notes

#37

Post by tapirl »

jhoechtl wrote: post #23
Scaevolus wrote: post #2

Maybe link the changelog instead? https://tip.golang.org/doc/go1.14 Selected changes: - This release improves the performance of most uses of defer to incur almost zero overhead compared to calling the deferred function directly. As a result, defer can now be used in performance-critical code without overhead concerns. - Goroutines are now asynchronously preemptible. As a result, loops without function calls no longe…

> Goroutines are now asynchronously preemptible. As a result, loops without function calls no longer potentially deadlock the scheduler or significantly delay garbage collection. What does that mean in practice? Can I perform expensive calculations in parallel exhausting all cores?

It means the following program will happily exit now.

  package main
  
  import (
    "time"
    "runtime"
  )
  
  func main(){
    for i := runtime.NumCPU(); i > 0; i-- {
      go func() {
        for {}
      }()
    }
    time.Sleep(time.Second)
    println("bye")
  }

Re: Go 1.14 release notes

#40

Post by mappu »

jpdb wrote: post #35

Wish the json.Register funcion had been in 1.14. Desperately need it for a project I'm working on. If anyone has any ideas for overriding structs in a pkg I'd love to hear them!

For others following along - this is https://github.com/golang/go/issues/5901 to register custom marshallers on an existing `json.Encoder` instance.

I feel like it's generally possible to work around this by creating a wrapper struct with an overridden MarshalJSON method? But maybe that's infeasible for deeply nested structs.

Post reply on HN