- 22 Feb, 2018 9 commits
-
-
Tobias Klauser authored
The syscall package is frozen and we don't want to encourage anyone to implement these syscalls. Change-Id: I6b6e33e32a4b097da6012226aa15300735e50e9f Reviewed-on: https://go-review.googlesource.com/96315Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Robert Griesemer authored
The variables on the lhs of a short variable declaration are only in scope after the variable declaration. Specifically, function literals on the rhs of a short variable declaration must not see newly declared variables on the lhs. This used to work and this bug was likely introduced with https://go-review.googlesource.com/c/go/+/83397 for go1.11. Luckily this is just an oversight and the fix is trivial: Simply use the mechanism for delayed type-checkin of function literals introduced in the before-mentioned change here as well. Fixes #24026. Change-Id: I74ce3a0d05c5a2a42ce4b27601645964f906e82d Reviewed-on: https://go-review.googlesource.com/96177Reviewed-by: Alan Donovan <adonovan@google.com>
-
Ben Shi authored
Two ARM64 rules are added to avoid FP accuracy issue, which causes build failure. https://build.golang.org/log/1360f5c9ef3f37968216350283c1013e9681725d fixes #24033 Change-Id: I9b74b584ab5cc53fa49476de275dc549adf97610 Reviewed-on: https://go-review.googlesource.com/96355Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Alexey Palazhchenko authored
Fixes #23632 Change-Id: I7197e13df6cf28400a6dd86c110f41129550abb6 Reviewed-on: https://go-review.googlesource.com/92235Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
-
Alberto Donizetti authored
For now, limited to the most repetitive rules that are also short and simple, so that we can have a substantial conciseness win without compromising rules readability. Ran rulegen, no changes in the rewrite files. Change-Id: I8447784895a218c5c1b4dfa1cdb355bd73dabfd1 Reviewed-on: https://go-review.googlesource.com/95955Reviewed-by: Giovanni Bajo <rasky@develer.com>
-
Martin Möhrmann authored
If the type of Type is known to be *rtype than the common function is a no-op and does not need to be called. name old time/op new time/op delta New 31.0ns ± 5% 30.2ns ± 4% -2.74% (p=0.008 n=20+20) Change-Id: I5d00346dbc782e34c530166d1ee0499b24068b51 Reviewed-on: https://go-review.googlesource.com/96115Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ben Shi authored
FMADD/FMSUB/FNMADD/FNMSUB are efficient FP instructions, which can be used by the comiler to improve FP performance. This CL implements this optimization. 1. The compilecmp benchmark shows little change. name old time/op new time/op delta Template 2.35s ± 4% 2.38s ± 4% ~ (p=0.161 n=15+15) Unicode 1.36s ± 5% 1.36s ± 4% ~ (p=0.685 n=14+13) GoTypes 8.11s ± 3% 8.13s ± 2% ~ (p=0.624 n=15+15) Compiler 40.5s ± 2% 40.7s ± 2% ~ (p=0.137 n=15+15) SSA 115s ± 3% 116s ± 1% ~ (p=0.270 n=15+14) Flate 1.46s ± 4% 1.45s ± 5% ~ (p=0.870 n=15+15) GoParser 1.85s ± 2% 1.87s ± 3% ~ (p=0.477 n=14+15) Reflect 5.11s ± 4% 5.10s ± 2% ~ (p=0.624 n=15+15) Tar 2.23s ± 3% 2.23s ± 5% ~ (p=0.624 n=15+15) XML 2.72s ± 5% 2.74s ± 3% ~ (p=0.290 n=15+14) [Geo mean] 5.02s 5.03s +0.29% name old user-time/op new user-time/op delta Template 2.90s ± 2% 2.90s ± 3% ~ (p=0.780 n=14+15) Unicode 1.71s ± 5% 1.70s ± 3% ~ (p=0.458 n=14+13) GoTypes 9.77s ± 2% 9.76s ± 2% ~ (p=0.838 n=15+15) Compiler 49.1s ± 2% 49.1s ± 2% ~ (p=0.902 n=15+15) SSA 144s ± 1% 144s ± 2% ~ (p=0.567 n=15+15) Flate 1.75s ± 5% 1.74s ± 3% ~ (p=0.461 n=15+15) GoParser 2.22s ± 2% 2.21s ± 3% ~ (p=0.233 n=15+15) Reflect 5.99s ± 2% 5.95s ± 1% ~ (p=0.093 n=14+15) Tar 2.68s ± 2% 2.67s ± 3% ~ (p=0.310 n=14+15) XML 3.22s ± 2% 3.24s ± 3% ~ (p=0.512 n=15+15) [Geo mean] 6.08s 6.07s -0.19% name old text-bytes new text-bytes delta HelloSize 641kB ± 0% 641kB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 9.46kB ± 0% 9.46kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 125kB ± 0% 125kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.24MB ± 0% 1.24MB ± 0% ~ (all equal) 2. The go1 benchmark shows little improvement in total (excluding noise), but some improvement in test case Mandelbrot200 and FmtFprintfFloat. name old time/op new time/op delta BinaryTree17-4 42.1s ± 2% 42.0s ± 2% ~ (p=0.453 n=30+28) Fannkuch11-4 33.5s ± 3% 33.3s ± 3% -0.38% (p=0.045 n=30+30) FmtFprintfEmpty-4 534ns ± 0% 534ns ± 0% ~ (all equal) FmtFprintfString-4 1.09µs ± 0% 1.09µs ± 0% -0.27% (p=0.000 n=23+17) FmtFprintfInt-4 1.16µs ± 3% 1.16µs ± 3% ~ (p=0.714 n=30+30) FmtFprintfIntInt-4 1.76µs ± 1% 1.77µs ± 0% +0.15% (p=0.002 n=23+23) FmtFprintfPrefixedInt-4 2.21µs ± 3% 2.20µs ± 3% ~ (p=0.390 n=30+30) FmtFprintfFloat-4 3.28µs ± 0% 3.11µs ± 0% -5.01% (p=0.000 n=25+26) FmtManyArgs-4 7.18µs ± 0% 7.19µs ± 0% +0.13% (p=0.000 n=24+25) GobDecode-4 94.9ms ± 0% 95.6ms ± 5% +0.83% (p=0.002 n=23+29) GobEncode-4 80.7ms ± 4% 79.8ms ± 0% -1.11% (p=0.003 n=30+24) Gzip-4 4.58s ± 4% 4.59s ± 3% +0.26% (p=0.002 n=30+26) Gunzip-4 449ms ± 4% 443ms ± 0% ~ (p=0.096 n=30+26) HTTPClientServer-4 553µs ± 1% 548µs ± 1% -0.96% (p=0.000 n=30+30) JSONEncode-4 215ms ± 4% 214ms ± 4% -0.29% (p=0.000 n=30+30) JSONDecode-4 868ms ± 4% 875ms ± 5% +0.79% (p=0.008 n=30+30) Mandelbrot200-4 51.4ms ± 0% 46.7ms ± 3% -9.09% (p=0.000 n=25+26) GoParse-4 42.1ms ± 0% 41.8ms ± 0% -0.61% (p=0.000 n=25+24) RegexpMatchEasy0_32-4 1.02µs ± 4% 1.02µs ± 4% -0.17% (p=0.000 n=30+30) RegexpMatchEasy0_1K-4 3.90µs ± 0% 3.95µs ± 4% ~ (p=0.516 n=23+30) RegexpMatchEasy1_32-4 970ns ± 3% 973ns ± 3% ~ (p=0.951 n=30+30) RegexpMatchEasy1_1K-4 6.43µs ± 3% 6.33µs ± 0% -1.62% (p=0.000 n=30+25) RegexpMatchMedium_32-4 1.75µs ± 0% 1.75µs ± 0% ~ (p=0.422 n=25+24) RegexpMatchMedium_1K-4 568µs ± 3% 562µs ± 0% ~ (p=0.079 n=30+24) RegexpMatchHard_32-4 30.8µs ± 0% 31.2µs ± 4% +1.46% (p=0.018 n=23+30) RegexpMatchHard_1K-4 932µs ± 0% 946µs ± 3% +1.49% (p=0.000 n=24+30) Revcomp-4 7.69s ± 3% 7.69s ± 2% +0.04% (p=0.032 n=24+25) Template-4 893ms ± 5% 880ms ± 6% -1.53% (p=0.000 n=30+30) TimeParse-4 4.90µs ± 3% 4.84µs ± 0% ~ (p=0.080 n=30+25) TimeFormat-4 4.70µs ± 1% 4.76µs ± 0% +1.21% (p=0.000 n=23+26) [Geo mean] 710µs 706µs -0.63% name old speed new speed delta GobDecode-4 8.09MB/s ± 0% 8.03MB/s ± 5% -0.77% (p=0.002 n=23+29) GobEncode-4 9.52MB/s ± 4% 9.62MB/s ± 0% +1.07% (p=0.003 n=30+24) Gzip-4 4.24MB/s ± 4% 4.23MB/s ± 3% -0.35% (p=0.002 n=30+26) Gunzip-4 43.2MB/s ± 4% 43.8MB/s ± 0% ~ (p=0.123 n=30+26) JSONEncode-4 9.03MB/s ± 4% 9.06MB/s ± 4% +0.28% (p=0.000 n=30+30) JSONDecode-4 2.24MB/s ± 4% 2.22MB/s ± 5% -0.79% (p=0.008 n=30+30) GoParse-4 1.38MB/s ± 1% 1.38MB/s ± 0% ~ (p=0.401 n=25+17) RegexpMatchEasy0_32-4 31.4MB/s ± 4% 31.5MB/s ± 3% +0.16% (p=0.000 n=30+30) RegexpMatchEasy0_1K-4 262MB/s ± 0% 259MB/s ± 4% ~ (p=0.693 n=23+30) RegexpMatchEasy1_32-4 33.0MB/s ± 3% 32.9MB/s ± 3% ~ (p=0.139 n=30+30) RegexpMatchEasy1_1K-4 159MB/s ± 3% 162MB/s ± 0% +1.60% (p=0.000 n=30+25) RegexpMatchMedium_32-4 570kB/s ± 0% 570kB/s ± 0% ~ (all equal) RegexpMatchMedium_1K-4 1.80MB/s ± 3% 1.82MB/s ± 0% +1.09% (p=0.007 n=30+24) RegexpMatchHard_32-4 1.04MB/s ± 0% 1.03MB/s ± 3% -1.38% (p=0.003 n=23+30) RegexpMatchHard_1K-4 1.10MB/s ± 0% 1.08MB/s ± 3% -1.52% (p=0.000 n=24+30) Revcomp-4 33.0MB/s ± 3% 33.0MB/s ± 2% ~ (p=0.128 n=24+25) Template-4 2.17MB/s ± 5% 2.21MB/s ± 6% +1.61% (p=0.000 n=30+30) [Geo mean] 7.79MB/s 7.79MB/s +0.05% Change-Id: Ied3dbdb5ba8e386168629cba06fcd4263bbb83e1 Reviewed-on: https://go-review.googlesource.com/94901 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
erifan01 authored
Add arm64 HW instructions FMADDD, FMADDS, FMSUBD, FMSUBS, FNMADDD, FNMADDS, FNMSUBD, FNMSUBS, VFMLA, VFMLS, VMOV (element) for math optimization. Add check on register element index and test cases. Change-Id: Ice07c50b1a02d488ad2cde2a4e8aea93f3e3afff Reviewed-on: https://go-review.googlesource.com/90876Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
David Chase authored
While tinkering with different block orders for the preemptible loop experiment, crashed the register allocator with a "bad" one (these exist). Realized that one knob was controlling two things (register allocation and branch patterns) and decided that life would be simpler if the two orders were independent. Ran some experiments and determined that we have probably, mostly, been optimizing for register allocation effects, not branch effects. Bad block orders for register allocation are somewhat costly. This will also allow separate experimentation with perhaps- better block orders for register allocation. Change-Id: I6ecf2f24cca178b6f8acc0d3c4caaef043c11ed9 Reviewed-on: https://go-review.googlesource.com/47314 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
- 21 Feb, 2018 29 commits
-
-
Hana Kim authored
Enabled when the tool runs with DEBUG_MEMORY_USAGE=1 env var. After reporting the usage, it waits until user enters input (helpful when checking top or other memory monitor) Also adds net/http/pprof to export debug endpoints. From the trace included in #21870 $ DEBUG_MEMORY_USAGE=1 go tool trace trace.out 2018/02/21 16:04:49 Parsing trace... after parsing trace Alloc: 3385747848 Bytes Sys: 3661654648 Bytes HeapReleased: 0 Bytes HeapSys: 3488907264 Bytes HeapInUse: 3426377728 Bytes HeapAlloc: 3385747848 Bytes Enter to continue... 2018/02/21 16:05:09 Serializing trace... after generating trace Alloc: 4908929616 Bytes Sys: 5319063640 Bytes HeapReleased: 0 Bytes HeapSys: 5032411136 Bytes HeapInUse: 4982865920 Bytes HeapAlloc: 4908929616 Bytes Enter to continue... 2018/02/21 16:05:18 Splitting trace... after spliting trace Alloc: 4909026200 Bytes Sys: 5319063640 Bytes HeapReleased: 0 Bytes HeapSys: 5032411136 Bytes HeapInUse: 4983046144 Bytes HeapAlloc: 4909026200 Bytes Enter to continue... 2018/02/21 16:05:39 Opening browser. Trace viewer is listening on http://127.0.0.1:33661 after httpJsonTrace Alloc: 5288336048 Bytes Sys: 7790245896 Bytes HeapReleased: 0 Bytes HeapSys: 7381123072 Bytes HeapInUse: 5324120064 Bytes HeapAlloc: 5288336048 Bytes Enter to continue... Change-Id: I88bb3cb1af3cb62e4643a8cbafd5823672b2e464 Reviewed-on: https://go-review.googlesource.com/92355Reviewed-by: Peter Weinberger <pjw@google.com>
-
Robert Griesemer authored
The existing code was somewhat convoluted and made several assumptions about the encoding of position bases: 1) The position's base for a file contained a position whose base pointed to itself (which is true but an implementation detail of src.Pos). 2) Updating the position base for a line directive required finding the base of the most recent's base position. This change simply stores the file's position base and keeps using it directly for each line directive (instead of getting it from the most recently updated base). Change-Id: I4d80da513bededb636eab0ce53257fda73f0dbc0 Reviewed-on: https://go-review.googlesource.com/95736Reviewed-by: Matthew Dempsky <mdempsky@google.com>
-
OneOfOne authored
Fixes #23959 GitHub-Last-Rev: 08ce026f52f9fd65b49d99745dffed46a3951585 GitHub-Pull-Request: golang/go#24012 Change-Id: I7e71c41330346dbc4dad6ba813cabfa8a54e2f66 Reviewed-on: https://go-review.googlesource.com/95975 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Yury Smolsky authored
Fixes #23520 Change-Id: Ia834819f3260691a1a0181034ef4b4b945965688 Reviewed-on: https://go-review.googlesource.com/94761Reviewed-by: Andrew Gerrand <adg@golang.org>
-
Austin Clements authored
Now that we support the full non-contiguous virtual address space of amd64 hardware, some of the comments and constants related to this are out of date. This renames memLimitBits to heapAddrBits because 1<<memLimitBits is no longer the limit of the address space and rewrites the comment to focus first on hardware limits (which span OSes) and then discuss kernel limits. Second, this eliminates the memLimit constant because there's no longer a meaningful "highest possible heap pointer value" on amd64. Updates #23862. Change-Id: I44b32033d2deb6b69248fb8dda14fc0e65c47f11 Reviewed-on: https://go-review.googlesource.com/95498 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Austin Clements authored
On amd64, the virtual address space, when interpreted as signed values, is [-2^47, 2^47). Currently, we only support heap addresses in the "positive" half of this, [0, 2^47). This suffices for linux/amd64 and windows/amd64, but solaris/amd64 can map user addresses in the negative part of this range. Specifically, addresses 0xFFFF8000'00000000 to 0xFFFFFD80'00000000 are part of user space. This leads to "memory allocated by OS not in usable address space" panic, since we don't map heap arena index space for these addresses. Fix this by offsetting addresses when computing arena indexes so that arena entry 0 corresponds to address -2^47 on amd64. We already map enough arena space for 2^48 heap addresses on 64-bit (because arm64's virtual address space is [0, 2^48)), so we don't need to grow any structures to support this. A different approach would be to simply mask out the top 16 bits. However, there are two advantages to the offset approach: 1) invalid heap addresses continue to naturally map to invalid arena indexes so we don't need extra checks and 2) it perturbs the mapping of addresses to arena indexes more, which helps check that we don't accidentally compute incorrect arena indexes somewhere that happen to be right most of the time. Several comments and constant names are now somewhat misleading. We'll fix that in the next CL. This CL is the core change the arena indexing. Fixes #23862. Change-Id: Idb8e299fded04593a286b01a9582da6ddbac2f9a Reviewed-on: https://go-review.googlesource.com/95497 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Accessing the arena index is about to get slightly more complicated. Abstract this away into a set of functions for going back and forth between addresses and arena slice indexes. For #23862. Change-Id: I0b20e74ef47a07b78ed0cf0a6128afe6f6e40f4b Reviewed-on: https://go-review.googlesource.com/95496 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Austin Clements authored
Currently, bulkBarrierPreWrite uses inheap to decide whether the destination is in the heap or whether to check for stack or global data. However, this isn't the best question to ask. Instead, get the span directly and query its state. This lets us directly determine whether this might be a global, or is stack memory, or is heap memory. At this point, inheap is no longer used in the hot path, so drop it from the must-be-inlined list and substitute spanOf. This will help in a circuitous way with #23862, since fixing that is going to push inheap very slightly over the inline-able threshold on a few platforms. Change-Id: I5360fc1181183598502409f12979899e1e4d45f7 Reviewed-on: https://go-review.googlesource.com/95495 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rick Hudson <rlh@golang.org>
-
Hana Kim authored
The task-oriented trace view presents the execution trace organized based on goroutines. Often, which P a goroutine was running on is useful, so this CL includes the P ids in the goroutine execution slices. R=go1.11 Change-Id: I96539bf8215e5c1cd8cc997a90204f57347c48c8 Reviewed-on: https://go-review.googlesource.com/90221Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Hana Kim authored
Also append stack traces to task create/end slices. R=go1.11 Change-Id: I2adb342e92b36d30bee2860393618eb4064450cf Reviewed-on: https://go-review.googlesource.com/90220Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Hana Kim authored
The GC time for a task is defined by the sum of GC duration overlapping with the task's duration. Also, grey out non-overlapping slices in the task-oriented trace view. R=go1.11 Change-Id: I42def0eb520f5d9bd07edd265e558706f6fab552 Reviewed-on: https://go-review.googlesource.com/90219Reviewed-by: Heschi Kreinick <heschi@google.com>
-
Heschi Kreinick authored
Reuse even more memory, and keep track of it in a long-lived debugState object rather than piecemeal in the Cache. Change-Id: Ib6936b4e8594dc6dda1f59ece753c00fd1c136ba Reviewed-on: https://go-review.googlesource.com/92404Reviewed-by: David Chase <drchase@google.com>
-
Heschi Kreinick authored
Change the closures to methods on debugState, mostly just for aesthetic reasons. Change-Id: I5242807f7300efafc7efb4eb3bd305ac3ec8e826 Reviewed-on: https://go-review.googlesource.com/92403Reviewed-by: David Chase <drchase@google.com>
-
Heschi Kreinick authored
changedVars was functionally a set, but couldn't be iterated over efficiently. In functions with many variables, the wasted iteration was costly. Use a sparseSet instead. (*gc.Node).String() is very expensive: it calls Sprintf, which does reflection, etc, etc. Instead, just look at .Sym.Name, which is all we care about. Change-Id: Ib61cd7b5c796e1813b8859135e85da5bfe2ac686 Reviewed-on: https://go-review.googlesource.com/92402Reviewed-by: David Chase <drchase@google.com>
-
Heschi Kreinick authored
Replace the OnStack boolean in VarLoc with a flag bit in StackOffset. This doesn't get much memory savings since it's still 64-bit aligned, but does seem to help a bit anyway. Change liveSlot to fit into 16 bytes. Because nested structs still get padding, this required inlining it. Fortunately there's not much logic to copy. Change-Id: Ie19a409daa41aa310275c4517a021eecf8886441 Reviewed-on: https://go-review.googlesource.com/92401Reviewed-by: David Chase <drchase@google.com>
-
Alberto Donizetti authored
For now, limited to the most repetitive rules that are also short and simple, so that we can have a substantial conciseness win without compromising rules readability. Ran rulegen, no changes in the rewrite files. Change-Id: I8d8cc67d02faca4756cc02402b763f1645ee31de Reviewed-on: https://go-review.googlesource.com/95935Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alberto Donizetti authored
Fixes #24006 Change-Id: Ic1438b121fe705f9a6e3ed8340882e9dfd26ecf7 Reviewed-on: https://go-review.googlesource.com/95916Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com>
-
Alberto Donizetti authored
For now, limited to the most repetitive rules that are also short and simple, so that we can have a substantial conciseness win without compromising rules readability. Ran rulegen, no change in the actual compiler code (as expected). Change-Id: Ia74acc389cd8310eb7fe8f927171fa3d292d2a86 Reviewed-on: https://go-review.googlesource.com/95797Reviewed-by: Giovanni Bajo <rasky@develer.com>
-
Alberto Donizetti authored
For now, limited to the most repetitive rules that are also short and simple, so that we can have a substantial conciseness win without compromising rules readability. Ran rulegen, no change in the actual compiler code (as expected). Change-Id: Ib0bfbbc181fcec095fb78ac752addd1eee0c3575 Reviewed-on: https://go-review.googlesource.com/95796Reviewed-by: Giovanni Bajo <rasky@develer.com>
-
Giovanni Bajo authored
No changes in the generated file, as expected. Change-Id: I30e0404612cd150f1455378b8db1c18b1e12d34e Reviewed-on: https://go-review.googlesource.com/95616Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Daniel Martí authored
We did warn on them in some cases, but not others. In particular, if one used a slice composite literal with struct pointer elements, and omitted the type of an element's composite literal, it would not get any warning even if it should get one. The issue is that typ.Underlying() can be of type *types.Pointer. Skip those levels of indirection before checking for a *types.Struct underlying type. isLocalType also needed a bit of tweaking to ignore dereferences. Perhaps that can be rewritten now that we have type info, but let's leave it for another time. Fixes #23539. Change-Id: I727a497284df1325b70d47a756519f5db1add25d Reviewed-on: https://go-review.googlesource.com/89715 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Giovanni Bajo authored
Sometimes, multiple CLs being merged that create rules on the same opcodes can cause the generated file to differ compared to a new regeneration. This is caused by the fact that rulegen splits generated functions in chunks of 10 rules per function (to avoid creating functions that are too big). If two CLs add rules to the same function, they might cause a generated function to have more than 10 rules, even though each CL individually didn't pass this limit. Change-Id: Ib641396b7e9028f80ec8718746969d390a9fbba9 Reviewed-on: https://go-review.googlesource.com/95795 Run-TryBot: Giovanni Bajo <rasky@develer.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Mansour Rahimi authored
Calling UDPConn readers (Read, ReadFrom, ReadMsgUDP) to read part of datagram returns error (in Windows), mentioning there is more data available, and 0 as size of read data, even though part of data is already read. This fix makes UDPConn readers to return truncated payload size, even there is error due more data available to read. Fixes #14074 Updates #18056 Change-Id: Id7eec7f544dd759b2d970fa2561eef2937ec4662 Reviewed-on: https://go-review.googlesource.com/92475 Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
-
Alberto Donizetti authored
For now, limited to the most repetitive rules that are also short and simple, so that we can have a substantial conciseness win without compromising rules readability. Ran rulegen, no change in the actual compiler code (as expected). Change-Id: Ib1d2b9fbc787379105ec9baf10d2c1e2ff3c4c5c Reviewed-on: https://go-review.googlesource.com/95615Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ahmed W authored
GitHub-Last-Rev: ff68319f4c46271ddb927d176756962a3a2b4332 GitHub-Pull-Request: golang/go#23874 Change-Id: I7242c5cc35f04e23d807f5e91180c4ef510e7d1a Reviewed-on: https://go-review.googlesource.com/94840Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Austin Clements authored
We don't want to account the memory for mheap_.arenas because most of it is never touched, so currently we pass the address of a uint64 on the heap. However, at least on mips, it's possible for this uint64 to be unaligned, which causes the atomic add in mSysStatInc to crash. Fix this by instead passing a nil stat pointer. Fixes #23946. Change-Id: I091587df1b3066c330b6bb4d834e4596c407910f Reviewed-on: https://go-review.googlesource.com/95695 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
-
Andrew Bonventre authored
+ Move from Markdown checklist to text. The first PR comment is presented as text when creating it. + Add the note about Signed-Off-By: not being required. Change-Id: I0650891dcf11ed7dd367007148730ba2917784fe Reviewed-on: https://go-review.googlesource.com/95696Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ilya Tocar authored
Currently zip benchmarks spend 60% in the rleBuffer code, which is used only to test zip archive/zip itself: 17.48s 37.02% 37.02% 18.12s 38.37% archive/zip.(*rleBuffer).ReadAt 9.51s 20.14% 57.16% 10.43s 22.09% archive/zip.(*rleBuffer).Write 9.15s 19.38% 76.54% 10.85s 22.98% compress/flate.(*compressor).deflate This means that benchmarks currently test performance of test helper. Updating ReadAt/Write methods to be more performant makes benchmarks closer to real world. name old time/op new time/op delta CompressedZipGarbage-8 2.34ms ± 0% 2.34ms ± 1% ~ (p=0.684 n=10+10) Zip64Test-8 58.1ms ± 2% 10.7ms ± 1% -81.54% (p=0.000 n=10+10) Zip64TestSizes/4096-8 4.05µs ± 2% 3.65µs ± 5% -9.96% (p=0.000 n=9+10) Zip64TestSizes/1048576-8 238µs ± 0% 43µs ± 0% -82.06% (p=0.000 n=10+10) Zip64TestSizes/67108864-8 15.3ms ± 1% 2.6ms ± 0% -83.12% (p=0.000 n=10+9) name old alloc/op new alloc/op delta CompressedZipGarbage-8 17.9kB ±14% 16.0kB ±24% -10.48% (p=0.026 n=9+10) name old allocs/op new allocs/op delta CompressedZipGarbage-8 44.0 ± 0% 44.0 ± 0% ~ (all equal) Change-Id: Idfd920d0e4bed4aec2f5be84dc7e3919d9f1dd2d Reviewed-on: https://go-review.googlesource.com/83857Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Martin Möhrmann authored
reflect.unsafe_New is an often called function according to profiling in a large production environment. Since newobject is not inlined currently there is call overhead that can be avoided by calling mallocgc directly. name old time/op new time/op delta New 32.4ns ± 2% 29.8ns ± 1% -8.03% (p=0.000 n=19+20) Change-Id: I572e4be830ed8e5c0da555dc3a8864c8363112be Reviewed-on: https://go-review.googlesource.com/95015Reviewed-by: Austin Clements <austin@google.com>
-
- 20 Feb, 2018 2 commits
-
-
Ilya Tocar authored
Similar to https://golang.org/cl/54391, but for sha512 name old time/op new time/op delta Hash8Bytes-8 289ns ± 1% 253ns ± 2% -12.59% (p=0.000 n=10+10) Hash1K-8 1.85µs ± 1% 1.82µs ± 1% -1.77% (p=0.000 n=9+10) Hash8K-8 12.7µs ± 2% 12.5µs ± 1% ~ (p=0.075 n=10+10) name old speed new speed delta Hash8Bytes-8 27.6MB/s ± 1% 31.6MB/s ± 2% +14.43% (p=0.000 n=10+10) Hash1K-8 554MB/s ± 1% 564MB/s ± 1% +1.81% (p=0.000 n=9+10) Hash8K-8 647MB/s ± 2% 653MB/s ± 1% ~ (p=0.075 n=10+10) Change-Id: I437668c96ad55f8dbb62c89c8fc3f433453b5330 Reviewed-on: https://go-review.googlesource.com/82996 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <hi@filippo.io>
-
Ilya Tocar authored
Similar to https://golang.org/cl/54391, but for sha256 name old time/op new time/op delta Hash8Bytes-8 209ns ± 1% 191ns ± 1% -8.65% (p=0.000 n=10+9) Hash1K-8 2.49µs ± 1% 2.47µs ± 2% -0.74% (p=0.045 n=9+10) Hash8K-8 18.4µs ± 1% 18.2µs ± 0% -0.98% (p=0.009 n=10+10) name old speed new speed delta Hash8Bytes-8 38.1MB/s ± 1% 41.8MB/s ± 1% +9.47% (p=0.000 n=10+9) Hash1K-8 412MB/s ± 1% 415MB/s ± 2% ~ (p=0.051 n=9+10) Hash8K-8 445MB/s ± 1% 450MB/s ± 0% +0.98% (p=0.009 n=10+10) Change-Id: I50ca80fc28c279fbb758b7c849f67d8c66391eb6 Reviewed-on: https://go-review.googlesource.com/82995 Run-TryBot: Ilya Tocar <ilya.tocar@intel.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Filippo Valsorda <hi@filippo.io>
-