Skip to content

G
golang
Switch branch/tag
  1. 13 Apr, 2018 10 commits
    • Josh Bleecher Snyder's avatar
      debug/gosym: intern LineTable strings · e511f153
      Josh Bleecher Snyder authored 
      This cuts the allocated space while executing

go tool objdump -S `go tool -n compile`

by over 10%.

It also speeds it up slightly:

name              old time/op       new time/op       delta
ObjdumpSCompiler        9.03s ± 1%        8.88s ± 1%  -1.59%  (p=0.000 n=20+20)

Updates #24725

Change-Id: Ic6ef8e273ede589334ab6e07099ac2e5bdf990c9
Reviewed-on: https://go-review.googlesource.com/106798
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      e511f153
    • Jeremy Jackins's avatar
      encoding/json: make use of encodeStatePool in Marshal · c0547476
      Jeremy Jackins authored 
      On my system, this seems to be a significant win, with a major
reduction in allocations and minor speed improvement.

name           old time/op    new time/op    delta
CodeMarshal      9.75ms ± 3%    9.24ms ± 1%   -5.21%  (p=0.001 n=5+10)
CodeMarshal-4    4.98ms ± 1%    4.71ms ± 1%   -5.44%  (p=0.001 n=5+10)
CodeMarshal-8    4.80ms ± 0%    4.77ms ± 1%   -0.70%  (p=0.012 n=5+9)

name           old speed      new speed      delta
CodeMarshal     199MB/s ± 3%   210MB/s ± 1%   +5.46%  (p=0.001 n=5+10)
CodeMarshal-4   390MB/s ± 1%   412MB/s ± 1%   +5.76%  (p=0.001 n=5+10)
CodeMarshal-8   404MB/s ± 0%   407MB/s ± 1%   +0.70%  (p=0.012 n=5+9)

name           old alloc/op   new alloc/op   delta
CodeMarshal      4.59MB ± 0%    1.96MB ± 0%  -57.22%  (p=0.000 n=5+9)
CodeMarshal-4    4.59MB ± 0%    2.00MB ± 0%  -56.39%  (p=0.000 n=5+8)
CodeMarshal-8    4.59MB ± 0%    2.06MB ± 0%  -55.05%  (p=0.001 n=5+9)

name           old allocs/op  new allocs/op  delta
CodeMarshal        16.0 ± 0%       1.0 ± 0%  -93.75%  (p=0.000 n=5+10)
CodeMarshal-4      16.0 ± 0%       1.0 ± 0%  -93.75%  (p=0.000 n=5+10)
CodeMarshal-8      16.0 ± 0%       1.0 ± 0%  -93.75%  (p=0.000 n=5+10)

Change-Id: I9d09850d8227f523f861ae1b4ca248c4a4b16aaf
Reviewed-on: https://go-review.googlesource.com/84897Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      c0547476
    • Sebastien Binet's avatar
      os/user: fix build with "osusergo" build tag · 98dfd400
      Sebastien Binet authored 
      Fixes #24841
Updates #24845

Change-Id: I4a5c05f4cbf9692bd6cab48baf3cc51fa43fe5a9
Reviewed-on: https://go-review.googlesource.com/106837Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      98dfd400
    • Cherry Zhang's avatar
      all: use new softfloat on GOARM=5 · b08a9b7e
      Cherry Zhang authored 
      Use the new softfloat support in the compiler, originally added
for softfloat on MIPS. This support is portable, so we can just
use it for softfloat on ARM.

In the old softfloat support on ARM, the compiler generates
floating point instructions, then the assembler inserts calls
to _sfloat before FP instructions. _sfloat decodes the following
FP instructions and simulates them.

In the new scheme, the compiler generates runtime calls to do FP
operations at a higher level. It doesn't generate FP instructions,
and therefore the assembler won't insert _sfloat calls, i.e. the
old mechanism is automatically suppressed.

The old method may be still be triggered with assembly code
using FP instructions. In the standard library, the only
occurance is math/sqrt_arm.s, which is rewritten to call to the
Go implementation instead.

Some significant speedups for code using floating points:

name                     old time/op    new time/op     delta
BinaryTree17-4              37.1s ± 2%      37.3s ± 1%     ~     (p=0.105 n=10+10)
Fannkuch11-4                13.0s ± 0%      13.1s ± 0%   +0.46%  (p=0.000 n=10+10)
FmtFprintfEmpty-4           700ns ± 4%      734ns ± 6%   +4.84%  (p=0.009 n=10+10)
FmtFprintfString-4         1.22µs ± 3%     1.22µs ± 4%     ~     (p=0.897 n=10+10)
FmtFprintfInt-4            1.27µs ± 2%     1.30µs ± 1%   +1.91%  (p=0.001 n=10+9)
FmtFprintfIntInt-4         1.83µs ± 2%     1.81µs ± 3%     ~     (p=0.149 n=10+10)
FmtFprintfPrefixedInt-4    1.80µs ± 3%     1.81µs ± 2%     ~     (p=0.421 n=10+8)
FmtFprintfFloat-4          6.89µs ± 3%     3.59µs ± 2%  -47.93%  (p=0.000 n=10+10)
FmtManyArgs-4              6.39µs ± 1%     6.09µs ± 1%   -4.61%  (p=0.000 n=10+9)
GobDecode-4                 109ms ± 2%       81ms ± 2%  -25.99%  (p=0.000 n=9+10)
GobEncode-4                 109ms ± 2%       76ms ± 2%  -29.88%  (p=0.000 n=10+9)
Gzip-4                      3.61s ± 1%      3.59s ± 1%     ~     (p=0.247 n=10+10)
Gunzip-4                    449ms ± 4%      450ms ± 1%     ~     (p=0.230 n=10+7)
HTTPClientServer-4         1.55ms ± 3%     1.53ms ± 2%     ~     (p=0.400 n=9+10)
JSONEncode-4                356ms ± 1%      183ms ± 1%  -48.73%  (p=0.000 n=10+10)
JSONDecode-4                1.12s ± 2%      0.87s ± 1%  -21.88%  (p=0.000 n=10+10)
Mandelbrot200-4             5.49s ± 1%      2.55s ± 1%  -53.45%  (p=0.000 n=9+10)
GoParse-4                  49.6ms ± 2%     47.5ms ± 1%   -4.08%  (p=0.000 n=10+9)
RegexpMatchEasy0_32-4      1.13µs ± 4%     1.20µs ± 4%   +6.42%  (p=0.000 n=10+10)
RegexpMatchEasy0_1K-4      4.41µs ± 2%     4.44µs ± 2%     ~     (p=0.128 n=10+10)
RegexpMatchEasy1_32-4      1.15µs ± 5%     1.20µs ± 5%   +4.85%  (p=0.002 n=10+10)
RegexpMatchEasy1_1K-4      6.21µs ± 2%     6.37µs ± 4%   +2.62%  (p=0.001 n=9+10)
RegexpMatchMedium_32-4     1.58µs ± 5%     1.65µs ± 3%   +4.85%  (p=0.000 n=10+10)
RegexpMatchMedium_1K-4      341µs ± 3%      351µs ± 7%     ~     (p=0.573 n=8+10)
RegexpMatchHard_32-4       21.4µs ± 3%     21.5µs ± 5%     ~     (p=0.931 n=9+9)
RegexpMatchHard_1K-4        626µs ± 2%      626µs ± 1%     ~     (p=0.645 n=8+8)
Revcomp-4                  46.4ms ± 2%     47.4ms ± 2%   +2.07%  (p=0.000 n=10+10)
Template-4                  1.31s ± 3%      1.23s ± 4%   -6.13%  (p=0.000 n=10+10)
TimeParse-4                4.49µs ± 1%     4.41µs ± 2%   -1.81%  (p=0.000 n=10+9)
TimeFormat-4               9.31µs ± 1%     9.32µs ± 2%     ~     (p=0.561 n=9+9)

Change-Id: Iaeeff6c9a09c1b2c064d06e09dd88101dc02bfa4
Reviewed-on: https://go-review.googlesource.com/106735Reviewed-by: 's avatarAustin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      b08a9b7e
    • Hana Kim's avatar
      cmd/trace: change span id computation for trace view use · 1d8fc211
      Hana Kim authored 
      golang.org/cl/102697 attempted to fix the span presentation by utilizing
the position of the span in the span slices of a task. But it is
not complete either.

First, id=0 is omitted in json encoding and the trace viewer silently
drops entries with the missing id field, so we must avoid zero-value id.
Second, it is possible that a goroutine handles multiple tasks. Then,
id collisions will happen.

This takes a simpler approach - have a counter that increments for every
emitSpan call, and use the value as the id value.

Change-Id: Idaa9505634acf6d327c6f00af32d8260955b85e1
Reviewed-on: https://go-review.googlesource.com/106755Reviewed-by: 's avatarHeschi Kreinick <heschi@google.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      1d8fc211
    • fanzha02's avatar
      cmd/internal/obj/arm64: fix the bug of incorrect handling negative offset of LDP/STP/LDPW/STPW · 4d59b144
      fanzha02 authored 
      The current assembler will report error when the negative offset is in
the range of [-256, 0) and is not the multiples of 4/8.

The fix introduces C_NSAUTO_8, C_NSAUTO_4 and C_NAUTO4K. C_NPAUTO
includes C_NSAUTO_8 instead of C_NSAUTO, C_NAUTO4K includes C_NSAUTO_8,
C_NSAUTO_4 and C_NSAUTO. So that assembler will encode the negative offset
that is greater than -4095 and is not the multiples of 4/8 as two instructions.

Add the test cases.

Fixed #24471

Change-Id: I42f34e3b8a9fc52c9e8b41504294271aafade639
Reviewed-on: https://go-review.googlesource.com/102635
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      4d59b144
    • Cherry Zhang's avatar
      cmd/compile: in escape analysis, propagate loop depth to field · 5a91c83c
      Cherry Zhang authored 
      The escape analysis models "loop depth". If the address of an
expression is assigned to something defined at a lower (outer)
loop depth, the escape analysis decides it escapes. However, it
uses the loop depth of the address operator instead of where
the RHS is defined. This causes an unnecessary escape if there is
an assignment inside a loop but the RHS is defined outside the
loop. This CL propagates the loop depth.

Fixes #24730.

Change-Id: I5ff1530688bdfd90561a7b39c8be9bfc009a9dae
Reviewed-on: https://go-review.googlesource.com/105257
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      5a91c83c
    • Ian Lance Taylor's avatar
      runtime: document that LockOSThread in init locks to thread · eb4f3324
      Ian Lance Taylor authored 
      This is more or less implied by the spec language on initialization,
but restate it for clarity.

Fixes #23112

Change-Id: Ibe5385acafe4eac38823de98a025cd37f7a77d3b
Reviewed-on: https://go-review.googlesource.com/103399Reviewed-by: 's avatarAustin Clements <austin@google.com>
      eb4f3324
    • Ian Lance Taylor's avatar
      crypto/x509: don't return nil, nil from SystemCertPool · 2d4ccbfe
      Ian Lance Taylor authored 
      If there are no certs, return an empty pool, not nil.

Fixes #21405

Change-Id: Ib4ac9d5c4a8cef83dd53565b0707a63b73ba0a8b
Reviewed-on: https://go-review.googlesource.com/103596
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarFilippo Valsorda <filippo@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      2d4ccbfe
    • Ian Lance Taylor's avatar
      time: document that going to sleep may stop the monotonic clock · c96ac60b
      Ian Lance Taylor authored 
      Fixes #23178

Change-Id: I060a73d6263bc135f5a14c1991932a225208bb39
Reviewed-on: https://go-review.googlesource.com/103396Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      c96ac60b
  3. 12 Apr, 2018 14 commits
  5. 11 Apr, 2018 16 commits