- 19 Apr, 2016 10 commits
-
-
Josh Bleecher Snyder authored
Previously, isStaticCompositeLiteral would return the wrong value for literals like: [1]struct{ b []byte }{b: []byte{1}} Note that the outermost component is an array, but once we recurse into isStaticCompositeLiteral, we never check again that arrays are actually arrays. Instead of adding more logic to the guts of isStaticCompositeLiteral, allow it to accept any Node and return the correct answer. Change-Id: I6af7814a9037bbc7043da9a96137fbee067bbe0e Reviewed-on: https://go-review.googlesource.com/22247Reviewed-by:Keith Randall <khr@golang.org>
-
Robert Griesemer authored
Per the latest spec refinement (https://golang.org/cl/19981). Fixes #14537. Change-Id: I2dedee942c4da21dc94bdeda466f133827ab5bb9 Reviewed-on: https://go-review.googlesource.com/22241 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Alan Donovan <adonovan@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Michael Munday authored
There is currently only one assembly implementation of AES (amd64). While it is possible to fit other implementations to the same pattern it complicates the code. For example s390x does not use expanded keys, so having enc and dec in the aesCipher struct is confusing. By separating out the asm implementations we can more closely match the data structures to the underlying implementation. This also opens the door for AES implementations that support block cipher modes other than GCM (e.g. CTR and CBC). This commit changes BenchmarkExpandKey to test the go implementation of key expansion. It might be better to have some sort of 'initialisation' benchmark instead to cover the startup costs of the assembly implementations (which might be doing key expansion in a different way, or not at all). Change-Id: I094a7176b5bbe2177df73163a9c0b711a61c12d6 Reviewed-on: https://go-review.googlesource.com/22193 Run-TryBot: Michael Munday <munday@ca.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org>
-
Josh Bleecher Snyder authored
CL 21891 was too clever in its attempts to avoid spills. Storing newlen too early caused uses of append in the runtime itself to receive an inconsistent view of a slice, leading to corruption. This CL makes the generate code much more similar to the old backend. It spills more than before, but those spills have been contained to the grow path. It recalculates newlen unnecessarily on the fast path, but that's measurably cheaper than spilling it. CL 21891 caused runtime failures in 6 of 2000 runs of net/http and crypto/x509 in my test setup. This CL has gone 6000 runs without a failure. Benchmarks going from master to this CL: name old time/op new time/op delta AppendInPlace/NoGrow/Byte-8 439ns ± 2% 436ns ± 2% -0.72% (p=0.001 n=28+27) AppendInPlace/NoGrow/1Ptr-8 901ns ± 0% 856ns ± 0% -4.95% (p=0.000 n=26+29) AppendInPlace/NoGrow/2Ptr-8 2.15µs ± 1% 1.95µs ± 0% -9.07% (p=0.000 n=28+30) AppendInPlace/NoGrow/3Ptr-8 2.66µs ± 0% 2.45µs ± 0% -7.93% (p=0.000 n=29+26) AppendInPlace/NoGrow/4Ptr-8 3.24µs ± 1% 3.02µs ± 1% -6.75% (p=0.000 n=28+30) AppendInPlace/Grow/Byte-8 269ns ± 1% 271ns ± 1% +0.84% (p=0.000 n=30+29) AppendInPlace/Grow/1Ptr-8 275ns ± 1% 280ns ± 1% +1.75% (p=0.000 n=30+30) AppendInPlace/Grow/2Ptr-8 384ns ± 0% 391ns ± 0% +1.94% (p=0.000 n=27+30) AppendInPlace/Grow/3Ptr-8 455ns ± 0% 462ns ± 0% +1.43% (p=0.000 n=29+29) AppendInPlace/Grow/4Ptr-8 478ns ± 0% 479ns ± 0% +0.23% (p=0.000 n=30+27) However, for the large no-grow cases, there is still more work to be done. Going from this CL to the non-SSA backend: name old time/op new time/op delta AppendInPlace/NoGrow/Byte-8 436ns ± 2% 436ns ± 2% ~ (p=0.967 n=27+29) AppendInPlace/NoGrow/1Ptr-8 856ns ± 0% 884ns ± 0% +3.28% (p=0.000 n=29+26) AppendInPlace/NoGrow/2Ptr-8 1.95µs ± 0% 1.56µs ± 0% -20.28% (p=0.000 n=30+29) AppendInPlace/NoGrow/3Ptr-8 2.45µs ± 0% 1.89µs ± 0% -22.88% (p=0.000 n=26+28) AppendInPlace/NoGrow/4Ptr-8 3.02µs ± 1% 2.56µs ± 1% -15.35% (p=0.000 n=30+28) AppendInPlace/Grow/Byte-8 271ns ± 1% 283ns ± 1% +4.56% (p=0.000 n=29+29) AppendInPlace/Grow/1Ptr-8 280ns ± 1% 288ns ± 1% +2.99% (p=0.000 n=30+30) AppendInPlace/Grow/2Ptr-8 391ns ± 0% 409ns ± 0% +4.66% (p=0.000 n=30+29) AppendInPlace/Grow/3Ptr-8 462ns ± 0% 481ns ± 0% +4.13% (p=0.000 n=29+30) AppendInPlace/Grow/4Ptr-8 479ns ± 0% 502ns ± 0% +4.81% (p=0.000 n=27+26) New generated code: var x []byte func a() { x = append(x, 1) } "".a t=1 size=208 args=0x0 locals=0x48 0x0000 00000 (a.go:5) TEXT "".a(SB), $72-0 0x0000 00000 (a.go:5) MOVQ (TLS), CX 0x0009 00009 (a.go:5) CMPQ SP, 16(CX) 0x000d 00013 (a.go:5) JLS 190 0x0013 00019 (a.go:5) SUBQ $72, SP 0x0017 00023 (a.go:5) FUNCDATA $0, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x0017 00023 (a.go:5) FUNCDATA $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB) 0x0017 00023 (a.go:6) MOVQ "".x+16(SB), CX 0x001e 00030 (a.go:6) MOVQ "".x+8(SB), DX 0x0025 00037 (a.go:6) MOVQ "".x(SB), BX 0x002c 00044 (a.go:6) LEAQ 1(DX), BP 0x0030 00048 (a.go:6) CMPQ BP, CX 0x0033 00051 (a.go:6) JGT $0, 73 0x0035 00053 (a.go:6) LEAQ 1(DX), AX 0x0039 00057 (a.go:6) MOVQ AX, "".x+8(SB) 0x0040 00064 (a.go:6) MOVB $1, (BX)(DX*1) 0x0044 00068 (a.go:7) ADDQ $72, SP 0x0048 00072 (a.go:7) RET 0x0049 00073 (a.go:6) LEAQ type.[]uint8(SB), AX 0x0050 00080 (a.go:6) MOVQ AX, (SP) 0x0054 00084 (a.go:6) MOVQ BX, 8(SP) 0x0059 00089 (a.go:6) MOVQ DX, 16(SP) 0x005e 00094 (a.go:6) MOVQ CX, 24(SP) 0x0063 00099 (a.go:6) MOVQ BP, 32(SP) 0x0068 00104 (a.go:6) PCDATA $0, $0 0x0068 00104 (a.go:6) CALL runtime.growslice(SB) 0x006d 00109 (a.go:6) MOVQ 40(SP), CX 0x0072 00114 (a.go:6) MOVQ 48(SP), DX 0x0077 00119 (a.go:6) MOVQ DX, "".autotmp_0+64(SP) 0x007c 00124 (a.go:6) MOVQ 56(SP), BX 0x0081 00129 (a.go:6) MOVQ BX, "".x+16(SB) 0x0088 00136 (a.go:6) MOVL runtime.writeBarrier(SB), AX 0x008e 00142 (a.go:6) TESTB AL, AL 0x0090 00144 (a.go:6) JNE $0, 162 0x0092 00146 (a.go:6) MOVQ CX, "".x(SB) 0x0099 00153 (a.go:6) MOVQ "".x(SB), BX 0x00a0 00160 (a.go:6) JMP 53 0x00a2 00162 (a.go:6) LEAQ "".x(SB), BX 0x00a9 00169 (a.go:6) MOVQ BX, (SP) 0x00ad 00173 (a.go:6) MOVQ CX, 8(SP) 0x00b2 00178 (a.go:6) PCDATA $0, $0 0x00b2 00178 (a.go:6) CALL runtime.writebarrierptr(SB) 0x00b7 00183 (a.go:6) MOVQ "".autotmp_0+64(SP), DX 0x00bc 00188 (a.go:6) JMP 153 0x00be 00190 (a.go:6) NOP 0x00be 00190 (a.go:5) CALL runtime.morestack_noctxt(SB) 0x00c3 00195 (a.go:5) JMP 0 Fixes #14969 again Change-Id: Ia50463b1f506011aad0718a4fef1d4738e43c32d Reviewed-on: https://go-review.googlesource.com/22197 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: -
Robert Griesemer authored
Per a suggestion from mdempsky. Both gc and gccgo consider a statement list as terminating if the last _non_empty_ statement is terminating; i.e., trailing semis are ok. Only gotype followed the current stricter rule in the spec. This change adjusts the spec to match gc and gccgo behavior. In support of this change, the spec has a matching rule for fallthrough, which in valid positions may be followed by trailing semis as well. For details and examples, see the issue below. Fixes #14422. Change-Id: Ie17c282e216fc40ecb54623445c17be111e17ade Reviewed-on: https://go-review.googlesource.com/19981Reviewed-by:
Ian Lance Taylor <iant@golang.org> Reviewed-by:
Russ Cox <rsc@golang.org>
-
Michael Munday authored
The encryptBlock and decryptBlock functions are already tested (via the public API) by TestCipherEncrypt and TestCipherDecrypt respectively. Both sets of tests check the output of the two functions against the same set of FIPS 197 examples. I therefore think it is safe to delete these two tests without losing any coverage. Deleting these two tests will make it easier to modify the internal API, which I am hoping to do in future CLs. Change-Id: I0dd568bc19f47b70ab09699b507833e527d39ba7 Reviewed-on: https://go-review.googlesource.com/22115Reviewed-by:
Adam Langley <agl@golang.org> Run-TryBot: Adam Langley <agl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Mikio Hara authored
This change adds Zone field to IPNet structure for making it possible to determine which network interface is associated with IPv6 link-local address. Also makes ParseCIDR and IPNet.String capable handling literal IPv6 address prefixes with zone identifier. Fixes #14518. Change-Id: I8f8a40d3b4f500ffef25728d4995651379d8408a Reviewed-on: https://go-review.googlesource.com/19946Reviewed-by:
-
Alex Brainman authored
Go 1.6 requires Windows XP or later. I have: C:\>systeminfo | findstr /B /C:"OS Name" /C:"OS Version" OS Name: Microsoft Windows XP Professional OS Version: 5.1.2600 Service Pack 3 Build 2600 Running "go test" PASSes on my system after this CL is applied. Change-Id: Id59d169138c4a4183322c89ee7e766fb74d381fa Reviewed-on: https://go-review.googlesource.com/22209Reviewed-by:
-
David du Colombier authored
DualStack mode requires dialTCP to support cancellation, which has been implemented for Plan 9 in CL 22144. Updates #11225. Updates #11932. Change-Id: I6e468363dc147326b097b604c122d5af80362787 Reviewed-on: https://go-review.googlesource.com/22204Reviewed-by:
-
David du Colombier authored
TestDialParallel, TestDialerFallbackDelay and TestDialCancel require dialTCP to support cancellation, which has been implemented for Plan 9 in CL 22144. Updates #11225. Updates #11932. Change-Id: I3b30a645ef79227dfa519cde8d46c67b72f2485c Reviewed-on: https://go-review.googlesource.com/22203 Run-TryBot: David du Colombier <0intro@gmail.com> Reviewed-by:
-
- 18 Apr, 2016 17 commits
-
-
Robert Griesemer authored
Per feedback from mdempsky from https://go-review.googlesource.com/22096. Also fix emitted position info. Change-Id: I7ff1967430867d922be8784832042c75d81df28b Reviewed-on: https://go-review.googlesource.com/22198 Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by:
Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David du Colombier authored
On Plan 9, when closing a TCP connection, we write the "hangup" string to the TCP ctl file. The next read on the TCP data file will return an error like "/net/tcp/18/data: Hangup", while in Go, we expect to return io.EOF. This change makes Read to return io.EOF when an error string containing "Hangup" is returned. Change-Id: I3f71ed543704190b441cac4787488a77f46d88a1 Reviewed-on: https://go-review.googlesource.com/22149Reviewed-by:
-
David Crawshaw authored
Use (part of) a SHA-1 checksum to replace type symbol names. In typical programs this has no effect because types are not included in the symbol table. But when dynamically linking, types are in the table to make sure there is only one *rtype per Go type. Eventually we may be able to get rid of all pointers to rtype values in the binary, but probably not by 1.7. And this has a nice effect on binary size today: libstd.so: before 27.4MB after 26.2MB For #6853. Change-Id: I603d7f3e5baad84f59f2fd37eeb1e4ae5acfe44a Reviewed-on: https://go-review.googlesource.com/21583Reviewed-by:
-
Keith Randall authored
Some rewrites to simplify logical operations. Fixes #14363 Change-Id: I45a1e8f227267cbcca0778101125f7bab776a5dd Reviewed-on: https://go-review.googlesource.com/22188Reviewed-by:
Alexandru Moșoi <alexandru@mosoi.ro> Run-TryBot: Alexandru Moșoi <alexandru@mosoi.ro> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
David Crawshaw authored
Instead of writing out the type almost twice in the symbol name, teach the linker how to sort typelink symbols by their contents. This ~halves the size of typelink symbol names, which helps very large (6KB) names like those mentioned in #15104. This does not increase the total sorting work done by the linker, and makes it possible to use shorter symbol names for types. See the follow-on CL 21583. Change-Id: Ie5807565ed07d31bc477d20f60e4c0b47144f337 Reviewed-on: https://go-review.googlesource.com/21457Reviewed-by:
-
David Crawshaw authored
Bug fix went in CL 21396, this is a matching test. Fixes #15343 Change-Id: I3670145c7cac45cb4fb3121ffc039cfb7fa7c87a Reviewed-on: https://go-review.googlesource.com/22171Reviewed-by:
-
Josh Bleecher Snyder authored
Change-Id: I2b43cc976d2efbf8b41170be536fdd10364b65e5 Reviewed-on: https://go-review.googlesource.com/22190Reviewed-by:
-
Keith Randall authored
*p = [5]byte{1,2,3,4,5} First we allocate a global containing the RHS. Then we copy that global to a local stack variable, and then copy that local stack variable to *p. The intermediate copy is unnecessary. Note that this only works if the RHS is completely constant. If the code was: *p = [5]byte{1,2,x,4,5} this optimization doesn't apply as we have to construct the RHS on the stack before copying it to *p. Fixes #12841 Change-Id: I7cd0404ecc7a2d1750cbd8fe1222dba0fa44611f Reviewed-on: https://go-review.googlesource.com/22192Reviewed-by:Josh Bleecher Snyder <josharian@gmail.com>
-
Brad Fitzpatrick authored
My previous https://golang.org/cl/22101 to add context throughout the net package broke Plan 9, which isn't currently tested (#15251). It also broke some old unsupported version of Windows (Windows 2000?) which doesn't have the ConnectEx function, but that was only found visually, since our minimum supported Windows version has ConnectEx. This change simplifies the Windows and deletes the non-ConnectEx code path. Windows 2000 will work even less now, if it even worked before. Windows XP remains our minimum supported version. Specifically, the previous CL stopped using the "dial" function, which 0intro noted: https://github.com/golang/go/issues/15333#issuecomment-210842761 This CL removes the dial function instead and makes plan9's net implementation respect contexts, which likely fixes a number of t.Skipped tests. I'm leaving that to 0intro to investigate. In the process of propagating and respecting contexts for plan9, I had to change some signatures to add contexts to more places and ended up pushing contexts down into the Go-based DNS resolution as well, replacing the pure-Go DNS implementation's use of "timeout time.Duration" with a context instead. Updates #11932 Updates #15328 Fixes #15333 Change-Id: I6ad1e62f38271cdd86b3f40921f2d0f23374936a Reviewed-on: https://go-review.googlesource.com/22144Reviewed-by:
David du Colombier <0intro@gmail.com> Reviewed-by:
Mikio Hara <mikioh.mikioh@gmail.com> Reviewed-by:
-
David Crawshaw authored
The GNU linker follows the letter of -znocopyreloc by refusing to generate COPY relocations on arm64. Unfortunately it generates an error instead of finding another way. The gold linker works, so switch to it. Fixes linux/arm64 build. Change-Id: I1f7119d999c8f9f1f2d0c1e06b6462cea9c02a71 Reviewed-on: https://go-review.googlesource.com/22185 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Brad Fitzpatrick authored
Fixes #15312 Change-Id: I4fabef3f21081bc4b020069851b5c2504bc6b4d8 Reviewed-on: https://go-review.googlesource.com/22122Reviewed-by:
Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by:
Andrew Gerrand <adg@golang.org>
-
Ian Lance Taylor authored
Passes toolstash -cmp. Fixes #15311. Change-Id: I1d67f5c9de38e899ab2d6c8986fabd6f197df23a Reviewed-on: https://go-review.googlesource.com/22162Reviewed-by:
David Crawshaw <crawshaw@golang.org>
-
David Crawshaw authored
Introduce and start using nameOff for two encoded names. This pair of changes is best done together because the linker's method decoder expects the method layouts to match. Precursor to converting all existing name and *string fields to nameOff. linux/amd64: cmd/go: -45KB (0.5%) jujud: -389KB (0.6%) linux/amd64 PIE: cmd/go: -170KB (1.4%) jujud: -1.5MB (1.8%) For #6853. Change-Id: Ia044423f010fb987ce070b94c46a16fc78666ff6 Reviewed-on: https://go-review.googlesource.com/21396Reviewed-by:
-
David Crawshaw authored
On ARM, use the gold linker to avoid copy relocations. https://sourceware.org/bugzilla/show_bug.cgi?id=19962 Change-Id: Icf82a38d39495d4518812713b957a03a6652c728 Reviewed-on: https://go-review.googlesource.com/22141 Run-TryBot: David Crawshaw <crawshaw@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Andrew Gerrand authored
Fixes #15315 Change-Id: I8fea31507a5f83df8a86fb067f1b11d90133dc09 Reviewed-on: https://go-review.googlesource.com/22180Reviewed-by:
Chris Broadfoot <cbro@golang.org>
-
Klaus Post authored
This adds size calculation to "dynamic" writes. This ensures that if dynamic Huffman encoding is bigger, or only slightly smaller than raw data, the block is written uncompressed. To minimize the code duplication of this function, the size calculation has been moved to separate functions. Since I was modifying these calculations, I changed "int64" size calculations to "int". Blocks are of very limited size, so there is not any risk of overflows. This should mainly improve 32 bit performance, but amd64 also gets a slight boost: name old time/op new time/op delta EncodeDigitsHuffman1e4-8 49.9µs ± 1% 49.3µs ± 1% -1.21% (p=0.000 n=10+10) EncodeDigitsHuffman1e5-8 476µs ± 1% 471µs ± 3% ~ (p=0.218 n=10+10) EncodeDigitsHuffman1e6-8 4.80ms ± 2% 4.75ms ± 2% ~ (p=0.243 n=10+9) EncodeDigitsSpeed1e4-8 305µs ± 3% 300µs ± 1% -1.86% (p=0.005 n=10+10) EncodeDigitsSpeed1e5-8 3.67ms ± 2% 3.58ms ± 1% -2.29% (p=0.000 n=9+8) EncodeDigitsSpeed1e6-8 38.3ms ± 2% 37.0ms ± 1% -3.45% (p=0.000 n=9+9) EncodeDigitsDefault1e4-8 361µs ± 2% 353µs ± 1% -2.21% (p=0.000 n=10+10) EncodeDigitsDefault1e5-8 5.24ms ± 2% 5.19ms ± 2% ~ (p=0.105 n=10+10) EncodeDigitsDefault1e6-8 56.5ms ± 3% 55.1ms ± 1% -2.42% (p=0.001 n=10+10) EncodeDigitsCompress1e4-8 362µs ± 2% 358µs ± 2% ~ (p=0.123 n=10+10) EncodeDigitsCompress1e5-8 5.26ms ± 3% 5.20ms ± 1% ~ (p=0.089 n=10+10) EncodeDigitsCompress1e6-8 56.0ms ± 4% 55.0ms ± 1% ~ (p=0.065 n=10+9) EncodeTwainHuffman1e4-8 70.9µs ± 3% 67.6µs ± 2% -4.59% (p=0.000 n=10+10) EncodeTwainHuffman1e5-8 556µs ± 2% 533µs ± 1% -4.20% (p=0.000 n=10+10) EncodeTwainHuffman1e6-8 5.54ms ± 3% 5.29ms ± 1% -4.37% (p=0.000 n=10+9) EncodeTwainSpeed1e4-8 294µs ± 3% 293µs ± 1% ~ (p=0.965 n=10+8) EncodeTwainSpeed1e5-8 2.59ms ± 2% 2.56ms ± 1% ~ (p=0.353 n=10+10) EncodeTwainSpeed1e6-8 25.6ms ± 1% 24.9ms ± 1% -2.62% (p=0.000 n=9+10) EncodeTwainDefault1e4-8 419µs ± 2% 417µs ± 1% ~ (p=0.780 n=10+9) EncodeTwainDefault1e5-8 6.23ms ± 4% 6.16ms ± 1% ~ (p=0.218 n=10+10) EncodeTwainDefault1e6-8 66.2ms ± 2% 65.7ms ± 1% ~ (p=0.529 n=10+10) EncodeTwainCompress1e4-8 426µs ± 1% 428µs ± 2% ~ (p=0.549 n=9+10) EncodeTwainCompress1e5-8 6.80ms ± 1% 6.85ms ± 3% ~ (p=0.156 n=9+10) EncodeTwainCompress1e6-8 74.6ms ± 3% 73.8ms ± 2% ~ (p=0.280 n=10+10) name old speed new speed delta EncodeDigitsHuffman1e4-8 200MB/s ± 1% 203MB/s ± 1% +1.23% (p=0.000 n=10+10) EncodeDigitsHuffman1e5-8 210MB/s ± 1% 212MB/s ± 3% ~ (p=0.356 n=10+9) EncodeDigitsHuffman1e6-8 208MB/s ± 2% 210MB/s ± 2% ~ (p=0.243 n=10+9) EncodeDigitsSpeed1e4-8 32.8MB/s ± 3% 33.4MB/s ± 1% +1.88% (p=0.005 n=10+10) EncodeDigitsSpeed1e5-8 27.2MB/s ± 2% 27.9MB/s ± 1% +2.60% (p=0.000 n=10+8) EncodeDigitsSpeed1e6-8 26.1MB/s ± 2% 27.0MB/s ± 1% +3.56% (p=0.000 n=9+9) EncodeDigitsDefault1e4-8 27.7MB/s ± 2% 28.4MB/s ± 1% +2.24% (p=0.000 n=10+10) EncodeDigitsDefault1e5-8 19.1MB/s ± 2% 19.3MB/s ± 2% ~ (p=0.101 n=10+10) EncodeDigitsDefault1e6-8 17.7MB/s ± 3% 18.1MB/s ± 1% +2.46% (p=0.001 n=10+10) EncodeDigitsCompress1e4-8 27.6MB/s ± 2% 27.9MB/s ± 2% ~ (p=0.119 n=10+10) EncodeDigitsCompress1e5-8 19.0MB/s ± 3% 19.2MB/s ± 1% ~ (p=0.085 n=10+10) EncodeDigitsCompress1e6-8 17.9MB/s ± 4% 18.1MB/s ± 3% ~ (p=0.110 n=10+10) EncodeTwainHuffman1e4-8 141MB/s ± 3% 148MB/s ± 2% +4.79% (p=0.000 n=10+10) EncodeTwainHuffman1e5-8 180MB/s ± 2% 188MB/s ± 1% +4.38% (p=0.000 n=10+10) EncodeTwainHuffman1e6-8 181MB/s ± 3% 189MB/s ± 1% +4.54% (p=0.000 n=10+9) EncodeTwainSpeed1e4-8 34.0MB/s ± 3% 34.1MB/s ± 1% ~ (p=0.948 n=10+8) EncodeTwainSpeed1e5-8 38.7MB/s ± 2% 39.0MB/s ± 1% ~ (p=0.353 n=10+10) EncodeTwainSpeed1e6-8 39.1MB/s ± 1% 40.1MB/s ± 1% +2.68% (p=0.000 n=9+10) EncodeTwainDefault1e4-8 23.9MB/s ± 2% 24.0MB/s ± 1% ~ (p=0.734 n=10+9) EncodeTwainDefault1e5-8 16.0MB/s ± 4% 16.2MB/s ± 1% ~ (p=0.210 n=10+10) EncodeTwainDefault1e6-8 15.1MB/s ± 2% 15.2MB/s ± 1% ~ (p=0.515 n=10+10) EncodeTwainCompress1e4-8 23.5MB/s ± 1% 23.4MB/s ± 2% ~ (p=0.536 n=9+10) EncodeTwainCompress1e5-8 14.7MB/s ± 1% 14.6MB/s ± 3% ~ (p=0.138 n=9+10) EncodeTwainCompress1e6-8 13.4MB/s ± 3% 13.5MB/s ± 2% ~ (p=0.239 n=10+10) This improves "random input" to the dynamic writer, which is why the test data is updated. The output size goes from 1051 to 1005 bytes. Change-Id: I3ee11d2d2511b277d2dd16734aeea07c98bca450 Reviewed-on: https://go-review.googlesource.com/21757Reviewed-by:
Joe Tsai <joetsai@digital-static.net> Run-TryBot: Joe Tsai <joetsai@digital-static.net> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
Nigel Tao <nigeltao@golang.org>
-
David Symonds authored
Updates #15292. Change-Id: I229f66c2a41ae0738225f2ba7a574478f5d6d620 Reviewed-on: https://go-review.googlesource.com/22163Reviewed-by:
-
- 17 Apr, 2016 6 commits
-
-
Ian Lance Taylor authored
We no longer use yacc, and we shouldn't have any y.output files. Change-Id: I045671b6aef3f53c3cfe068b0c14a4871689c13e Reviewed-on: https://go-review.googlesource.com/22161 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Emmanuel Odeke authored
Fixes #15339 Change-Id: I0b006deefb58ccfc47beae4e1b8da3d77fafda6b Reviewed-on: https://go-review.googlesource.com/22148Reviewed-by:
Rob Pike <r@golang.org>
-
Martin Möhrmann authored
Ignore the f.zero flag and use spaces for padding instead when precision is set. Fixes #15331 Change-Id: I3ac485df24b7bdf4fddf69e3cc17c213c737b5ff Reviewed-on: https://go-review.googlesource.com/22131 Run-TryBot: Rob Pike <r@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
Change-Id: I05659a836612f958083fea9a27805eb9f0ac0836 Reviewed-on: https://go-review.googlesource.com/22145 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
It’d be nicer to write just _ = dpix[x+3] but the compiler isn’t able to reason about offsets from symbols (yet). image/draw benchmark: YCbCr-8 722µs ± 3% 682µs ± 3% -5.54% (p=0.000 n=50+50) Change-Id: Ia1e399496ed87c282bf0f9ca56c0b2d4948a0df9 Reviewed-on: https://go-review.googlesource.com/22146 Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by:
-
Josh Bleecher Snyder authored
They have different semantics. Equal is stricter and is designed for the front-end. Compare is looser and cheaper and is designed for the back-end. To avoid possible regression, remove Equal from ssa.Type. Updates #15043 Change-Id: Ie23ce75ff6b4d01b7982e0a89e6f81b5d099d8d6 Reviewed-on: https://go-review.googlesource.com/21483Reviewed-by:
David Chase <drchase@google.com> Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
-
- 16 Apr, 2016 7 commits
-
-
Brad Fitzpatrick authored
In JSON terminology, "object" is a collect of key/value pairs. But a JSON object is only one type of JSON value (others are string, number, array, true, false, null). This updates the Go docs (at least the public godoc) to not use "object" when we mean any JSON value. Change-Id: Ieb1c456c703693714d63d9d09d306f4d9e8f4597 Reviewed-on: https://go-review.googlesource.com/22003Reviewed-by:
-
Austin Clements authored
Currently the scavenger marks memory unused in multiples of the allocator page size (8K). This is safe as long as the true physical page size is 4K (or 8K), as it is on many platforms. However, on ARM64, PPC64x, and MIPS64, the physical page size is larger than 8K, so if we attempt to mark memory unused, the kernel will round the boundaries of the region *out* to all pages covered by the requested region, and we'll release a larger region of memory than intended. As a result, the scavenger is currently disabled on these platforms. Fix this by first rounding the region to be marked unused *in* to multiples of the physical page size, so that when we ask the kernel to mark it unused, it releases exactly the requested region. Fixes #9993. Change-Id: I96d5fdc2f77f9d69abadcea29bcfe55e68288cb1 Reviewed-on: https://go-review.googlesource.com/22066Reviewed-by:
Rick Hudson <rlh@golang.org>
-
Austin Clements authored
If sysUnused is passed an address or length that is not aligned to the physical page boundary, the kernel will unmap more memory than the caller wanted. Add a check for this. For #9993. Change-Id: I68ff03032e7b65cf0a853fe706ce21dc7f2aaaf8 Reviewed-on: https://go-review.googlesource.com/22065Reviewed-by:
Dave Cheney <dave@cheney.net> Reviewed-by:
Michael Hudson-Doyle <michael.hudson@canonical.com>
-
Austin Clements authored
The runtime hard-codes an assumed physical page size. If this is smaller than the kernel's page size or not a multiple of it, sysUnused may incorrectly release more memory to the system than intended. Add a runtime startup check that the runtime's assumed physical page is compatible with the kernel's physical page size. For #9993. Change-Id: Ida9d07f93c00ca9a95dd55fc59bf0d8a607f6728 Reviewed-on: https://go-review.googlesource.com/22064Reviewed-by:
-
Austin Clements authored
archauxv no longer does anything on 386, so remove it. Change-Id: I94545238e40fa6a6832a7c3b40aedfc6c1f6a97b Reviewed-on: https://go-review.googlesource.com/22063Reviewed-by:
-
Austin Clements authored
The Linux kernel provides 16 bytes of random data via the auxv vector at startup. Currently we consume this separately on 386, amd64, arm, and arm64. Now that we have a common auxv parser, handle _AT_RANDOM in the common path. Change-Id: Ib69549a1d37e2d07a351cf0f44007bcd24f0d20d Reviewed-on: https://go-review.googlesource.com/22062Reviewed-by:
-
Austin Clements authored
Currently several different Linux architectures have separate copies of the auxv parser. Bring these all together into a single copy of the parser that calls out to a per-arch handler for each tag/value pair. This is in preparation for handling common auxv tags in one place. For #9993. Change-Id: Iceebc3afad6b4133b70fca7003561ae370445c10 Reviewed-on: https://go-review.googlesource.com/22061 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
-
