- 27 Jun, 2014 4 commits
-
-
Andrew Gerrand authored
Include these files in the build, even though they don't get executed. LGTM=r R=golang-codereviews, r CC=golang-codereviews https://golang.org/cl/108180043
-
Evan Shaw authored
LGTM=r R=golang-codereviews, bradfitz, r CC=golang-codereviews https://golang.org/cl/102640046
-
Anthony Martin authored
LGTM=0intro, aram R=rsc, 0intro, aram CC=golang-codereviews https://golang.org/cl/109240044
-
Dmitriy Vyukov authored
Output number of spinning threads, this is useful to understanding whether the scheduler is in a steady state or not. R=golang-codereviews, khr CC=golang-codereviews, rsc https://golang.org/cl/103540045
-
- 26 Jun, 2014 6 commits
-
-
Josh Bleecher Snyder authored
LGTM=ruiu R=golang-codereviews, ruiu CC=golang-codereviews https://golang.org/cl/108150043
-
Dmitriy Vyukov authored
Say when a goroutine is locked to OS thread in crash reports and goroutine profiles. It can be useful to understand what goroutines consume OS threads (syscall and locked), e.g. if you forget to call UnlockOSThread or leak locked goroutines. R=golang-codereviews CC=golang-codereviews, rsc https://golang.org/cl/94170043
-
Evan Kroske authored
LGTM=iant R=golang-codereviews, gobot, iant, dave CC=golang-codereviews https://golang.org/cl/108990044
-
Ian Lance Taylor authored
LGTM=bradfitz R=bradfitz CC=golang-codereviews https://golang.org/cl/110160045
-
Robert Griesemer authored
Pending acceptance of CL 101500044 and adjustment of test/fixedbugs/bug299.go. LGTM=adonovan R=golang-codereviews, adonovan CC=golang-codereviews https://golang.org/cl/110160043
-
Russ Cox authored
The runtime has historically held two dedicated values g (current goroutine) and m (current thread) in 'extern register' slots (TLS on x86, real registers backed by TLS on ARM). This CL removes the extern register m; code now uses g->m. On ARM, this frees up the register that formerly held m (R9). This is important for NaCl, because NaCl ARM code cannot use R9 at all. The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected: BenchmarkBinaryTree17 5491374955 5471024381 -0.37% BenchmarkFannkuch11 4357101311 4275174828 -1.88% BenchmarkGobDecode 11029957 11364184 +3.03% BenchmarkGobEncode 6852205 6784822 -0.98% BenchmarkGzip 650795967 650152275 -0.10% BenchmarkGunzip 140962363 141041670 +0.06% BenchmarkHTTPClientServer 71581 73081 +2.10% BenchmarkJSONEncode 31928079 31913356 -0.05% BenchmarkJSONDecode 117470065 113689916 -3.22% BenchmarkMandelbrot200 6008923 5998712 -0.17% BenchmarkGoParse 6310917 6327487 +0.26% BenchmarkRegexpMatchMedium_1K 114568 114763 +0.17% BenchmarkRegexpMatchHard_1K 168977 169244 +0.16% BenchmarkRevcomp 935294971 914060918 -2.27% BenchmarkTemplate 145917123 148186096 +1.55% Minux previous reported larger variations, but these were caused by run-to-run noise, not repeatable slowdowns. Actual code changes by Minux. I only did the docs and the benchmarking. LGTM=dvyukov, iant, minux R=minux, josharian, iant, dave, bradfitz, dvyukov CC=golang-codereviews https://golang.org/cl/109050043
-
- 25 Jun, 2014 4 commits
-
-
Russ Cox authored
Matches CL 101500044. LGTM=gri R=gri CC=golang-codereviews https://golang.org/cl/110160044
-
Dmitriy Vyukov authored
A single iteration of BenchmarkSaveRestore runs for 5 seconds on my freebsd machine. 5 seconds looks like too long for a single iteration. This is the only benchmark that times out on freebsd-amd64-race builder. R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/107340044
-
Andrew Gerrand authored
Breaks the build ««« original CL description cmd/go: build test files containing non-runnable examples Even if we can't run them, we should at least check that they compile. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/107320046 »»» TBR=rsc R=rsc CC=golang-codereviews https://golang.org/cl/110140044
-
Dmitriy Vyukov authored
Runs for 4 seconds on my mac. Also this is the only test that times out on freebsd in -race mode. R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/110150045
-
- 24 Jun, 2014 13 commits
-
-
Mihai Borobocea authored
LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/110110045
-
Ian Lance Taylor authored
LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/101520043
-
Robert Griesemer authored
This CL removes the special syntax for method receivers and makes it just like other parameters. Instead, the crucial receiver-specific rules (exactly one receiver, receiver type must be of the form T or *T) are specified verbally instead of syntactically. This is a fully backward-compatible (and minor) syntax relaxation. As a result, the following syntactic restrictions (which are completely irrelevant) and which were only in place for receivers are removed: a) receiver types cannot be parenthesized b) receiver parameter lists cannot have a trailing comma The result of this CL is a simplication of the spec and the implementation, with no impact on existing (or future) code. Noteworthy: - gc already permits a trailing comma at the end of a receiver declaration: func (recv T,) m() {} This is technically a bug with the current spec; this CL will legalize this notation. - gccgo produces a misleading error when a trailing comma is used: error: method has multiple receivers (even though there's only one receiver) - Compilers and type-checkers won't need to report errors anymore if receiver types are parenthesized. Fixes #4496. LGTM=iant, rsc R=r, rsc, iant, ken CC=golang-codereviews https://golang.org/cl/101500044
-
Dmitriy Vyukov authored
R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/110150044
-
Andrew Gerrand authored
Even if we can't run them, we should at least check that they compile. LGTM=bradfitz R=golang-codereviews, bradfitz CC=golang-codereviews https://golang.org/cl/107320046
-
William Orr authored
Fixes #8218. LGTM=iant R=golang-codereviews, iant, minux CC=golang-codereviews https://golang.org/cl/107150043
-
Mikio Hara authored
Update #8266 LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/101460043
-
Glenn Lewis authored
For work on goauth2. LGTM=adg R=adg CC=golang-codereviews https://golang.org/cl/110150043
-
Rob Pike authored
R=gri CC=golang-codereviews https://golang.org/cl/104340043
-
Dave Cheney authored
This CL re-applies the tests added in CL 101330053 and subsequently rolled back in CL 102610043. The original author of this change was Rui Ueyama <ruiu@google.com> LGTM=r, ruiu R=ruiu, r CC=golang-codereviews https://golang.org/cl/109170043
-
Josh Bleecher Snyder authored
The number of estimated iterations required to reach the benchtime is multiplied by a safety margin (to avoid falling just short) and then rounded up to a readable number. With an accurate estimate, in the worse case, the resulting number of iterations could be 3.75x more than necessary: 1.5x for safety * 2.5x to round up (e.g. from 2eX+1 to 5eX). This CL reduces the safety margin to 1.2x. Experimentation showed a diminishing margin of return past 1.2x, although the average case continued to show improvements down to 1.05x. This CL also reduces the maximum round-up multiplier from 2.5x (from 2eX+1 to 5eX) to 2x, by allowing the number of iterations to be of the form 3eX. Both changes improve benchmark wall clock times, and the effects are cumulative. From 1.5x to 1.2x safety margin: package old s new s delta bytes 163 125 -23% encoding/json 27 21 -22% net/http 42 36 -14% runtime 463 418 -10% strings 82 65 -21% Allowing 3eX iterations: package old s new s delta bytes 163 134 -18% encoding/json 27 23 -15% net/http 42 36 -14% runtime 463 422 -9% strings 82 72 -12% Combined: package old s new s delta bytes 163 112 -31% encoding/json 27 20 -26% net/http 42 30 -29% runtime 463 346 -25% strings 82 60 -27% LGTM=crawshaw, r, rsc R=golang-codereviews, crawshaw, r, rsc CC=golang-codereviews https://golang.org/cl/105990045
-
Robert Obryk authored
The previous call to parseRange already checks whether all the ranges start before the end of file. LGTM=robert.hencke, bradfitz R=golang-codereviews, robert.hencke, gobot, bradfitz CC=golang-codereviews https://golang.org/cl/91880044
-
Mikio Hara authored
Updates z-files from 10.7 kernel-based to 10.9 kernel-based. LGTM=iant R=golang-codereviews, bradfitz, iant CC=golang-codereviews https://golang.org/cl/102610045
-
- 23 Jun, 2014 7 commits
-
-
Dave Cheney authored
LGTM=iant R=ruiu, iant CC=golang-codereviews https://golang.org/cl/107320044
-
Dave Cheney authored
Update #1435 This proposal disables Setuid and Setgid on all linux platforms. Issue 1435 has been open for a long time, and it is unlikely to be addressed soon so an argument was made by a commenter https://code.google.com/p/go/issues/detail?id=1435#c45 That these functions should made to fail rather than succeed in their broken state. LGTM=ruiu, iant R=iant, ruiu CC=golang-codereviews https://golang.org/cl/106170043
-
Mikio Hara authored
Update #8266 LGTM=iant R=golang-codereviews, iant CC=golang-codereviews https://golang.org/cl/104290043
-
Rui Ueyama authored
MOV with SSE registers seems faster than REP MOVSQ if the size being copied is less than about 2K. Previously we didn't use MOV if the memory region is larger than 256 byte. This patch improves the performance of 257 ~ 2048 byte non-overlapping copy by using MOV. Here is the benchmark result on Intel Xeon 3.5GHz (Nehalem). benchmark old ns/op new ns/op delta BenchmarkMemmove16 4 4 +0.42% BenchmarkMemmove32 5 5 -0.20% BenchmarkMemmove64 6 6 -0.81% BenchmarkMemmove128 7 7 -0.82% BenchmarkMemmove256 10 10 +1.92% BenchmarkMemmove512 29 16 -44.90% BenchmarkMemmove1024 37 25 -31.55% BenchmarkMemmove2048 55 44 -19.46% BenchmarkMemmove4096 92 91 -0.76% benchmark old MB/s new MB/s speedup BenchmarkMemmove16 3370.61 3356.88 1.00x BenchmarkMemmove32 6368.68 6386.99 1.00x BenchmarkMemmove64 10367.37 10462.62 1.01x BenchmarkMemmove128 17551.16 17713.48 1.01x BenchmarkMemmove256 24692.81 24142.99 0.98x BenchmarkMemmove512 17428.70 31687.72 1.82x BenchmarkMemmove1024 27401.82 40009.45 1.46x BenchmarkMemmove2048 36884.86 45766.98 1.24x BenchmarkMemmove4096 44295.91 44627.86 1.01x LGTM=khr R=golang-codereviews, gobot, khr CC=golang-codereviews https://golang.org/cl/90500043
-
Mikio Hara authored
Also exposes common socket option functions on Solaris. Update #7174 Update #7175 LGTM=aram R=golang-codereviews, aram CC=golang-codereviews https://golang.org/cl/107280044
-
Mikio Hara authored
LGTM=dave R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/110020050
-
Rui Ueyama authored
paeth(0, x, 0) == x for any uint8 value. LGTM=nigeltao R=golang-codereviews, bradfitz, nigeltao CC=golang-codereviews https://golang.org/cl/105290049
-
- 22 Jun, 2014 3 commits
-
-
Rui Ueyama authored
sync.Pool is not supposed to be used everywhere, but is a last resort. ««« original CL description strings: use sync.Pool to cache buffer benchmark old ns/op new ns/op delta BenchmarkByteReplacerWriteString 3596 3094 -13.96% benchmark old allocs new allocs delta BenchmarkByteReplacerWriteString 1 0 -100.00% LGTM=dvyukov R=bradfitz, dave, dvyukov CC=golang-codereviews https://golang.org/cl/101330053 »»» LGTM=dave R=r, dave CC=golang-codereviews https://golang.org/cl/102610043
-
Dave Cheney authored
Fixes #8074. The issue was not reproduceable by revision go version devel +e0ad7e329637 Thu Jun 19 22:19:56 2014 -0700 linux/arm But include the original test case in case the issue reopens itself. LGTM=dvyukov R=golang-codereviews, dvyukov CC=golang-codereviews https://golang.org/cl/107290043
-
Rui Ueyama authored
benchmark old ns/op new ns/op delta BenchmarkByteReplacerWriteString 3596 3094 -13.96% benchmark old allocs new allocs delta BenchmarkByteReplacerWriteString 1 0 -100.00% LGTM=dvyukov R=bradfitz, dave, dvyukov CC=golang-codereviews https://golang.org/cl/101330053
-
- 21 Jun, 2014 3 commits
-
-
Dmitriy Vyukov authored
R=golang-codereviews CC=golang-codereviews https://golang.org/cl/103520044
-
Dmitriy Vyukov authored
LGTM=ruiu R=golang-codereviews, ruiu CC=golang-codereviews https://golang.org/cl/109100046
-
Dmitriy Vyukov authored
LGTM=dave R=golang-codereviews, dave CC=golang-codereviews https://golang.org/cl/102580043
-