- 05 Apr, 2018 14 commits
-
-
Hana Kim authored
Change-Id: Id4e3407ba497a018d5ace92813ba8e9653d0ac7d Reviewed-on: https://go-review.googlesource.com/104976Reviewed-by:
Heschi Kreinick <heschi@google.com> Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Carlos Eduardo Seo authored
This change improves performance of addVV, subVV and mulAddVWW by unrolling the loops, with improvements up to 1.45x. benchmark old ns/op new ns/op delta BenchmarkAddVV/1-16 5.79 5.85 +1.04% BenchmarkAddVV/2-16 6.41 6.62 +3.28% BenchmarkAddVV/3-16 6.89 7.35 +6.68% BenchmarkAddVV/4-16 7.47 8.26 +10.58% BenchmarkAddVV/5-16 8.04 8.18 +1.74% BenchmarkAddVV/10-16 10.9 11.2 +2.75% BenchmarkAddVV/100-16 81.7 57.0 -30.23% BenchmarkAddVV/1000-16 714 500 -29.97% BenchmarkAddVV/10000-16 7088 4946 -30.22% BenchmarkAddVV/100000-16 71514 49364 -30.97% BenchmarkSubVV/1-16 5.94 5.89 -0.84% BenchmarkSubVV/2-16 12.9 6.82 -47.13% BenchmarkSubVV/3-16 7.03 7.34 +4.41% BenchmarkSubVV/4-16 7.58 8.23 +8.58% BenchmarkSubVV/5-16 8.15 8.19 +0.49% BenchmarkSubVV/10-16 11.2 11.4 +1.79% BenchmarkSubVV/100-16 82.4 57.0 -30.83% BenchmarkSubVV/1000-16 715 499 -30.21% BenchmarkSubVV/10000-16 7089 4947 -30.22% BenchmarkSubVV/100000-16 71568 49378 -31.01% benchmark old MB/s new MB/s speedup BenchmarkAddVV/1-16 11048.49 10939.92 0.99x BenchmarkAddVV/2-16 19973.41 19323.60 0.97x BenchmarkAddVV/3-16 27847.09 26123.06 0.94x BenchmarkAddVV/4-16 34276.46 30976.54 0.90x BenchmarkAddVV/5-16 39781.92 39140.68 0.98x BenchmarkAddVV/10-16 58559.29 56894.68 0.97x BenchmarkAddVV/100-16 78354.88 112243.69 1.43x BenchmarkAddVV/1000-16 89592.74 127889.04 1.43x BenchmarkAddVV/10000-16 90292.39 129387.06 1.43x BenchmarkAddVV/100000-16 89492.92 129647.78 1.45x BenchmarkSubVV/1-16 10781.03 10861.22 1.01x BenchmarkSubVV/2-16 9949.27 18760.21 1.89x BenchmarkSubVV/3-16 27319.40 26166.01 0.96x BenchmarkSubVV/4-16 33764.35 31123.02 0.92x BenchmarkSubVV/5-16 39272.40 39050.31 0.99x BenchmarkSubVV/10-16 57262.87 56206.33 0.98x BenchmarkSubVV/100-16 77641.78 112280.86 1.45x BenchmarkSubVV/1000-16 89486.27 128064.08 1.43x BenchmarkSubVV/10000-16 90274.37 129356.59 1.43x BenchmarkSubVV/100000-16 89424.42 129610.50 1.45x Change-Id: I2795a82134d1e3b75e2634c76b8ca165a723ec7b Reviewed-on: https://go-review.googlesource.com/103495 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Lynn Boger <laboger@linux.vnet.ibm.com>
-
Joel Sing authored
OpenBSD's __threxit syscall takes a pointer to a 32-bit value that will be zeroed immediately before the thread exits. Make use of this instead of zeroing freeWait from the exitThread assembly and using hacks like switching to a static stack, so this works on 386. Change-Id: I3ec5ead82b6496404834d148f713794d5d9da723 Reviewed-on: https://go-review.googlesource.com/105055Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Austin Clements <austin@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ilya Tocar authored
Don't generate FP ops with 1 operand in memory for 387. Change-Id: I23b49dfa2a1e60c8778c920230e64785a3ddfbd1 Reviewed-on: https://go-review.googlesource.com/105035 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
Originally, scalar values were directly stored within interface values as long as they fit into a pointer-sized slot of memory. And since interface method calls always pass the full pointer-sized value as the receiver argument, value-narrowing wrappers were necessary to adapt to the calling convention for methods with smaller receiver types. However, for precise garbage collection, we now only store actual pointers within interface values, so these wrappers are no longer necessary. Passes toolstash-check. Change-Id: I5303bfeb8d0f11db619b5a5d06b37ac898588670 Reviewed-on: https://go-review.googlesource.com/104875 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
Mostly replacing C-Style loops with range expressions, but also other simplifications like the introduction of writeBool and unindenting some code. Passes toolstash -cmp on std cmd. Change-Id: I799bccd4e5d411428dcf122b8588a564a9217e7c Reviewed-on: https://go-review.googlesource.com/104936 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Marvin Stenger <marvin.stenger94@gmail.com> Reviewed-by:
Ilya Tocar <ilya.tocar@intel.com>
-
isharipo authored
- Unexport MaxLoopPad and LoopAlign; associated comments updated - Remove commented-out C code - Replace C-style /**/ code comments with single-line comments Change-Id: I51bd92a05b4d3823757b12efd798951c9f252bd4 Reviewed-on: https://go-review.googlesource.com/104795 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> Reviewed-by:
-
isharipo authored
VEX constants were used when instructions were added by hand. Now all VEX-encoded instructions are auto-generated by x86avxgen, so there is no need for those anymore. Change-Id: Ida63e5e23a8b819b15f61ac98980dec45a21617c Reviewed-on: https://go-review.googlesource.com/104775 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Daniel Martí <mvdan@mvdan.cc>
-
Ben Shi authored
Some integer/float binary operations of 386 can take a direct memory operand, which is more efficient than loading to a register. These CL does this optimization by copying the similar solution of amd64. And the go1 benchmark shows some inprovements, especially the test case Template. (excluding noise) name old time/op new time/op delta BinaryTree17-4 3.42s ± 2% 3.40s ± 2% ~ (p=0.069 n=38+39) Fannkuch11-4 3.48s ± 1% 3.53s ± 1% +1.59% (p=0.000 n=40+40) FmtFprintfEmpty-4 46.7ns ± 4% 46.3ns ± 3% -1.03% (p=0.001 n=40+40) FmtFprintfString-4 80.1ns ± 3% 80.6ns ± 3% +0.56% (p=0.029 n=40+40) FmtFprintfInt-4 92.4ns ± 2% 92.3ns ± 3% ~ (p=0.847 n=40+40) FmtFprintfIntInt-4 147ns ± 3% 144ns ± 3% -1.87% (p=0.000 n=40+40) FmtFprintfPrefixedInt-4 182ns ± 2% 184ns ± 3% +0.99% (p=0.002 n=40+40) FmtFprintfFloat-4 387ns ± 3% 384ns ± 3% ~ (p=0.069 n=40+40) FmtManyArgs-4 619ns ± 3% 616ns ± 3% ~ (p=0.320 n=40+40) GobDecode-4 7.28ms ± 6% 7.27ms ± 5% ~ (p=0.897 n=40+40) GobEncode-4 7.33ms ± 6% 7.21ms ± 6% -1.56% (p=0.022 n=38+40) Gzip-4 357ms ± 4% 357ms ± 4% ~ (p=0.071 n=40+40) Gunzip-4 45.3ms ± 3% 45.4ms ± 3% ~ (p=0.452 n=40+40) HTTPClientServer-4 63.0µs ± 2% 62.9µs ± 3% ~ (p=0.760 n=38+39) JSONEncode-4 22.0ms ± 4% 21.7ms ± 4% -1.49% (p=0.000 n=40+40) JSONDecode-4 67.7ms ± 4% 68.3ms ± 3% +0.86% (p=0.039 n=40+40) Mandelbrot200-4 5.16ms ± 3% 5.17ms ± 3% ~ (p=0.418 n=40+40) GoParse-4 3.30ms ± 2% 3.32ms ± 3% +0.55% (p=0.017 n=40+40) RegexpMatchEasy0_32-4 104ns ± 3% 104ns ± 4% ~ (p=0.992 n=40+40) RegexpMatchEasy0_1K-4 852ns ± 3% 851ns ± 2% ~ (p=0.344 n=40+40) RegexpMatchEasy1_32-4 113ns ± 4% 113ns ± 5% ~ (p=0.937 n=40+40) RegexpMatchEasy1_1K-4 1.03µs ± 5% 1.04µs ± 4% ~ (p=0.430 n=40+40) RegexpMatchMedium_32-4 132ns ± 4% 131ns ± 3% -1.06% (p=0.027 n=40+40) RegexpMatchMedium_1K-4 43.0µs ± 3% 43.2µs ± 3% ~ (p=0.122 n=40+40) RegexpMatchHard_32-4 2.21µs ± 4% 2.20µs ± 4% ~ (p=0.146 n=40+40) RegexpMatchHard_1K-4 67.1µs ± 4% 67.2µs ± 3% ~ (p=0.859 n=40+40) Revcomp-4 1.85s ± 2% 1.85s ± 3% ~ (p=0.184 n=40+40) Template-4 70.1ms ± 4% 67.5ms ± 3% -3.65% (p=0.000 n=40+40) TimeParse-4 457ns ±16% 439ns ± 4% ~ (p=0.683 n=40+34) TimeFormat-4 413ns ± 3% 414ns ± 3% ~ (p=0.850 n=40+40) [Geo mean] 67.5µs 67.3µs -0.38% name old speed new speed delta GobDecode-4 105MB/s ± 6% 106MB/s ± 5% ~ (p=0.893 n=40+40) GobEncode-4 105MB/s ± 6% 107MB/s ± 7% +1.60% (p=0.023 n=38+40) Gzip-4 54.4MB/s ± 4% 54.5MB/s ± 4% ~ (p=0.073 n=40+40) Gunzip-4 429MB/s ± 3% 428MB/s ± 3% ~ (p=0.453 n=40+40) JSONEncode-4 88.3MB/s ± 5% 89.6MB/s ± 4% +1.51% (p=0.000 n=40+40) JSONDecode-4 28.7MB/s ± 4% 28.4MB/s ± 3% -0.87% (p=0.039 n=40+40) GoParse-4 17.6MB/s ± 3% 17.5MB/s ± 3% -0.55% (p=0.020 n=40+40) RegexpMatchEasy0_32-4 308MB/s ± 4% 308MB/s ± 5% ~ (p=0.988 n=40+40) RegexpMatchEasy0_1K-4 1.20GB/s ± 3% 1.20GB/s ± 2% ~ (p=0.329 n=40+40) RegexpMatchEasy1_32-4 283MB/s ± 4% 283MB/s ± 4% ~ (p=0.507 n=40+40) RegexpMatchEasy1_1K-4 991MB/s ± 5% 987MB/s ± 4% ~ (p=0.446 n=40+40) RegexpMatchMedium_32-4 7.54MB/s ± 4% 7.63MB/s ± 3% +1.26% (p=0.004 n=40+40) RegexpMatchMedium_1K-4 23.8MB/s ± 3% 23.7MB/s ± 4% ~ (p=0.121 n=40+40) RegexpMatchHard_32-4 14.5MB/s ± 4% 14.6MB/s ± 4% ~ (p=0.145 n=40+40) RegexpMatchHard_1K-4 15.3MB/s ± 4% 15.2MB/s ± 3% ~ (p=0.874 n=40+40) Revcomp-4 137MB/s ± 2% 137MB/s ± 3% ~ (p=0.179 n=40+40) Template-4 27.7MB/s ± 4% 28.7MB/s ± 3% +3.78% (p=0.000 n=40+40) [Geo mean] 78.9MB/s 79.2MB/s +0.38% Change-Id: I3ba688c253b665485c1ebdf5a75f4ce82cc3def3 Reviewed-on: https://go-review.googlesource.com/102036 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Keith Randall <khr@golang.org>
-
isharipo authored
Fixes golint receiver name complaints. We can't go with "a" name as it sometimes is used for obj.Addr args. Change-Id: I66556f4e3dc42cfaaa4db3ed7772fa6756ea9a9b Reviewed-on: https://go-review.googlesource.com/104796 Run-TryBot: Iskander Sharipov <iskander.sharipov@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
While at it, also simplify a couple of switches. Doesn't pass toolstash -cmp on std cmd, because orderBlock(&n2.Nbody) is moved further down to the n3 loop. Change-Id: I20a2a6c21eb9a183a59572e0fca401a5041fc40a Reviewed-on: https://go-review.googlesource.com/104416 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com> Reviewed-by:
-
Daniel Martí authored
Since it's been reliably failing on one of the linux-arm builders (arm5spacemonkey) for a long time. Updates #24221. Change-Id: I8fccc7e16631de497ccc2c285e510a110a93ad95 Reviewed-on: https://go-review.googlesource.com/104535 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Alberto Donizetti authored
Stack-allocate a local worklist in the deadcode pass. A size of 64 for the pre-allocation is enough for >99% of the ReachableBlocks call in a typical package. name old time/op new time/op delta Template 281ms ± 3% 278ms ± 2% -1.03% (p=0.049 n=20+20) Unicode 135ms ± 6% 134ms ± 6% ~ (p=0.273 n=18+17) GoTypes 882ms ± 3% 880ms ± 2% ~ (p=0.925 n=20+20) Compiler 4.01s ± 1% 4.02s ± 2% ~ (p=0.640 n=20+20) SSA 9.61s ± 1% 9.75s ± 1% +1.39% (p=0.000 n=20+19) Flate 186ms ± 5% 185ms ± 7% ~ (p=0.758 n=20+20) GoParser 219ms ± 5% 218ms ± 4% ~ (p=0.149 n=20+20) Reflect 568ms ± 4% 562ms ± 1% ~ (p=0.154 n=19+19) Tar 258ms ± 2% 257ms ± 3% ~ (p=0.428 n=19+20) XML 316ms ± 2% 317ms ± 3% ~ (p=0.901 n=20+19) name old user-time/op new user-time/op delta Template 398ms ± 6% 388ms ± 6% -2.55% (p=0.007 n=20+20) Unicode 217ms ± 5% 213ms ± 6% -1.90% (p=0.036 n=17+20) GoTypes 1.21s ± 3% 1.20s ± 3% -0.89% (p=0.022 n=19+20) Compiler 5.56s ± 3% 5.53s ± 5% ~ (p=0.779 n=20+20) SSA 13.9s ± 5% 14.0s ± 4% ~ (p=0.529 n=20+20) Flate 248ms ±10% 252ms ± 4% ~ (p=0.409 n=20+18) GoParser 305ms ± 4% 299ms ± 5% -1.87% (p=0.007 n=19+20) Reflect 754ms ± 2% 747ms ± 3% ~ (p=0.107 n=20+19) Tar 360ms ± 5% 362ms ± 3% ~ (p=0.534 n=20+18) XML 425ms ± 6% 429ms ± 4% ~ (p=0.496 n=20+19) name old alloc/op new alloc/op delta Template 38.8MB ± 0% 38.7MB ± 0% -0.15% (p=0.000 n=20+20) Unicode 29.1MB ± 0% 29.1MB ± 0% -0.03% (p=0.000 n=20+20) GoTypes 115MB ± 0% 115MB ± 0% -0.13% (p=0.000 n=20+20) Compiler 491MB ± 0% 490MB ± 0% -0.15% (p=0.000 n=18+19) SSA 1.40GB ± 0% 1.40GB ± 0% -0.16% (p=0.000 n=20+20) Flate 24.9MB ± 0% 24.8MB ± 0% -0.17% (p=0.000 n=20+20) GoParser 30.7MB ± 0% 30.6MB ± 0% -0.16% (p=0.000 n=20+20) Reflect 77.1MB ± 0% 77.0MB ± 0% -0.11% (p=0.000 n=19+20) Tar 39.0MB ± 0% 39.0MB ± 0% -0.14% (p=0.000 n=20+20) XML 44.6MB ± 0% 44.5MB ± 0% -0.13% (p=0.000 n=17+19) name old allocs/op new allocs/op delta Template 379k ± 0% 378k ± 0% -0.45% (p=0.000 n=20+17) Unicode 336k ± 0% 336k ± 0% -0.08% (p=0.000 n=20+20) GoTypes 1.18M ± 0% 1.17M ± 0% -0.37% (p=0.000 n=20+20) Compiler 4.58M ± 0% 4.56M ± 0% -0.38% (p=0.000 n=20+20) SSA 11.4M ± 0% 11.4M ± 0% -0.39% (p=0.000 n=20+20) Flate 233k ± 0% 232k ± 0% -0.51% (p=0.000 n=20+20) GoParser 313k ± 0% 312k ± 0% -0.48% (p=0.000 n=19+20) Reflect 946k ± 0% 943k ± 0% -0.31% (p=0.000 n=20+20) Tar 388k ± 0% 387k ± 0% -0.40% (p=0.000 n=20+20) XML 411k ± 0% 409k ± 0% -0.35% (p=0.000 n=17+20) Change-Id: Iaec0b9471ded61be5eb3c9d1074e804672307644 Reviewed-on: https://go-review.googlesource.com/104675Reviewed-by:
-
Matthew Dempsky authored
Inl, Inldcl, and InlCost are only applicable to functions with bodies that can be inlined, so pull them out into a separate Inline type to make understanding them easier. A side benefit is that we can check if a function can be inlined by just checking if n.Func.Inl is non-nil, which simplifies handling of empty function bodies. While here, remove some unnecessary Curfn twiddling, and make imported functions use Inl.Dcl instead of Func.Dcl for consistency for local functions. Passes toolstash-check. Change-Id: Ifd4a80349d85d9e8e4484952b38ec4a63182e81f Reviewed-on: https://go-review.googlesource.com/104756 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
- 04 Apr, 2018 18 commits
-
-
Robert Griesemer authored
Noticed that we can simply use a []byte slice while investigating a separate issue. Did the obvious simplification. Change-Id: I921ebbb42135b5f1a10109236ceb9ae6e94ae7e2 Reviewed-on: https://go-review.googlesource.com/104757 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Chase authored
Stores to auto tmp variables can be hoisted to places where the line numbers make debugging look "jumpy". Turning those instructions into ones with is_stmt = 0 in the DWARF (accomplished by marking ssa nodes with NotStmt) makes debugging look better while still attributing the instructions with the correct line number. The same is true for certain register allocator spills and reloads. Change-Id: I97a394eb522d4911cc40b4bf5bf76d3d7221f6c0 Reviewed-on: https://go-review.googlesource.com/98415 Run-TryBot: David Chase <drchase@google.com> Reviewed-by:
Cherry Zhang <cherryyz@google.com> Reviewed-by:
-
David Chase authored
To improve debugging, instructions should be annotated with DWARF is_stmt. The DWARF default before was is_stmt=1, and to remove "jumpy" stepping the optimizer was tagging instructions with a no-position position, which interferes with the accuracy of profiling information. This allows that to be corrected, and also allows more "jumpy" positions to be annotated with is_stmt=0 (these changes were not made for 1.10 because of worries about further messing up profiling). The is_stmt values are placed in a pc-encoded table and passed through a symbol derived from the name of the function and processed in the linker alongside its processing of each function's pc/line tables. The only change in binary size is in the .debug_line tables measured with "objdump -h --section=.debug_line go1.test" For go1.test, these are 2614 bytes larger, or 0.72% of the size of .debug_line, or 0.025% of the file size. This will increase in proportion to how much the is_stmt flag is used (toggled). Change-Id: Ic1f1aeccff44591ad0494d29e1a0202a3c506a7a Reviewed-on: https://go-review.googlesource.com/93664 Run-TryBot: David Chase <drchase@google.com> Reviewed-by:
-
David Chase authored
Add IsStmt information to src.lico so that suitable lines for breakpoints (or not) can be noted, eventually for communication to the debugger via the linker and DWARF. The expectation is that the front end will apply statement boundary marks because it has best information about the input, and the optimizer will attempt to preserve these. The exact method for placing these marks is still TBD; ideally stopping "at" line N in unoptimized code will occur at a point where none of the side effects of N have occurred and all of the inputs for line N can still be observed. The optimizer will work with the same markings supplied for unoptimized code. It is a goal that non-optimizing compilation should conserve statement marks. The optimizer will also use the not-a-statement annotation to indicate instructions that have a line number (for profiling purposes) but should not be the target of debugger step, next, or breakpoints. Because instructions marked as statements are sometimes removed, a third value indicating that a position (instruction) can serve as a statement if the optimizer removes the current instruction marked as a statement for the same line. The optimizer should attempt to conserve statement marks, but it is not a bug if some are lost. Includes changes to html output for GOSSAFUNC to indicate not-default is-a-statement with bold and not-a-statement with strikethrough. Change-Id: Ia22c9a682f276e2ca2a4ef7a85d4b6ebf9c62b7f Reviewed-on: https://go-review.googlesource.com/93663 Run-TryBot: David Chase <drchase@google.com> Reviewed-by:
-
Robert Griesemer authored
The go/printer (and thus gofmt) uses a heuristic to determine whether to break alignment between elements of an expression list which is spread across multiple lines. The heuristic only kicked in if the entry sizes (character length) was above a certain threshold (20) and the ratio between the previous and current entry size was above a certain value (4). This heuristic worked reasonably most of the time, but also led to unfortunate breaks in many cases where a single entry was suddenly much smaller (or larger) then the previous one. The behavior of gofmt was sufficiently mysterious in some of these situations that many issues were filed against it. The simplest solution to address this problem is to remove the heuristic altogether and have a programmer introduce empty lines to force different alignments if it improves readability. The problem with that approach is that the places where it really matters, very long tables with many (hundreds, or more) entries, may be machine-generated and not "post-processed" by a human (e.g., unicode/utf8/tables.go). If a single one of those entries is overlong, the result would be that the alignment would force all comments or values in key:value pairs to be adjusted to that overlong value, making the table hard to read (e.g., that entry may not even be visible on screen and all other entries seem spaced out too wide). Instead, we opted for a slightly improved heuristic that behaves much better for "normal", human-written code. 1) The threshold is increased from 20 to 40. This disables the heuristic for many common cases yet even if the alignment is not "ideal", 40 is not that many characters per line with todays screens, making it very likely that the entire line remains "visible" in an editor. 2) Changed the heuristic to not simply look at the size ratio between current and previous line, but instead considering the geometric mean of the sizes of the previous (aligned) lines. This emphasizes the "overall picture" of the previous lines, rather than a single one (which might be an outlier). 3) Changed the ratio from 4 to 2.5. Now that we ignore sizes below 40, a ratio of 4 would mean that a new entry would have to be 4 times bigger (160) or smaller (10) before alignment would be broken. A ratio of 2.5 seems more sensible. Applied updated gofmt to all of src and misc. Also tested against several former issues that complained about this and verified that the output for the given examples is satisfactory (added respective test cases). Some of the files changed because they were not gofmt-ed in the first place. For #644. For #7335. For #10392. (and probably more related issues) Fixes #22852. Change-Id: I5e48b3d3b157a5cf2d649833b7297b33f43a6f6e
-
Balaram Makam authored
Performance numbers on amberwing: pkg: math/big name old time/op new time/op delta QuoRem 3.08µs ± 0% 2.93µs ± 1% -4.89% (p=0.008 n=5+5) ModSqrt225_Tonelli 721µs ± 0% 718µs ± 0% -0.46% (p=0.008 n=5+5) ModSqrt224_3Mod4 218µs ± 0% 217µs ± 0% -0.27% (p=0.008 n=5+5) ModSqrt5430_Tonelli 2.91s ± 0% 2.91s ± 0% ~ (p=0.222 n=5+5) ModSqrt5430_3Mod4 970ms ± 0% 970ms ± 0% ~ (p=0.151 n=5+5) Sqrt 45.9µs ± 0% 43.8µs ± 0% -4.63% (p=0.008 n=5+5) IntSqr/1 19.9ns ± 0% 17.3ns ± 0% -13.07% (p=0.008 n=5+5) IntSqr/2 52.6ns ± 0% 50.8ns ± 0% -3.35% (p=0.008 n=5+5) IntSqr/3 70.4ns ± 0% 69.4ns ± 0% ~ (p=0.079 n=4+5) IntSqr/5 103ns ± 0% 99ns ± 0% -3.98% (p=0.008 n=5+5) IntSqr/8 179ns ± 0% 178ns ± 0% -0.56% (p=0.008 n=5+5) IntSqr/10 272ns ± 0% 272ns ± 0% ~ (all equal) IntSqr/20 763ns ± 0% 787ns ± 0% +3.15% (p=0.016 n=5+4) IntSqr/30 1.25µs ± 1% 1.29µs ± 1% +3.27% (p=0.008 n=5+5) IntSqr/50 2.64µs ± 0% 2.71µs ± 0% +2.61% (p=0.008 n=5+5) IntSqr/80 5.67µs ± 0% 5.72µs ± 0% +0.88% (p=0.008 n=5+5) IntSqr/100 8.05µs ± 0% 8.09µs ± 0% +0.45% (p=0.008 n=5+5) IntSqr/200 28.0µs ± 0% 28.1µs ± 0% ~ (p=0.151 n=5+5) IntSqr/300 59.4µs ± 0% 59.6µs ± 0% +0.36% (p=0.008 n=5+5) IntSqr/500 141µs ± 0% 141µs ± 0% +0.08% (p=0.008 n=5+5) IntSqr/800 280µs ± 0% 280µs ± 0% -0.12% (p=0.008 n=5+5) IntSqr/1000 429µs ± 0% 428µs ± 0% -0.27% (p=0.008 n=5+5) pkg: crypto-ecdsa name old time/op new time/op delta SignP384 7.85ms ± 1% 7.61ms ± 1% -3.12% (p=0.008 n=5+5) Change-Id: I1ab30856cc0e570f6312f0bd8914779b55adbc16 Reviewed-on: https://go-review.googlesource.com/104135Reviewed-by:
-
Hana Kim authored
The trace viewer interprets the slice as a non-terminating time interval which is quite opposit to what trace records indicate (i.e., almostly immediately terminating time interval). As observed in the issue #24663 this can result in quite misleading visualization of the trace. Work around the trace viewer's issue by setting a small value (0.0001usec) as the duration if the time interval is not positive. Change-Id: I1c2aac135c194d0717f5c01a98ca60ffb14ef45c Reviewed-on: https://go-review.googlesource.com/104716Reviewed-by:
-
Hana Kim authored
This mode is similar to the default traceview mode where the execution trace is presented in P-oriented way. Each row represents a P, and each slice represents the time interval of a goroutine's execution on the P. The difference is that, in this mode, only the execution of goroutines involved in the specified task is highlighted, and other goroutine execution or events are greyed out. So, users can focus on how a task is executed while considering other affecting conditions such as other goroutines, network events, or process scheduling. Example: https://user-images.githubusercontent.com/4999471/38116793-a6f995f0-337f-11e8-8de9-88eec2f2c497.png Here, for a while the program remained idle after the first burst of activity related to the task because all other goroutines were also being blocked or waiting for events, or no incoming network traffic (indicated by the lack of any network activity). This is a bit hard to discover when the usual task-oriented view (/trace?taskid=<taskid>) mode. Also, it simplifies the traceview generation mode logic. /trace ---> 0 /trace?goid ---> modeGoroutineOriented /trace?taskid ---> modeGoroutineOriented|modeTaskOriented /trace?focustask ---> modeTaskOriented Change-Id: Idcc0ae31b708ddfd19766f4e26ee7efdafecd3a5 Reviewed-on: https://go-review.googlesource.com/103555 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by:
-
Austin Clements authored
Currently, the runtime falls back to asking for any address the OS can offer for the heap when it runs out of hint addresses. However, the race detector assumes the heap lives in [0x00c000000000, 0x00e000000000), and will fail in a non-obvious way if we go outside this region. Fix this by actively throwing a useful error if we run out of heap hints in race mode. This problem is currently being triggered by TestArenaCollision, which intentionally triggers this fallback behavior. Fix the test to look for the new panic message in race mode. Fixes #24670. Updates #24133. Change-Id: I57de6d17a3495dc1f1f84afc382cd18a6efc2bf7 Reviewed-on: https://go-review.googlesource.com/104717 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
James Hartig authored
Fixes #23643. Change-Id: I4f8195a36be817d79b9e7c61a5301f153b681493 Reviewed-on: https://go-review.googlesource.com/91675Reviewed-by:
-
Cherry Zhang authored
On darwin, only writable symbol is exported (cmd/link/internal/ld/macho.go:/machoShouldExport). For plugin to work correctly, global variables, including runtime.framepointer_enabled which is set by the linker, need to be exported when dynamic linking. Put it in DATA so it is exported. Also in Go it is defined as a var, which is not read-only. While here, do the same for runtime.goarm. Fixes #24653. Change-Id: I9d1b7d5a648be17103d20b97be65a901cb69f5a2 Reviewed-on: https://go-review.googlesource.com/104715 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by:
-
Meng Zhuo authored
Fix #10109 name old time/op new time/op delta Hash5 72.3ns ± 0% 51.5ns ± 0% -28.71% (p=0.000 n=4+5) Hash16 78.8ns ± 0% 48.7ns ± 0% ~ (p=0.079 n=4+5) Hash64 196ns ±25% 73ns ±16% -62.68% (p=0.008 n=5+5) Hash1024 1.57µs ± 0% 0.27µs ± 1% -82.90% (p=0.000 n=5+4) Hash65536 96.5µs ± 0% 14.3µs ± 0% -85.14% (p=0.016 n=5+4) HashStringSpeed 156ns ± 6% 129ns ± 3% -17.56% (p=0.008 n=5+5) HashBytesSpeed 227ns ± 1% 200ns ± 1% -11.98% (p=0.008 n=5+5) HashInt32Speed 116ns ± 2% 102ns ± 0% -11.92% (p=0.016 n=5+4) HashInt64Speed 120ns ± 3% 101ns ± 2% -15.55% (p=0.008 n=5+5) HashStringArraySpeed 342ns ± 0% 306ns ± 2% -10.58% (p=0.008 n=5+5) FastrandHashiter 217ns ± 1% 217ns ± 1% ~ (p=1.000 n=5+5) name old speed new speed delta Hash5 69.1MB/s ± 0% 97.0MB/s ± 0% +40.32% (p=0.008 n=5+5) Hash16 203MB/s ± 0% 329MB/s ± 0% +61.76% (p=0.016 n=4+5) Hash64 332MB/s ±21% 881MB/s ±14% +165.66% (p=0.008 n=5+5) Hash1024 651MB/s ± 0% 3652MB/s ±17% +460.73% (p=0.008 n=5+5) Hash65536 679MB/s ± 0% 4570MB/s ± 0% +572.85% (p=0.016 n=5+4) Change-Id: I573028979f84cf2e0e087951271d5de8865dbf04 Reviewed-on: https://go-review.googlesource.com/89755 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Daniel Martí authored
Variables can be declared and shadowing is supported, but modifying existing variables via assignments was not available. This meant that modifying a variable from a nested block was not possible: {{ $v := "init" }} {{ if true }} {{ $v := "changed" }} {{ end }} v: {{ $v }} {{/* "init" */}} Introduce the "=" assignment token, such that one can now do: {{ $v := "init" }} {{ if true }} {{ $v = "changed" }} {{ end }} v: {{ $v }} {{/* "changed" */}} To avoid confusion, rename PipeNode.Decl to PipeNode.Vars, as the variables may not always be declared after this change. Also change a few other names to better reflect the added ambiguity of variables in pipelines. Modifying the text/template/parse package in a backwards incompatible manner is acceptable, given that the package godoc clearly states that it isn't intended for general use. It's the equivalent of an internal package, back when internal packages didn't exist yet. To make the changes to the parse package sit well with the cmd/api test, update except.txt with the changes that we aren't worried about. Fixes #10608. Change-Id: I1f83a4297ee093fd45f9993cebb78fc9a9e81295 Reviewed-on: https://go-review.googlesource.com/84480 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:Rob Pike <r@golang.org>
-
Nikhil Benesch authored
If A's external test package imports B, which imports A, and A's internal test code adds something to A that invalidates anything in A's export data, then we need to build B against the test-augmented version of A before using it to build A's external test package. https://golang.org/cl/92215 taught 'go test' to do this rebuilding properly, but 'go vet' was not taught the same trick when it learned to vet test packages in https://golang.org/cl/87636. This commit moves the necessary logic into the load.TestPackagesFor function so it can be shared by 'go test' and 'go vet'. Fixes #23701. Change-Id: I1086d447eca02933af53de693384eac99a08d9bd Reviewed-on: https://go-review.googlesource.com/104315 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Alberto Donizetti authored
And delete them from asm_test. Change-Id: Id533130470da9176a401cb94972f626f43a62148 Reviewed-on: https://go-review.googlesource.com/103656 Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Giovanni Bajo <rasky@develer.com>
-
Alberto Donizetti authored
Allocate two more ssa local worklists on the stack. The initial sizes are chosen to cover >99% of the calls. name old time/op new time/op delta Template 281ms ± 2% 283ms ± 5% ~ (p=0.443 n=18+19) Unicode 136ms ± 4% 135ms ± 7% ~ (p=0.277 n=20+20) GoTypes 886ms ± 2% 885ms ± 2% ~ (p=0.862 n=20+20) Compiler 4.03s ± 2% 4.02s ± 1% ~ (p=0.270 n=19+20) SSA 9.66s ± 1% 9.64s ± 2% ~ (p=0.253 n=20+20) Flate 186ms ± 5% 183ms ± 6% ~ (p=0.174 n=20+20) GoParser 222ms ± 4% 219ms ± 4% ~ (p=0.081 n=20+20) Reflect 569ms ± 2% 568ms ± 2% ~ (p=0.686 n=19+19) Tar 258ms ± 4% 256ms ± 3% ~ (p=0.211 n=20+20) XML 319ms ± 2% 317ms ± 3% ~ (p=0.158 n=18+20) name old user-time/op new user-time/op delta Template 396ms ± 6% 392ms ± 6% ~ (p=0.211 n=20+20) Unicode 212ms ±10% 211ms ± 9% ~ (p=0.904 n=20+20) GoTypes 1.21s ± 3% 1.21s ± 2% ~ (p=0.183 n=20+20) Compiler 5.60s ± 2% 5.62s ± 2% ~ (p=0.355 n=18+18) SSA 14.0s ± 6% 13.9s ± 5% ~ (p=0.678 n=20+20) Flate 250ms ± 8% 245ms ± 6% ~ (p=0.166 n=19+20) GoParser 305ms ± 6% 304ms ± 5% ~ (p=0.659 n=20+20) Reflect 760ms ± 3% 758ms ± 4% ~ (p=0.758 n=20+20) Tar 362ms ± 6% 357ms ± 5% ~ (p=0.108 n=20+20) XML 429ms ± 4% 429ms ± 4% ~ (p=0.799 n=20+20) name old alloc/op new alloc/op delta Template 39.0MB ± 0% 38.8MB ± 0% -0.55% (p=0.000 n=20+20) Unicode 29.1MB ± 0% 29.1MB ± 0% -0.06% (p=0.000 n=20+20) GoTypes 116MB ± 0% 115MB ± 0% -0.50% (p=0.000 n=20+20) Compiler 493MB ± 0% 491MB ± 0% -0.46% (p=0.000 n=19+20) SSA 1.40GB ± 0% 1.40GB ± 0% -0.31% (p=0.000 n=19+20) Flate 25.0MB ± 0% 24.9MB ± 0% -0.60% (p=0.000 n=19+19) GoParser 30.9MB ± 0% 30.7MB ± 0% -0.66% (p=0.000 n=20+20) Reflect 77.5MB ± 0% 77.1MB ± 0% -0.52% (p=0.000 n=20+20) Tar 39.2MB ± 0% 39.0MB ± 0% -0.47% (p=0.000 n=20+20) XML 44.8MB ± 0% 44.6MB ± 0% -0.45% (p=0.000 n=20+19) name old allocs/op new allocs/op delta Template 382k ± 0% 379k ± 0% -0.69% (p=0.000 n=20+19) Unicode 337k ± 0% 336k ± 0% -0.09% (p=0.000 n=20+20) GoTypes 1.19M ± 0% 1.18M ± 0% -0.64% (p=0.000 n=20+20) Compiler 4.60M ± 0% 4.58M ± 0% -0.57% (p=0.000 n=20+20) SSA 11.5M ± 0% 11.4M ± 0% -0.42% (p=0.000 n=19+20) Flate 235k ± 0% 233k ± 0% -0.74% (p=0.000 n=20+19) GoParser 316k ± 0% 313k ± 0% -0.69% (p=0.000 n=20+20) Reflect 953k ± 0% 946k ± 0% -0.81% (p=0.000 n=20+20) Tar 391k ± 0% 388k ± 0% -0.61% (p=0.000 n=20+19) XML 413k ± 0% 411k ± 0% -0.56% (p=0.000 n=20+20) Change-Id: I7378174e3550b47df4368b24cf24c8ce1b85c906 Reviewed-on: https://go-review.googlesource.com/104656Reviewed-by:
-
Lubomir I. Ivanov (VMware) authored
Add the following helpers in lookup_windows.go: 1) lookupGroupName() is used to obtain the SID of a group based on name. 2) listGroupsForUsernameAndDomain() uses NetUserGetLocalGroups() as a WINAPI backend to obtain the list of local groups for this user. 3) lookupUserPrimaryGroup() is now used to populate the User.Gid field when looking up a user by name. Implement listGroups(), lookupGroupId(), lookupGroup() and no longer return unimplemented errors. Do not skip Windows User.Gid tests in user_test.go. Change-Id: I81fd41b406da51f9a4cb24e50d392a333df81141 GitHub-Last-Rev: d1448fd55d6eaa0f41bf347df18b40da06791df1 GitHub-Pull-Request: golang/go#24222 Reviewed-on: https://go-review.googlesource.com/98137Reviewed-by:
Alex Brainman <alex.brainman@gmail.com> Run-TryBot: Alex Brainman <alex.brainman@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Josh Bleecher Snyder authored
Make the StackCopyNoCache test easier to read. Add a StackCopyPtr test that actually has some pointers that need adjusting. Change-Id: I5b07c26f40cb485c9de97ed63fac89a9e6f36650 Reviewed-on: https://go-review.googlesource.com/104195 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
- 03 Apr, 2018 8 commits
-
-
Dhruvdutt Jadhav authored
Change-Id: I5a1c7ed83a430a509d8f61f4aba8772d5d16ad48 GitHub-Last-Rev: fed86d88691c8a62bafac18a4e5c0944a4e59050 GitHub-Pull-Request: golang/go#24664 Reviewed-on: https://go-review.googlesource.com/104515Reviewed-by:
-
Robert Griesemer authored
Fixes #23664. Change-Id: Ic0637e9f896b2fc6502dfbab2d1c4de3c62c0bd2 Reviewed-on: https://go-review.googlesource.com/104616Reviewed-by:
-
Robert Griesemer authored
Change-Id: Ie84d0e61697922c1e808d815fb7d9aec694ee8e9 Reviewed-on: https://go-review.googlesource.com/104615Reviewed-by:
-
Giovanni Bajo authored
The logic in addBranchRestrictions didn't allow to correctly model OpIs(Slice)Bound for signed domain, and it was also partly implemented within addRestrictions. Thanks to the previous changes, it is now possible to handle the negative conditions correctly, so that we can learn both signed/LT + unsigned/LT on the positive side, and signed/GE + unsigned/GE on the negative side (but only if the index can be proved to be non-negative). This is able to prove ~50 more slice accesses in std+cmd. Change-Id: I9858080dc03b16f85993a55983dbc4b00f8491b0 Reviewed-on: https://go-review.googlesource.com/104037 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Giovanni Bajo authored
addRestrictions was taking a branch parameter, binding its logic to that of addBranchRestrictions. Since we will need to use it for updating the facts table for induction variables, refactor it to remove the branch parameter. Passes toolstash -cmp. Change-Id: Iaaec350a8becd1919d03d8574ffd1bbbd906d068 Reviewed-on: https://go-review.googlesource.com/104036 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
isharipo authored
That "else" was needed due to gc DCE limitations. Now it's not the case and we can avoid go lint complaints. (See #23521 and https://golang.org/cl/91056.) There is inlining test for bigEndianWord, so if test is passing, no performance regression should occur. Change-Id: Id84d63f361e5e51a52293904ff042966c83c16e9 Reviewed-on: https://go-review.googlesource.com/104555Reviewed-by:
-
Alberto Donizetti authored
Compiler instrumentation shows that the cap of the stores slice in the storeOrder function is almost always 64 or less. Since the slice does not escape, pre-allocating on the stack a 64-elements one greatly reduces the number of allocations performed by the function. name old time/op new time/op delta Template 289ms ± 5% 283ms ± 3% -1.99% (p=0.000 n=19+20) Unicode 140ms ± 6% 136ms ± 6% -2.61% (p=0.021 n=19+20) GoTypes 915ms ± 2% 895ms ± 2% -2.24% (p=0.000 n=19+20) Compiler 4.15s ± 1% 4.04s ± 2% -2.73% (p=0.000 n=20+20) SSA 10.0s ± 1% 9.8s ± 2% -2.13% (p=0.000 n=20+20) Flate 189ms ± 6% 186ms ± 4% -1.75% (p=0.028 n=19+20) GoParser 229ms ± 5% 224ms ± 4% -2.25% (p=0.001 n=20+19) Reflect 584ms ± 2% 573ms ± 3% -1.83% (p=0.000 n=18+20) Tar 265ms ± 3% 261ms ± 3% -1.33% (p=0.021 n=20+20) XML 328ms ± 2% 321ms ± 2% -2.11% (p=0.000 n=20+20) name old user-time/op new user-time/op delta Template 408ms ± 4% 400ms ± 4% -1.98% (p=0.006 n=19+20) Unicode 216ms ± 9% 216ms ± 7% ~ (p=0.883 n=20+20) GoTypes 1.25s ± 1% 1.23s ± 3% -1.32% (p=0.002 n=19+20) Compiler 5.77s ± 1% 5.69s ± 2% -1.47% (p=0.000 n=18+19) SSA 14.6s ± 5% 14.1s ± 4% -3.45% (p=0.000 n=20+20) Flate 252ms ± 7% 251ms ± 7% ~ (p=0.659 n=20+20) GoParser 314ms ± 5% 310ms ± 5% ~ (p=0.165 n=20+20) Reflect 780ms ± 2% 769ms ± 3% -1.34% (p=0.004 n=19+18) Tar 365ms ± 7% 367ms ± 5% ~ (p=0.841 n=20+20) XML 439ms ± 4% 432ms ± 4% -1.45% (p=0.043 n=20+20) name old alloc/op new alloc/op delta Template 38.9MB ± 0% 38.8MB ± 0% -0.26% (p=0.000 n=19+20) Unicode 29.0MB ± 0% 29.0MB ± 0% -0.02% (p=0.001 n=20+19) GoTypes 115MB ± 0% 115MB ± 0% -0.31% (p=0.000 n=20+20) Compiler 492MB ± 0% 490MB ± 0% -0.41% (p=0.000 n=20+19) SSA 1.40GB ± 0% 1.39GB ± 0% -0.48% (p=0.000 n=20+20) Flate 24.9MB ± 0% 24.9MB ± 0% -0.24% (p=0.000 n=20+20) GoParser 30.9MB ± 0% 30.8MB ± 0% -0.39% (p=0.000 n=20+20) Reflect 77.1MB ± 0% 76.8MB ± 0% -0.32% (p=0.000 n=17+20) Tar 39.1MB ± 0% 39.0MB ± 0% -0.23% (p=0.000 n=20+20) XML 44.7MB ± 0% 44.6MB ± 0% -0.30% (p=0.000 n=20+18) name old allocs/op new allocs/op delta Template 385k ± 0% 382k ± 0% -0.99% (p=0.000 n=20+19) Unicode 336k ± 0% 336k ± 0% -0.08% (p=0.000 n=19+17) GoTypes 1.20M ± 0% 1.18M ± 0% -1.11% (p=0.000 n=20+18) Compiler 4.66M ± 0% 4.59M ± 0% -1.42% (p=0.000 n=19+20) SSA 11.6M ± 0% 11.5M ± 0% -1.49% (p=0.000 n=20+20) Flate 237k ± 0% 235k ± 0% -1.00% (p=0.000 n=20+19) GoParser 319k ± 0% 315k ± 0% -1.12% (p=0.000 n=20+20) Reflect 960k ± 0% 952k ± 0% -0.92% (p=0.000 n=18+20) Tar 394k ± 0% 390k ± 0% -0.87% (p=0.000 n=20+20) XML 418k ± 0% 413k ± 0% -1.18% (p=0.000 n=20+20) Change-Id: I01b9f45b161379967d7a52e23f39ac30dd90edb0 Reviewed-on: https://go-review.googlesource.com/104415Reviewed-by:
-
Filippo Valsorda authored
If in.Mutex is never locked by Handshake when c.handshakeComplete is true, and since c.handshakeComplete is unset and then set back by handleRenegotiation all under both in.Mutex and handshakeMutex, we can significantly simplify the locking strategy by removing the sync.Cond. See also https://groups.google.com/forum/#!topic/golang-dev/Xxiai-R_jH0 and a more complete analysis at https://go-review.googlesource.com/c/go/+/33776#message-223a3ccc819f7015cc773d214c65bad70de5dfd7 Change-Id: I6052695ece9aff9e3112c2fb176596fde8aa9cb2 Reviewed-on: https://go-review.googlesource.com/33776Reviewed-by:
Adam Langley <agl@golang.org>
-
