- 01 Nov, 2016 19 commits
-
-
Ilya Tocar authored
IndexByte+compare is faster than indexShortStr in good case, when first byte is rare, but is more costly in bad cases. Start with IndexByte and switch to indexShortStr if we encounter false positives more often than once per 8 bytes. Benchmark changes for package bytes: IndexRune/4K-8 416ns ± 0% 86ns ± 0% -79.24% (p=0.000 n=10+10) IndexRune/4M-8 413µs ± 0% 100µs ± 1% -75.88% (p=0.000 n=10+10) IndexRune/64M-8 6.73ms ± 0% 2.86ms ± 1% -57.49% (p=0.000 n=10+10) Index/10-8 8.45ns ± 0% 8.96ns ± 0% +6.04% (p=0.000 n=9+10) Index/32-8 9.64ns ± 0% 9.51ns ± 0% -1.30% (p=0.000 n=8+9) Index/4K-8 2.11µs ± 0% 2.12µs ± 0% +0.26% (p=0.000 n=10+10) Index/4M-8 3.60ms ± 5% 3.59ms ± 7% ~ (p=0.497 n=9+10) Index/64M-8 57.1ms ± 3% 58.7ms ± 5% ~ (p=0.113 n=9+10) IndexEasy/10-8 7.10ns ± 1% 7.71ns ± 1% +8.60% (p=0.000 n=10+10) IndexEasy/32-8 9.29ns ± 1% 9.22ns ± 0% -0.75% (p=0.000 n=9+10) IndexEasy/4K-8 1.06µs ± 0% 0.08µs ± 0% -92.18% (p=0.000 n=10+10) IndexEasy/4M-8 1.07ms ± 0% 0.10ms ± 1% -90.74% (p=0.000 n=9+10) IndexEasy/64M-8 17.3ms ± 0% 2.8ms ± 1% -83.76% (p=0.000 n=10+9) IndexRune/4K-8 9.84GB/s ± 0% 47.42GB/s ± 0% +381.85% (p=0.000 n=8+10) IndexRune/4M-8 10.1GB/s ± 0% 42.1GB/s ± 1% +314.56% (p=0.000 n=10+10) IndexRune/64M-8 10.0GB/s ± 0% 23.4GB/s ± 1% +135.25% (p=0.000 n=10+10) Index/10-8 1.18GB/s ± 0% 1.12GB/s ± 0% -5.67% (p=0.000 n=10+9) Index/32-8 3.32GB/s ± 0% 3.36GB/s ± 0% +1.27% (p=0.000 n=10+9) Index/4K-8 1.94GB/s ± 0% 1.93GB/s ± 0% -0.25% (p=0.000 n=10+9) Index/4M-8 1.17GB/s ± 5% 1.17GB/s ± 7% ~ (p=0.497 n=9+10) Index/64M-8 1.17GB/s ± 3% 1.15GB/s ± 6% ~ (p=0.113 n=9+10) IndexEasy/10-8 1.41GB/s ± 1% 1.30GB/s ± 1% -7.90% (p=0.000 n=10+10) IndexEasy/32-8 3.45GB/s ± 1% 3.47GB/s ± 0% +0.73% (p=0.000 n=9+10) IndexEasy/4K-8 3.84GB/s ± 0% 49.16GB/s ± 0% +1178.78% (p=0.000 n=9+10) IndexEasy/4M-8 3.91GB/s ± 0% 42.19GB/s ± 1% +980.37% (p=0.000 n=9+10) IndexEasy/64M-8 3.88GB/s ± 0% 23.91GB/s ± 1% +515.76% (p=0.000 n=10+9) No significant changes in strings. In regexp I see: Match/Easy0/32-8 536MB/s ± 1% 540MB/s ± 1% +0.75% (p=0.001 n=9+10) Match/Easy0/1K-8 1.62GB/s ± 0% 4.42GB/s ± 1% +172.48% (p=0.000 n=10+10) Match/Easy0/32K-8 1.87GB/s ± 0% 9.07GB/s ± 1% +384.24% (p=0.000 n=7+10) Match/Easy0/1M-8 1.90GB/s ± 0% 4.83GB/s ± 0% +154.56% (p=0.000 n=8+10) Match/Easy0/32M-8 1.90GB/s ± 0% 4.53GB/s ± 0% +138.62% (p=0.000 n=7+10) Compared to in 1.7: Match/Easy0/32-8 59.5ns ± 0% 59.2ns ± 1% -0.45% (p=0.008 n=9+10) Match/Easy0/1K-8 226ns ± 1% 231ns ± 1% +2.30% (p=0.000 n=10+10) Match/Easy0/32K-8 3.73µs ± 2% 3.61µs ± 1% -3.12% (p=0.000 n=10+10) Match/Easy0/1M-8 206µs ± 1% 217µs ± 0% +5.34% (p=0.000 n=10+10) Match/Easy0/32M-8 7.03ms ± 1% 7.40ms ± 0% +5.23% (p=0.000 n=10+10) Fixes #17456 Change-Id: I38b2fabcaed7119cc4bf37007ba7bfe7504c8f9f Reviewed-on: https://go-review.googlesource.com/31690 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> Reviewed-by:
Keith Randall <khr@golang.org>
-
Brad Fitzpatrick authored
Fixes #17699 Change-Id: I7ea29a3fc2ca13d9d7e3044cbb8ea22e3435d423 Reviewed-on: https://go-review.googlesource.com/32484 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Rob Pike <r@golang.org>
-
Rob Pike authored
This makes it possible to avoid tests where coverage affects the test results by skipping them (or otherwise adjusting them) when coverage is enabled. Update #17699 Change-Id: Ifcc36cfcd88ebd677890e82ba80ee3d696ed3d7c Reviewed-on: https://go-review.googlesource.com/32483Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Brad Fitzpatrick authored
Fixes #13290 Change-Id: I0f7e7683d86db501cbedb6a0b7349ceb0769701c Reviewed-on: https://go-review.googlesource.com/32481Reviewed-by:
Martin Möhrmann <martisch@uos.de> Reviewed-by:
Ian Lance Taylor <iant@golang.org>
-
Bryan C. Mills authored
sigfwd calls an arbitrary C signal handler function. The System V ABI for x86_64 (and the most recent revision of the ABI for i386) requires the stack to be 16-byte aligned. Fixes: #17641 Change-Id: I77f53d4a8c29c1b0fe8cfbcc8d5381c4e6f75a6b Reviewed-on: https://go-review.googlesource.com/32107 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Go's http1 implementation originally had a mechanism to send HTTP trailers based on pre-declaring the trailer keys whose values you'd later let after the header was written. http2 copied the same mechanism, but it was found to be unsufficient for gRPC's wire protocol. A second trailer mechanism was added later (but only to http2) for handlers that want to send a trailer without knowing in advance they'd need to. Copy the same mechanism back to http1 and document it. Fixes #15754 Change-Id: I8c40d55e28b0e5b7087d3d1a904a392c56ee1f9b Reviewed-on: https://go-review.googlesource.com/32479Reviewed-by:
-
Lynn Boger authored
Skip TestObjdumpPowerManual if the host system is not ppc64 or ppc64le. This test depends on using the host objdump and comparing output, which does not work as expected if the test is run on another host. Orignates from golang.org/x/arch/ppc64/ppc64asm commit 8e2d4898. Fixes #17698 Change-Id: I956b0fb78c5ec33641db752d46a755008403d269 Reviewed-on: https://go-review.googlesource.com/32531Reviewed-by:
-
Robert Griesemer authored
This should never be called but should help identify causes of unexpected panics such as in issue #17716. Change-Id: Id6ad0cef1088a41bfcc69110a93484a7e39c4128 Reviewed-on: https://go-review.googlesource.com/32480 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Alan Donovan <adonovan@google.com>
-
David Crawshaw authored
Fixes #17683 Change-Id: I46f45c63796b58e8a8f14e37592231cbe7cd6934 Reviewed-on: https://go-review.googlesource.com/32438Reviewed-by:
-
David Crawshaw authored
The introduction of -buildmode=plugin means modules can be added to a Go program while it is running. This means there exists some time while the program is running with the module is on the moduledata linked list, but it has not been initialized to the satisfaction of other parts of the runtime. Notably, the GC. This CL adds a new way of access modules, an activeModules function. It returns a slice of modules that is built in the background and atomically swapped in. The parts of the runtime that need to wait on module initialization can use this slice instead of the linked list. Fixes #17455 Change-Id: I04790fd07e40c7295beb47cea202eb439206d33d Reviewed-on: https://go-review.googlesource.com/32357Reviewed-by:
-
Michael Munday authored
There is no benefit to folding ADDconsts unless the resultant immediate will fit into a 20-bit signed integer, so limit these rules accordingly. Also the signed load operations were missing, so I've added them, and I've also removed some MOVDaddr rules that were dead code (MOVDaddrs are rematerializable on s390x which means they can't take inputs other than SP or SB). Change-Id: Iebeba78da37d3d71d32d4b7f49fe4ea9095d40ec Reviewed-on: https://go-review.googlesource.com/30616 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
David Chase <drchase@google.com>
-
Martin Möhrmann authored
- Adds overflow checks - Adds parsing of negative integers - Adds boolean return value to signal parsing errors - Adds atoi32 for parsing of integers that fit in an int32 - Adds tests Handling of errors to provide error messages at the call sites is left to future CLs. Updates #17718 Change-Id: I3cacd0ab1230b9efc5404c68edae7304d39bcbc0 Reviewed-on: https://go-review.googlesource.com/32390Reviewed-by:
-
Carlos Eduardo Seo authored
This implements a check that can be done at runtime for the ISA level and hardware capability. It follows the same implementation as in s390x. These checks will be important as we enable new instructions and write go asm implementations using those. Updates #15403 Fixes #16643 Change-Id: Idfee374a3ffd7cf13a7d8cf0a6c83d247d3bee16 Reviewed-on: https://go-review.googlesource.com/32330Reviewed-by:
Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by:
-
Michael Munday authored
Use vector instructions to speed up indexing operations for short strings (64 bytes or less). bytes_s390x.go and strings_s390x.go are based on their amd64 equivalents in CL 31690. bytes package: name old time/op new time/op delta Index/10 40.3ns ± 7% 11.3ns ± 4% -72.06% (p=0.000 n=10+10) Index/32 196ns ± 1% 27ns ± 2% -86.25% (p=0.000 n=10+10) Index/4K 28.9µs ± 1% 1.5µs ± 2% -94.94% (p=0.000 n=9+9) Index/4M 30.1ms ± 2% 1.5ms ± 3% -94.94% (p=0.000 n=10+10) Index/64M 549ms ±13% 28ms ± 3% -94.87% (p=0.000 n=10+9) IndexEasy/10 18.8ns ±11% 11.5ns ± 2% -38.81% (p=0.000 n=10+10) IndexEasy/32 23.6ns ± 6% 28.1ns ± 3% +19.29% (p=0.000 n=10+10) IndexEasy/4K 251ns ± 5% 223ns ± 8% -11.04% (p=0.000 n=10+10) IndexEasy/4M 318µs ± 9% 266µs ± 8% -16.42% (p=0.000 n=10+10) IndexEasy/64M 14.7ms ±16% 13.2ms ±11% -10.22% (p=0.001 n=10+10) strings package: name old time/op new time/op delta IndexRune 88.1ns ±16% 28.9ns ± 4% -67.20% (p=0.000 n=10+10) IndexRuneLongString 456ns ± 7% 34ns ± 3% -92.50% (p=0.000 n=10+10) IndexRuneFastPath 12.9ns ±14% 11.1ns ± 6% -13.84% (p=0.000 n=10+10) Index 13.0ns ± 7% 11.3ns ± 4% -13.31% (p=0.000 n=10+10) IndexHard1 3.38ms ± 9% 0.07ms ± 1% -97.79% (p=0.000 n=10+10) IndexHard2 3.58ms ± 7% 0.37ms ± 2% -89.78% (p=0.000 n=10+10) IndexHard3 3.47ms ± 7% 0.75ms ± 1% -78.52% (p=0.000 n=10+10) IndexHard4 3.56ms ± 6% 1.34ms ± 0% -62.39% (p=0.000 n=9+9) Change-Id: If36c2afb8c02e80fcaa1cf5ec2abb0a2be08c7d1 Reviewed-on: https://go-review.googlesource.com/32447 Run-TryBot: Michael Munday <munday@ca.ibm.com> Reviewed-by:
-
Daniel Martí authored
In a previous change, cmd/go was taught to show a "no tests ran" warning if test did nothing. But it missed a case - if no tests nor examples ran but any benchmarks were meant to be run, it would still produce the warning. This meant that running only benchmarks, which is common, would be confusing: $ go test -run='^$' -bench=. testing: warning: no tests to run BenchmarkFoo-4 300000 5056 ns/op [...] I believe this was because of a copy-paste error in the tests. This was being tested, but on the wrong file which does contain a test that was being run. Fix the path and fix the now failing test by never showing the warning if -bench was given a non-empty string. The rationale is that if -bench was given but there was no output, it's obvious that nothing happened as benchmarks always produce output even without -v. So showing a warning in those cases is redundant. To make future typos less likely, make sure that no tests are being run in the cases where we only want to run benchmarks. Fixes #17603. Change-Id: I4c626caf39f72260c6a9761c06446663f465f947 Reviewed-on: https://go-review.googlesource.com/32157Reviewed-by:
Marcel van Lohuizen <mpvl@golang.org> Run-TryBot: Marcel van Lohuizen <mpvl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Emmanuel Odeke authored
Adds ModifyResponse, an optional func to ReverseProxy that modifies a response in the backend, right before the headers of the response are written to the internal response writer. If ModifyResponse returns an error, the proxy returns a StatusBadGateway error. Fixes #14237. Change-Id: I8e03139e34dea0084512ccbd8cc49e941bf9fb5d Reviewed-on: https://go-review.googlesource.com/32356Reviewed-by:
-
Joe Tsai authored
This CL expands upon a change made in (http://golang.org/cl/21811) to ensure that a nil RawMessage gets serialized as "null" instead of being a nil slice. The added check only triggers when the RawMessage is nil. We do not handle the case when the RawMessage is non-nil, but empty. Fixes #17704 Updates #14493 Change-Id: I0fbebcdd81f7466c5b78c94953afc897f162ceb4 Reviewed-on: https://go-review.googlesource.com/32472Reviewed-by:
-
Robert Griesemer authored
If no error handler is provided, terminate parsing with first error and report that error. Fixes #17697. Change-Id: I9070faf7239bd53725de141507912b92ded3474b Reviewed-on: https://go-review.googlesource.com/32456 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com>
-
Brad Fitzpatrick authored
Also updates x/net/http2 to git rev 541150 for: http2: add support for graceful shutdown of Server https://golang.org/cl/32412 http2: make http2.Server access http1's Server via an interface check https://golang.org/cl/32417 Fixes #4674 Fixes #9478 Change-Id: I8021a18dee0ef2fe3946ac1776d2b10d3d429052 Reviewed-on: https://go-review.googlesource.com/32329 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
-
- 31 Oct, 2016 21 commits
-
-
Matthew Dempsky authored
Change-Id: I54f8788a4703283b9aa3904e2e610097ac3e3586 Reviewed-on: https://go-review.googlesource.com/32471 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by:
Robert Griesemer <gri@golang.org>
-
Austin Clements authored
Currently we have write barriers for direct channel sends, where the receiver is blocked and the sender is writing directly to the receiver's stack; but not for direct channel receives, where the sender is blocked and the receiver is reading directly from the sender's stack. This was okay with the old write barrier because either 1) the receiver would write the received pointer into the heap (causing it to be shaded), 2) the pointer would still be on the receiver's stack at mark termination and we would rescan it, or 3) the receiver dropped the pointer so it wasn't necessarily reachable anyway. This is not okay with the write barrier because it lets a grey stack send a white pointer to a black stack and then remove it from its own stack. If the grey stack was the sole grey-protector of this pointer, this hides the object from the garbage collector. Fix this by making direct receives perform a stack-to-stack write barrier just like direct sends do. Fixes #17694. Change-Id: I1a4cb904e4138d2ac22f96a3e986635534a5ae41 Reviewed-on: https://go-review.googlesource.com/32450Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Dhananjay Nakrani authored
typecheckcomplit nils out node's type, upon finding new errors. This hides new errors in children's node as well as the type info of current node. This change fixes that. Fixes #17645. Change-Id: Ib473291f31c7e8fa0307cb1d494e0c112ddd3583 Reviewed-on: https://go-review.googlesource.com/32324Reviewed-by:
-
Austin Clements authored
Currently, assists can only perform heap marking jobs. However, at the beginning of GC, there are only root jobs and no heap marking jobs. As a result, there's often a period at the beginning of a GC cycle where no goroutine has accumulated assist credit, but at the same time it can't get any credit because there are no heap marking jobs for it to do yet. As a result, many goroutines often block on the assist queue at the very beginning of the GC cycle. This commit fixes this by allowing assists to perform root marking jobs. The tricky part of this (and the reason we haven't done this before) is that stack scanning jobs can lead to deadlocks if the goroutines performing the stack scanning are themselves non-preemptible, since two non-preemptible goroutines may try to scan each other. To address this, we use the same insight d6625caf used to simplify the mark worker stack scanning: as long as we're careful with the stacks and only drain jobs while on the system stack, we can put the goroutine into a preemptible state while we drain jobs. This means an assist's user stack can be scanned while it continues to do work. This reduces the rate of assist blocking in the x/benchmarks HTTP benchmark by a factor of 3 and all remaining blocking happens towards the *end* of the GC cycle, when there may genuinely not be enough work to go around. Ideally, assists would get credit for working on root jobs. Currently they do not; however, this change prioritizes heap work over root jobs in assists, so they're likely to mostly perform heap work. In contrast with mark workers, for assists, the root jobs act only as a backstop to create heap work when there isn't enough heap work. Fixes #15361. Change-Id: If6e169863e4ad75710b0c8dc00f6125b41e9a595 Reviewed-on: https://go-review.googlesource.com/32432Reviewed-by:
-
Austin Clements authored
This lifts the part of gcAssistAlloc that runs on the system stack to its own function in preparation for letting assists perform root jobs (notably stack scanning). This makes it easy to see that there are no references to the user stack once we've entered gcAssistAlloc1, which means it's safe to shrink the stack while in gcAssistAlloc1. This does not yet make assists perform root jobs, so it's not actually possible for the stack to shrink yet. That will happen in the next commit. The code in gcAssistAlloc1 is identical to the code that's currently passed in a closure to systemstack with one exception. Currently, we set the "completed" variable in the enclosing scope to indicate that the assist completed the mark phase. This is exactly the sort of cross-stack reference lifting this function is meant to prevent. We replace this variable with setting gp.param to nil or non-nil to indicate the completion status. Updates #15361. Change-Id: Iba7cfb758c781070a441aea86c0117b399a24dbd Reviewed-on: https://go-review.googlesource.com/32431 TryBot-Result: Gobot Gobot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by:
-
Robert Griesemer authored
Change-Id: I113ea712838511ee823375d9ea059089195414f5 Reviewed-on: https://go-review.googlesource.com/32449 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Jaana Burcu Dogan authored
Fixes #16910. Change-Id: I0e97e88bee0361cd3621cacd1d4b84e6e42af718 Reviewed-on: https://go-review.googlesource.com/32424Reviewed-by:
-
Robert Griesemer authored
Change-Id: Iba5cfa033483b843dbd3681ffad50b117cced4a7 Reviewed-on: https://go-review.googlesource.com/32448Reviewed-by:
-
Dhananjay Nakrani authored
Previously, on encountering Func.Nname.Type == nil, typecheckfunc() returned without initializing Decldepth for that func. This causes typecheckclosure() to fatal. This change ensures that we initialize Decldepth in all cases. Fixes #17588. Change-Id: I2e3c81ad52e8383395025388989e8dbf03438b68 Reviewed-on: https://go-review.googlesource.com/32415Reviewed-by:
Josh Bleecher Snyder <josharian@gmail.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Keith Randall authored
We used to have to keep on-stack copies of these types. Now they can be registerized. [0]T is kind of trivial but might as well handle it. This change enables another change I'm working on to improve how x.(T) expressions are handled (#17405). This CL helps because now all types that are direct interface types are registerizeable (e.g. [1]*byte). No higher-degree arrays for now because non-constant indexes are hard. Update #17405 Change-Id: I2399940965d17b3969ae66f6fe447a8cefdd6edd Reviewed-on: https://go-review.googlesource.com/32416 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
David Chase authored
This is an extension of https://go-review.googlesource.com/c/31662/ to mark all the temporaries, not just the ssa-generated ones. Before-and-after ls -l `go tool -n compile` shows a 3% reduction in size (or rather, a prior 3% inflation for failing to filter temps out properly.) Replaced name-dependent "is it a temp?" tests with calls to *Node.IsAutoTmp(), which depends on AutoTemp. Also replace calls to istemp(n) with n.IsAutoTmp(), to reduce duplication and clean up function name space. Generated temporaries now come with a "." prefix to avoid (apparently harmless) clashes with legal Go variable names. Fixes #17644. Fixes #17240. Change-Id: If1417f29c79a7275d7303ddf859b51472890fd43 Reviewed-on: https://go-review.googlesource.com/32255 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
Change-Id: I8a28a88a655d9929f8641f71573dc01dc53be00f Reviewed-on: https://go-review.googlesource.com/32443Reviewed-by:
-
Josh Bleecher Snyder authored
This picks up just a trivial fix, making vet (and thus me) happy. Change-Id: Ib82ae44c081ff1ec5c078196a6cd5e1a3505d03b Reviewed-on: https://go-review.googlesource.com/32427 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Change-Id: Ic66eb2939d83559610e62cbb181a8faa6193ecc4 Reviewed-on: https://go-review.googlesource.com/32426 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Makes vet happy. Change-Id: I00de44a844afa57901b31991acf9e7ac834a9572 Reviewed-on: https://go-review.googlesource.com/32425 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Robert Griesemer authored
Fixes #17592. Change-Id: I914fa8c0729012990878b6e5c3e99b0f9b0e2be8 Reviewed-on: https://go-review.googlesource.com/32350 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Matthew Dempsky authored
-M, -P, and -R were for debugging backend passes that no longer exists. -g is used for debugging instructions generated with Gins, but the SSA backend mostly generates instructions directly. The handful of instructions still generated with Gins are pretty useless for debugging. -x was used to debug the old lexer, but now it only causes us to print file names as they're parsed, and only if we manually hack the compiler to enable tracing. Change-Id: Ia58d4bc9c1312693466171a3fcefc1221e9a2381 Reviewed-on: https://go-review.googlesource.com/32428 Run-TryBot: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Mike Strosaker authored
Adds an assembly implementation of sha256.block for ppc64le to improve its performance. This implementation is largely based on the original amd64 implementation, which unrolls the 64 iterations of the inner loop. Fixes #17652 benchmark old ns/op new ns/op delta BenchmarkHash8Bytes 1263 767 -39.27% BenchmarkHash1K 14048 7766 -44.72% BenchmarkHash8K 102245 55626 -45.60% benchmark old MB/s new MB/s speedup BenchmarkHash8Bytes 6.33 10.43 1.65x BenchmarkHash1K 72.89 131.85 1.81x BenchmarkHash8K 80.12 147.27 1.84x Change-Id: Ib4adf429423b20495580400be10bd7e171bcc70b Reviewed-on: https://go-review.googlesource.com/32318Reviewed-by:
Carlos Eduardo Seo <cseo@linux.vnet.ibm.com> Reviewed-by:
-
Mike Strosaker authored
Adds an assembly implementation of sha512.block for ppc64le to improve its performance. This implementation is largely based on the original amd64 implementation, unrolling the 80 iterations of the inner loop. Fixes #17660 benchmark old ns/op new ns/op delta BenchmarkHash8Bytes 1715 1133 -33.94% BenchmarkHash1K 10098 5513 -45.41% BenchmarkHash8K 68004 35278 -48.12% benchmark old MB/s new MB/s speedup BenchmarkHash8Bytes 4.66 7.06 1.52x BenchmarkHash1K 101.40 185.72 1.83x BenchmarkHash8K 120.46 232.21 1.93x Change-Id: Ifd55a49a24cb159b3a09a8e928c3f37727aca103 Reviewed-on: https://go-review.googlesource.com/32320Reviewed-by:
-
Michael Matloob authored
These were accidentally removed by a rollback cl: golang.org/cl/32441 Change-Id: I0cfa8b3397be324dabfb8f33b6548a03c10571eb Reviewed-on: https://go-review.googlesource.com/32334Reviewed-by:
-
Michael Matloob authored
This reverts commit b33030a7. Reason for revert: We're going to try to get the code in this change submitted in smaller, more carefully reviewed changes. Change-Id: I4175f4b297f0e69fb78b11f9dc0bd82f27865be7 Reviewed-on: https://go-review.googlesource.com/32441Reviewed-by:
Russ Cox <rsc@golang.org>
-
