An error occurred fetching the project authors.
  1. 17 Oct, 2015 1 commit
    • Michael Hudson-Doyle's avatar
      cmd/link: always disable lazy PLT resolution when dynamically linking Go · 69a99ccc
      Michael Hudson-Doyle authored
      Go cannot allow lazy PLT resolution when calling between Go functions because
      the lazy resolution can use more stack than is available. Lazy resolution is
      disabled by passing -z now to the system linker, but unfortunately was only
      passed when linking to a Go shared library. That sounds fine, but the shared
      library containing the runtime is not linked to any other Go shared library but
      calls main.init and main.main via a PLT, and before this fix this did use lazy
      resolution. (For some reason this never caused a problem on intel, but it
      breaks on ppc64le). Fortunately the fix is very simple: always pass -z now to
      the system linker when dynamically linking Go.
      
      Change-Id: I7806d40aac80dcd1e56b95864d1cfeb1c42614e2
      Reviewed-on: https://go-review.googlesource.com/15870Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      69a99ccc
  2. 08 Oct, 2015 2 commits
  3. 16 Sep, 2015 1 commit
  4. 08 Sep, 2015 2 commits
  5. 04 Sep, 2015 3 commits
  6. 03 Sep, 2015 2 commits
  7. 01 Sep, 2015 1 commit
  8. 25 Aug, 2015 1 commit
  9. 29 Jul, 2015 1 commit
    • Russ Cox's avatar
      cmd/link: fix nosplit stack overflow checks · 767e0658
      Russ Cox authored
      The nosplit stack overflow checks were confused about morestack.
      The comment about not having correct SP information at the call
      to morestack was true, but that was a real bug, not something to
      work around. I fixed that problem in CL 12144. With that fixed,
      no need to special-case morestack in the way done here.
      
      This cleanup and simplification of the code was the first step
      to fixing a bug that happened when I started working on the
      arm64 frame size adjustments, but the cleanup was sufficient
      to make the bug go away.
      
      For #9880.
      
      Change-Id: I16b69a5c16b6b8cb4090295d3029c42d606e3b9b
      Reviewed-on: https://go-review.googlesource.com/12846Reviewed-by: default avatarAustin Clements <austin@google.com>
      767e0658
  10. 23 Jul, 2015 2 commits
  11. 22 Jul, 2015 1 commit
  12. 21 Jul, 2015 1 commit
  13. 29 Jun, 2015 1 commit
  14. 19 Jun, 2015 1 commit
  15. 16 Jun, 2015 1 commit
  16. 09 Jun, 2015 1 commit
  17. 05 Jun, 2015 2 commits
  18. 04 Jun, 2015 1 commit
    • Josh Bleecher Snyder's avatar
      cmd/link: make stkcheck more flexible · ca19e55f
      Josh Bleecher Snyder authored
      stkcheck is flow-insensitive: It processes calls in PC order.
      Since morestack was always the first call in a function,
      it was a safe, conservative approximation to simply adjust stack
      space as we went, recognizing morestack when it showed up.
      
      Subsequent CLS will rearrange the function prologue;
      morestack may no longer be the first call in a function.
      
      Introducing flow-sensitivity to stkcheck would allow this,
      and possibly allow a smaller stackguard.
      It is also a high risk change and possibly expensive.
      
      Instead, assume that all calls to morestack occur as
      part of the function prologue, no matter where they
      are located in the program text.
      
      Updates #10587.
      
      Change-Id: I4dcdd4256a980fc4bc433a68a10989ff57f7034f
      Reviewed-on: https://go-review.googlesource.com/10496
      Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: default avatarRuss Cox <rsc@golang.org>
      ca19e55f
  19. 28 May, 2015 1 commit
  20. 27 May, 2015 4 commits
    • Michael Hudson-Doyle's avatar
      cmd/internal/ld: do not depend on local symbols to read a type's gcdata · c949cff6
      Michael Hudson-Doyle authored
      We already read the address of a gcmask/gcprog out of the type data, but I
      didn't know how many bytes to read. But it turns out that it's easy to
      calculate, so change to do that. This means that we no longer depend on the
      local symbols being present, allowing me to strip the shared libraries for
      distribution and make them a lot smaller.
      
      As a bonus, this makes LSym another 24 bytes smaller, down to 296 bytes now.
      
      Change-Id: I379d359e28d63afae6753efd23efdf1fbb716992
      Reviewed-on: https://go-review.googlesource.com/10377Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      c949cff6
    • Michael Hudson-Doyle's avatar
      cmd/internal/ld: store the libraries a shared library was linked against in a note · bcc1870f
      Michael Hudson-Doyle authored
      The motivation for this is the innocuous looking test case that is added. This
      creates a stack exe -> libdep2.so -> libdep.so -> libruntime.so. The problem
      comes from the fact that a function from libdep.so gets inlined all the way
      into exe. This (unsurprisingly) means that the object file for exe references
      symbols from libdep.so, which means that -ldep needs to be passed when linking
      exe and it isn't. The fix is simply to pass it -- there is no harm in passing
      it when it's not needed.
      
      The thing is, it's not clear at all in the current code to see how the linker
      can know that libdep2 is linked against libdep. It could look through the
      DT_NEEDED entries in libdep2 and try to guess which are Go libraries, but it
      feels better to be explicit. So this adds another SHT_NOTE section that lists
      the shared libraries a shared library was linked against, and makes sure the
      complete set of depended upon shared libraries is passed to the external
      linker.
      
      Change-Id: I79aa6f98b4db4721d657a7eb7b7f062269bf49e2
      Reviewed-on: https://go-review.googlesource.com/10376Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      Run-TryBot: Ian Lance Taylor <iant@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      bcc1870f
    • Michael Hudson-Doyle's avatar
      cmd/link/internal/ld: put abi hash into a note · 65518032
      Michael Hudson-Doyle authored
      This makes for a more stable API for tools (including cmd/link itself) to
      extract the abi hash from a shared library and makes it possible at all for a
      library that has had the local symbol table removed.
      
      The existing note-writing code only supports writing notes into the very start
      of the object file so they are easy to find in core dumps. This doesn't apply
      to the "go" notes and means that all notes have to fit into a fixed size
      budget. That's annoying now we have more notes (and the next CL will add
      another one) so this does a little bit of work to make adding notes that do not
      have to go at the start of the file easier and moves the writing of the package
      list note over to that mechanism, which lets me revert a hack that increased
      the size budget mentioned above for -buildmode=shared builds.
      
      Change-Id: I6077a68d395c8a2bc43dec8506e73c71ef77d9b9
      Reviewed-on: https://go-review.googlesource.com/10375Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      65518032
    • Michael Hudson-Doyle's avatar
      cmd/link: replace interface{} fields with concrete types · cf2736c4
      Michael Hudson-Doyle authored
      The LSym.Section and Section.Elfsect fields were defined as interface{} but
      always had the same concrete type (*Section and *ElfShdr respectively) so just
      define them with that type. Reduces size of LSym from 328 to 320 bytes and
      reduces best-of-10 maxresident size from 246028k to 238036k when linking
      libstd.so.
      
      Change-Id: Ie7112c53e4c2c7ce5fe233b81372aa5633f572e8
      Reviewed-on: https://go-review.googlesource.com/10410Reviewed-by: default avatarMinux Ma <minux@golang.org>
      Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      cf2736c4
  21. 26 May, 2015 1 commit
  22. 21 May, 2015 3 commits
  23. 19 May, 2015 2 commits
  24. 16 May, 2015 1 commit
    • Russ Cox's avatar
      runtime: replace GC programs with simpler encoding, faster decoder · 512f75e8
      Russ Cox authored
      Small types record the location of pointers in their memory layout
      by using a simple bitmap. In Go 1.4 the bitmap held 4-bit entries,
      and in Go 1.5 the bitmap holds 1-bit entries, but in both cases using
      a bitmap for a large type containing arrays does not make sense:
      if someone refers to the type [1<<28]*byte in a program in such
      a way that the type information makes it into the binary, it would be
      a waste of space to write a 128 MB (for 4-bit entries) or even 32 MB
      (for 1-bit entries) bitmap full of 1s into the binary or even to keep
      one in memory during the execution of the program.
      
      For large types containing arrays, it is much more compact to describe
      the locations of pointers using a notation that can express repetition
      than to lay out a bitmap of pointers. Go 1.4 included such a notation,
      called ``GC programs'' but it was complex, required recursion during
      decoding, and was generally slow. Dmitriy measured the execution of
      these programs writing directly to the heap bitmap as being 7x slower
      than copying from a preunrolled 4-bit mask (and frankly that code was
      not terribly fast either). For some tests, unrollgcprog1 was seen costing
      as much as 3x more than the rest of malloc combined.
      
      This CL introduces a different form for the GC programs. They use a
      simple Lempel-Ziv-style encoding of the 1-bit pointer information,
      in which the only operations are (1) emit the following n bits
      and (2) repeat the last n bits c more times. This encoding can be
      generated directly from the Go type information (using repetition
      only for arrays or large runs of non-pointer data) and it can be decoded
      very efficiently. In particular the decoding requires little state and
      no recursion, so that the entire decoding can run without any memory
      accesses other than the reads of the encoding and the writes of the
      decoded form to the heap bitmap. For recursive types like arrays of
      arrays of arrays, the inner instructions are only executed once, not
      n times, so that large repetitions run at full speed. (In contrast, large
      repetitions in the old programs repeated the individual bit-level layout
      of the inner data over and over.) The result is as much as 25x faster
      decoding compared to the old form.
      
      Because the old decoder was so slow, Go 1.4 had three (or so) cases
      for how to set the heap bitmap bits for an allocation of a given type:
      
      (1) If the type had an even number of words up to 32 words, then
      the 4-bit pointer mask for the type fit in no more than 16 bytes;
      store the 4-bit pointer mask directly in the binary and copy from it.
      
      (1b) If the type had an odd number of words up to 15 words, then
      the 4-bit pointer mask for the type, doubled to end on a byte boundary,
      fit in no more than 16 bytes; store that doubled mask directly in the
      binary and copy from it.
      
      (2) If the type had an even number of words up to 128 words,
      or an odd number of words up to 63 words (again due to doubling),
      then the 4-bit pointer mask would fit in a 64-byte unrolled mask.
      Store a GC program in the binary, but leave space in the BSS for
      the unrolled mask. Execute the GC program to construct the mask the
      first time it is needed, and thereafter copy from the mask.
      
      (3) Otherwise, store a GC program and execute it to write directly to
      the heap bitmap each time an object of that type is allocated.
      (This is the case that was 7x slower than the other two.)
      
      Because the new pointer masks store 1-bit entries instead of 4-bit
      entries and because using the decoder no longer carries a significant
      overhead, after this CL (that is, for Go 1.5) there are only two cases:
      
      (1) If the type is 128 words or less (no condition about odd or even),
      store the 1-bit pointer mask directly in the binary and use it to
      initialize the heap bitmap during malloc. (Implemented in CL 9702.)
      
      (2) There is no case 2 anymore.
      
      (3) Otherwise, store a GC program and execute it to write directly to
      the heap bitmap each time an object of that type is allocated.
      
      Executing the GC program directly into the heap bitmap (case (3) above)
      was disabled for the Go 1.5 dev cycle, both to avoid needing to use
      GC programs for typedmemmove and to avoid updating that code as
      the heap bitmap format changed. Typedmemmove no longer uses this
      type information; as of CL 9886 it uses the heap bitmap directly.
      Now that the heap bitmap format is stable, we reintroduce GC programs
      and their space savings.
      
      Benchmarks for heapBitsSetType, before this CL vs this CL:
      
      name                    old mean               new mean              delta
      SetTypePtr              7.59ns × (0.99,1.02)   5.16ns × (1.00,1.00)  -32.05% (p=0.000)
      SetTypePtr8             21.0ns × (0.98,1.05)   21.4ns × (1.00,1.00)     ~    (p=0.179)
      SetTypePtr16            24.1ns × (0.99,1.01)   24.6ns × (1.00,1.00)   +2.41% (p=0.001)
      SetTypePtr32            31.2ns × (0.99,1.01)   32.4ns × (0.99,1.02)   +3.72% (p=0.001)
      SetTypePtr64            45.2ns × (1.00,1.00)   47.2ns × (1.00,1.00)   +4.42% (p=0.000)
      SetTypePtr126           75.8ns × (0.99,1.01)   79.1ns × (1.00,1.00)   +4.25% (p=0.000)
      SetTypePtr128           74.3ns × (0.99,1.01)   77.6ns × (1.00,1.01)   +4.55% (p=0.000)
      SetTypePtrSlice          726ns × (1.00,1.01)    712ns × (1.00,1.00)   -1.95% (p=0.001)
      SetTypeNode1            20.0ns × (0.99,1.01)   20.7ns × (1.00,1.00)   +3.71% (p=0.000)
      SetTypeNode1Slice        112ns × (1.00,1.00)    113ns × (0.99,1.00)     ~    (p=0.070)
      SetTypeNode8            23.9ns × (1.00,1.00)   24.7ns × (1.00,1.01)   +3.18% (p=0.000)
      SetTypeNode8Slice        294ns × (0.99,1.02)    287ns × (0.99,1.01)   -2.38% (p=0.015)
      SetTypeNode64           52.8ns × (0.99,1.03)   51.8ns × (0.99,1.01)     ~    (p=0.069)
      SetTypeNode64Slice      1.13µs × (0.99,1.05)   1.14µs × (0.99,1.00)     ~    (p=0.767)
      SetTypeNode64Dead       36.0ns × (1.00,1.01)   32.5ns × (0.99,1.00)   -9.67% (p=0.000)
      SetTypeNode64DeadSlice  1.43µs × (0.99,1.01)   1.40µs × (1.00,1.00)   -2.39% (p=0.001)
      SetTypeNode124          75.7ns × (1.00,1.01)   79.0ns × (1.00,1.00)   +4.44% (p=0.000)
      SetTypeNode124Slice     1.94µs × (1.00,1.01)   2.04µs × (0.99,1.01)   +4.98% (p=0.000)
      SetTypeNode126          75.4ns × (1.00,1.01)   77.7ns × (0.99,1.01)   +3.11% (p=0.000)
      SetTypeNode126Slice     1.95µs × (0.99,1.01)   2.03µs × (1.00,1.00)   +3.74% (p=0.000)
      SetTypeNode128          85.4ns × (0.99,1.01)  122.0ns × (1.00,1.00)  +42.89% (p=0.000)
      SetTypeNode128Slice     2.20µs × (1.00,1.01)   2.36µs × (0.98,1.02)   +7.48% (p=0.001)
      SetTypeNode130          83.3ns × (1.00,1.00)  123.0ns × (1.00,1.00)  +47.61% (p=0.000)
      SetTypeNode130Slice     2.30µs × (0.99,1.01)   2.40µs × (0.98,1.01)   +4.37% (p=0.000)
      SetTypeNode1024          498ns × (1.00,1.00)    537ns × (1.00,1.00)   +7.96% (p=0.000)
      SetTypeNode1024Slice    15.5µs × (0.99,1.01)   17.8µs × (1.00,1.00)  +15.27% (p=0.000)
      
      The above compares always using a cached pointer mask (and the
      corresponding waste of memory) against using the programs directly.
      Some slowdown is expected, in exchange for having a better general algorithm.
      The GC programs kick in for SetTypeNode128, SetTypeNode130, SetTypeNode1024,
      along with the slice variants of those.
      It is possible that the cutoff of 128 words (bits) should be raised
      in a followup CL, but even with this low cutoff the GC programs are
      faster than Go 1.4's "fast path" non-GC program case.
      
      Benchmarks for heapBitsSetType, Go 1.4 vs this CL:
      
      name                    old mean              new mean              delta
      SetTypePtr              6.89ns × (1.00,1.00)  5.17ns × (1.00,1.00)  -25.02% (p=0.000)
      SetTypePtr8             25.8ns × (0.97,1.05)  21.5ns × (1.00,1.00)  -16.70% (p=0.000)
      SetTypePtr16            39.8ns × (0.97,1.02)  24.7ns × (0.99,1.01)  -37.81% (p=0.000)
      SetTypePtr32            68.8ns × (0.98,1.01)  32.2ns × (1.00,1.01)  -53.18% (p=0.000)
      SetTypePtr64             130ns × (1.00,1.00)    47ns × (1.00,1.00)  -63.67% (p=0.000)
      SetTypePtr126            241ns × (0.99,1.01)    79ns × (1.00,1.01)  -67.25% (p=0.000)
      SetTypePtr128           2.07µs × (1.00,1.00)  0.08µs × (1.00,1.00)  -96.27% (p=0.000)
      SetTypePtrSlice         1.05µs × (0.99,1.01)  0.72µs × (0.99,1.02)  -31.70% (p=0.000)
      SetTypeNode1            16.0ns × (0.99,1.01)  20.8ns × (0.99,1.03)  +29.91% (p=0.000)
      SetTypeNode1Slice        184ns × (0.99,1.01)   112ns × (0.99,1.01)  -39.26% (p=0.000)
      SetTypeNode8            29.5ns × (0.97,1.02)  24.6ns × (1.00,1.00)  -16.50% (p=0.000)
      SetTypeNode8Slice        624ns × (0.98,1.02)   285ns × (1.00,1.00)  -54.31% (p=0.000)
      SetTypeNode64            135ns × (0.96,1.08)    52ns × (0.99,1.02)  -61.32% (p=0.000)
      SetTypeNode64Slice      3.83µs × (1.00,1.00)  1.14µs × (0.99,1.01)  -70.16% (p=0.000)
      SetTypeNode64Dead        134ns × (0.99,1.01)    32ns × (1.00,1.01)  -75.74% (p=0.000)
      SetTypeNode64DeadSlice  3.83µs × (0.99,1.00)  1.40µs × (1.00,1.01)  -63.42% (p=0.000)
      SetTypeNode124           240ns × (0.99,1.01)    79ns × (1.00,1.01)  -67.05% (p=0.000)
      SetTypeNode124Slice     7.27µs × (1.00,1.00)  2.04µs × (1.00,1.00)  -71.95% (p=0.000)
      SetTypeNode126          2.06µs × (0.99,1.01)  0.08µs × (0.99,1.01)  -96.23% (p=0.000)
      SetTypeNode126Slice     64.4µs × (1.00,1.00)   2.0µs × (1.00,1.00)  -96.85% (p=0.000)
      SetTypeNode128          2.09µs × (1.00,1.01)  0.12µs × (1.00,1.00)  -94.15% (p=0.000)
      SetTypeNode128Slice     65.4µs × (1.00,1.00)   2.4µs × (0.99,1.03)  -96.39% (p=0.000)
      SetTypeNode130          2.11µs × (1.00,1.00)  0.12µs × (1.00,1.00)  -94.18% (p=0.000)
      SetTypeNode130Slice     66.3µs × (1.00,1.00)   2.4µs × (0.97,1.08)  -96.34% (p=0.000)
      SetTypeNode1024         16.0µs × (1.00,1.01)   0.5µs × (1.00,1.00)  -96.65% (p=0.000)
      SetTypeNode1024Slice     512µs × (1.00,1.00)    18µs × (0.98,1.04)  -96.45% (p=0.000)
      
      SetTypeNode124 uses a 124 data + 2 ptr = 126-word allocation.
      Both Go 1.4 and this CL are using pointer bitmaps for this case,
      so that's an overall 3x speedup for using pointer bitmaps.
      
      SetTypeNode128 uses a 128 data + 2 ptr = 130-word allocation.
      Both Go 1.4 and this CL are running the GC program for this case,
      so that's an overall 17x speedup when using GC programs (and
      I've seen >20x on other systems).
      
      Comparing Go 1.4's SetTypeNode124 (pointer bitmap) against
      this CL's SetTypeNode128 (GC program), the slow path in the
      code in this CL is 2x faster than the fast path in Go 1.4.
      
      The Go 1 benchmarks are basically unaffected compared to just before this CL.
      
      Go 1 benchmarks, before this CL vs this CL:
      
      name                   old mean              new mean              delta
      BinaryTree17            5.87s × (0.97,1.04)   5.91s × (0.96,1.04)    ~    (p=0.306)
      Fannkuch11              4.38s × (1.00,1.00)   4.37s × (1.00,1.01)  -0.22% (p=0.006)
      FmtFprintfEmpty        90.7ns × (0.97,1.10)  89.3ns × (0.96,1.09)    ~    (p=0.280)
      FmtFprintfString        282ns × (0.98,1.04)   287ns × (0.98,1.07)  +1.72% (p=0.039)
      FmtFprintfInt           269ns × (0.99,1.03)   282ns × (0.97,1.04)  +4.87% (p=0.000)
      FmtFprintfIntInt        478ns × (0.99,1.02)   481ns × (0.99,1.02)  +0.61% (p=0.048)
      FmtFprintfPrefixedInt   399ns × (0.98,1.03)   400ns × (0.98,1.05)    ~    (p=0.533)
      FmtFprintfFloat         563ns × (0.99,1.01)   570ns × (1.00,1.01)  +1.37% (p=0.000)
      FmtManyArgs            1.89µs × (0.99,1.01)  1.92µs × (0.99,1.02)  +1.88% (p=0.000)
      GobDecode              15.2ms × (0.99,1.01)  15.2ms × (0.98,1.05)    ~    (p=0.609)
      GobEncode              11.6ms × (0.98,1.03)  11.9ms × (0.98,1.04)  +2.17% (p=0.000)
      Gzip                    648ms × (0.99,1.01)   648ms × (1.00,1.01)    ~    (p=0.835)
      Gunzip                  142ms × (1.00,1.00)   143ms × (1.00,1.01)    ~    (p=0.169)
      HTTPClientServer       90.5µs × (0.98,1.03)  91.5µs × (0.98,1.04)  +1.04% (p=0.045)
      JSONEncode             31.5ms × (0.98,1.03)  31.4ms × (0.98,1.03)    ~    (p=0.549)
      JSONDecode              111ms × (0.99,1.01)   107ms × (0.99,1.01)  -3.21% (p=0.000)
      Mandelbrot200          6.01ms × (1.00,1.00)  6.01ms × (1.00,1.00)    ~    (p=0.878)
      GoParse                6.54ms × (0.99,1.02)  6.61ms × (0.99,1.03)  +1.08% (p=0.004)
      RegexpMatchEasy0_32     160ns × (1.00,1.01)   161ns × (1.00,1.00)  +0.40% (p=0.000)
      RegexpMatchEasy0_1K     560ns × (0.99,1.01)   559ns × (0.99,1.01)    ~    (p=0.088)
      RegexpMatchEasy1_32     138ns × (0.99,1.01)   138ns × (1.00,1.00)    ~    (p=0.380)
      RegexpMatchEasy1_1K     877ns × (1.00,1.00)   878ns × (1.00,1.00)    ~    (p=0.157)
      RegexpMatchMedium_32    251ns × (0.99,1.00)   251ns × (1.00,1.01)  +0.28% (p=0.021)
      RegexpMatchMedium_1K   72.6µs × (1.00,1.00)  72.6µs × (1.00,1.00)    ~    (p=0.539)
      RegexpMatchHard_32     3.84µs × (1.00,1.00)  3.84µs × (1.00,1.00)    ~    (p=0.378)
      RegexpMatchHard_1K      117µs × (1.00,1.00)   117µs × (1.00,1.00)    ~    (p=0.067)
      Revcomp                 904ms × (0.99,1.02)   904ms × (0.99,1.01)    ~    (p=0.943)
      Template                125ms × (0.99,1.02)   127ms × (0.99,1.01)  +1.79% (p=0.000)
      TimeParse               627ns × (0.99,1.01)   622ns × (0.99,1.01)  -0.88% (p=0.000)
      TimeFormat              655ns × (0.99,1.02)   655ns × (0.99,1.02)    ~    (p=0.976)
      
      For the record, Go 1 benchmarks, Go 1.4 vs this CL:
      
      name                   old mean              new mean              delta
      BinaryTree17            4.61s × (0.97,1.05)   5.91s × (0.98,1.03)  +28.35% (p=0.000)
      Fannkuch11              4.40s × (0.99,1.03)   4.41s × (0.99,1.01)     ~    (p=0.212)
      FmtFprintfEmpty         102ns × (0.99,1.01)    84ns × (0.99,1.02)  -18.38% (p=0.000)
      FmtFprintfString        302ns × (0.98,1.01)   303ns × (0.99,1.02)     ~    (p=0.203)
      FmtFprintfInt           313ns × (0.97,1.05)   270ns × (0.99,1.01)  -13.69% (p=0.000)
      FmtFprintfIntInt        524ns × (0.98,1.02)   477ns × (0.99,1.00)   -8.87% (p=0.000)
      FmtFprintfPrefixedInt   424ns × (0.98,1.02)   386ns × (0.99,1.01)   -8.96% (p=0.000)
      FmtFprintfFloat         652ns × (0.98,1.02)   594ns × (0.97,1.05)   -8.97% (p=0.000)
      FmtManyArgs            2.13µs × (0.99,1.02)  1.94µs × (0.99,1.01)   -8.92% (p=0.000)
      GobDecode              17.1ms × (0.99,1.02)  14.9ms × (0.98,1.03)  -13.07% (p=0.000)
      GobEncode              13.5ms × (0.98,1.03)  11.5ms × (0.98,1.03)  -15.25% (p=0.000)
      Gzip                    656ms × (0.99,1.02)   647ms × (0.99,1.01)   -1.29% (p=0.000)
      Gunzip                  143ms × (0.99,1.02)   144ms × (0.99,1.01)     ~    (p=0.204)
      HTTPClientServer       88.2µs × (0.98,1.02)  90.8µs × (0.98,1.01)   +2.93% (p=0.000)
      JSONEncode             32.2ms × (0.98,1.02)  30.9ms × (0.97,1.04)   -4.06% (p=0.001)
      JSONDecode              121ms × (0.98,1.02)   110ms × (0.98,1.05)   -8.95% (p=0.000)
      Mandelbrot200          6.06ms × (0.99,1.01)  6.11ms × (0.98,1.04)     ~    (p=0.184)
      GoParse                6.76ms × (0.97,1.04)  6.58ms × (0.98,1.05)   -2.63% (p=0.003)
      RegexpMatchEasy0_32     195ns × (1.00,1.01)   155ns × (0.99,1.01)  -20.43% (p=0.000)
      RegexpMatchEasy0_1K     479ns × (0.98,1.03)   535ns × (0.99,1.02)  +11.59% (p=0.000)
      RegexpMatchEasy1_32     169ns × (0.99,1.02)   131ns × (0.99,1.03)  -22.44% (p=0.000)
      RegexpMatchEasy1_1K    1.53µs × (0.99,1.01)  0.87µs × (0.99,1.02)  -43.07% (p=0.000)
      RegexpMatchMedium_32    334ns × (0.99,1.01)   242ns × (0.99,1.01)  -27.53% (p=0.000)
      RegexpMatchMedium_1K    125µs × (1.00,1.01)    72µs × (0.99,1.03)  -42.53% (p=0.000)
      RegexpMatchHard_32     6.03µs × (0.99,1.01)  3.79µs × (0.99,1.01)  -37.12% (p=0.000)
      RegexpMatchHard_1K      189µs × (0.99,1.02)   115µs × (0.99,1.01)  -39.20% (p=0.000)
      Revcomp                 935ms × (0.96,1.03)   926ms × (0.98,1.02)     ~    (p=0.083)
      Template                146ms × (0.97,1.05)   119ms × (0.99,1.01)  -18.37% (p=0.000)
      TimeParse               660ns × (0.99,1.01)   624ns × (0.99,1.02)   -5.43% (p=0.000)
      TimeFormat              670ns × (0.98,1.02)   710ns × (1.00,1.01)   +5.97% (p=0.000)
      
      This CL is a bit larger than I would like, but the compiler, linker, runtime,
      and package reflect all need to be in sync about the format of these programs,
      so there is no easy way to split this into independent changes (at least
      while keeping the build working at each change).
      
      Fixes #9625.
      Fixes #10524.
      
      Change-Id: I9e3e20d6097099d0f8532d1cb5b1af528804989a
      Reviewed-on: https://go-review.googlesource.com/9888Reviewed-by: default avatarAustin Clements <austin@google.com>
      Run-TryBot: Russ Cox <rsc@golang.org>
      512f75e8
  25. 15 May, 2015 3 commits