This project is mirrored from https://go.googlesource.com/go.
Pull mirroring updated .
- Sep 03, 2024
-
-
Martin Stiemerling authored
-
Martin Stiemerling authored
removed freebsd compile flag from syscall_bsd.go and copied code to syscall_freebsd.go, extended code in syscall_freebsd.go for netlink.
-
- Aug 29, 2024
-
-
Martin Stiemerling authored
-
Martin Stiemerling authored
-
- Aug 27, 2024
-
-
Martin Stiemerling authored
-
Martin Stiemerling authored
-
- Aug 24, 2024
-
-
Jes Cok authored
Change-Id: Iecbfe986da386b5c9b8c366904f659acc8f34cfc GitHub-Last-Rev: ed6c744bbd9ff61874e8dd92f4cef01851ed1f09 GitHub-Pull-Request: golang/go#69039 Reviewed-on: https://go-review.googlesource.com/c/go/+/608015 Reviewed-by:
Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by:
Cherry Mui <cherryyz@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com>
-
Nic Klaassen authored
The current implementation has a panic when the database is closed concurrently with a new connection attempt. connRequestSet.CloseAndRemoveAll sets connRequestSet.s to a nil slice. If this happens between calls to connRequestSet.Add and connRequestSet.Delete, there is a panic when trying to write to the nil slice. This is sequence is likely to occur in DB.conn, where the mutex is released between calls to db.connRequests.Add and db.connRequests.Delete This change updates connRequestSet.CloseAndRemoveAll to set the curIdx to -1 for all pending requests before setting its internal slice to nil. CloseAndRemoveAll already iterates the full slice to close all the request channels. It seems appropriate to set curIdx to -1 before deleting the slice for 3 reasons: 1. connRequestSet.deleteIndex also sets curIdx to -1 2. curIdx will not be relevant to anything after the slice is set to nil 3. connRequestSet.Delete already checks for negative indices Fixes #68949 Change-Id: I6b7ebc5a71b67322908271d13865fa12f2469b87 GitHub-Last-Rev: 7d2669155b24043dd9d276f915689511572f2e49 GitHub-Pull-Request: golang/go#68953 Reviewed-on: https://go-review.googlesource.com/c/go/+/607238 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Commit-Queue: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by:
Dmitri Shuralyov <dmitshur@google.com>
-
- Aug 23, 2024
-
-
Tim King authored
Writes the field for type parameter names for aliases when the bitstream is >= V2. This is a no-op at the moment as the writer is hardwired to V1. Updates #68778 Change-Id: I5887e3608239b9a6a47e3cc21cacb75b84e1d186 Reviewed-on: https://go-review.googlesource.com/c/go/+/607235 Reviewed-by:
David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by:
Robert Griesemer <gri@google.com> Reviewed-by:
Cuong Manh Le <cuong.manhle.vn@gmail.com>
-
Joel Sing authored
Change-Id: I006370053748edbec930c7279ee88a805009aa0d Reviewed-on: https://go-review.googlesource.com/c/go/+/606976 Reviewed-by:
Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by:
-
Paul E. Murphy authored
The tests added by CL 601778 highlighted missing buffer overlap checks in the ppc64 specific aes-gcm implementation. Fixes #69007 Change-Id: I80c3b5628c5079cfed2c3dace7298512c16a8f46 Reviewed-on: https://go-review.googlesource.com/c/go/+/607519 Reviewed-by:
-
Joel Sing authored
This provides an assembly implementation of addMulVVW for riscv64, processing up to four words per loop, resulting in a significant performance gain. On a StarFive VisionFive 2: │ addmulvvw.1 │ addmulvvw.2 │ │ sec/op │ sec/op vs base │ AddMulVVW/1-4 65.49n ± 0% 50.79n ± 0% -22.44% (p=0.000 n=10) AddMulVVW/2-4 82.81n ± 0% 66.83n ± 0% -19.29% (p=0.000 n=10) AddMulVVW/3-4 100.20n ± 0% 82.87n ± 0% -17.30% (p=0.000 n=10) AddMulVVW/4-4 117.50n ± 0% 84.20n ± 0% -28.34% (p=0.000 n=10) AddMulVVW/5-4 134.9n ± 0% 100.3n ± 0% -25.69% (p=0.000 n=10) AddMulVVW/10-4 221.7n ± 0% 164.4n ± 0% -25.85% (p=0.000 n=10) AddMulVVW/100-4 1.794µ ± 0% 1.250µ ± 0% -30.32% (p=0.000 n=10) AddMulVVW/1000-4 17.42µ ± 0% 12.08µ ± 0% -30.68% (p=0.000 n=10) AddMulVVW/10000-4 254.9µ ± 0% 214.8µ ± 0% -15.75% (p=0.000 n=10) AddMulVVW/100000-4 2.569m ± 0% 2.178m ± 0% -15.20% (p=0.000 n=10) geomean 1.443µ 1.107µ -23.29% │ addmulvvw.1 │ addmulvvw.2 │ │ B/s │ B/s vs base │ AddMulVVW/1-4 932.0Mi ± 0% 1201.6Mi ± 0% +28.93% (p=0.000 n=10) AddMulVVW/2-4 1.440Gi ± 0% 1.784Gi ± 0% +23.90% (p=0.000 n=10) AddMulVVW/3-4 1.785Gi ± 0% 2.158Gi ± 0% +20.87% (p=0.000 n=10) AddMulVVW/4-4 2.029Gi ± 0% 2.832Gi ± 0% +39.59% (p=0.000 n=10) AddMulVVW/5-4 2.209Gi ± 0% 2.973Gi ± 0% +34.55% (p=0.000 n=10) AddMulVVW/10-4 2.689Gi ± 0% 3.626Gi ± 0% +34.86% (p=0.000 n=10) AddMulVVW/100-4 3.323Gi ± 0% 4.770Gi ± 0% +43.54% (p=0.000 n=10) AddMulVVW/1000-4 3.421Gi ± 0% 4.936Gi ± 0% +44.27% (p=0.000 n=10) AddMulVVW/10000-4 2.338Gi ± 0% 2.776Gi ± 0% +18.69% (p=0.000 n=10) AddMulVVW/100000-4 2.320Gi ± 0% 2.736Gi ± 0% +17.93% (p=0.000 n=10) geomean 2.109Gi 2.749Gi +30.36% Change-Id: I6c7ee48233c53ff9b6a5a9002675886cd9bff5af Reviewed-on: https://go-review.googlesource.com/c/go/+/595400 Reviewed-by:Mark Ryan <markdryan@rivosinc.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
-
Joel Sing authored
This provides an assembly implementation of mulAddVWW for riscv64, processing up to four words per loop, resulting in a significant performance gain. On a StarFive VisionFive 2: │ muladdvww.1 │ muladdvww.2 │ │ sec/op │ sec/op vs base │ MulAddVWW/1-4 68.18n ± 0% 65.49n ± 0% -3.95% (p=0.000 n=10) MulAddVWW/2-4 82.81n ± 0% 78.85n ± 0% -4.78% (p=0.000 n=10) MulAddVWW/3-4 97.49n ± 0% 72.18n ± 0% -25.96% (p=0.000 n=10) MulAddVWW/4-4 112.20n ± 0% 85.54n ± 0% -23.76% (p=0.000 n=10) MulAddVWW/5-4 126.90n ± 0% 98.90n ± 0% -22.06% (p=0.000 n=10) MulAddVWW/10-4 200.3n ± 0% 144.3n ± 0% -27.96% (p=0.000 n=10) MulAddVWW/100-4 1532.0n ± 0% 860.0n ± 0% -43.86% (p=0.000 n=10) MulAddVWW/1000-4 14.757µ ± 0% 8.076µ ± 0% -45.27% (p=0.000 n=10) MulAddVWW/10000-4 204.0µ ± 0% 137.1µ ± 0% -32.77% (p=0.000 n=10) MulAddVWW/100000-4 2.066m ± 0% 1.382m ± 0% -33.12% (p=0.000 n=10) geomean 1.311µ 950.0n -27.51% │ muladdvww.1 │ muladdvww.2 │ │ B/s │ B/s vs base │ MulAddVWW/1-4 895.1Mi ± 0% 932.0Mi ± 0% +4.11% (p=0.000 n=10) MulAddVWW/2-4 1.440Gi ± 0% 1.512Gi ± 0% +5.02% (p=0.000 n=10) MulAddVWW/3-4 1.834Gi ± 0% 2.477Gi ± 0% +35.07% (p=0.000 n=10) MulAddVWW/4-4 2.125Gi ± 0% 2.787Gi ± 0% +31.15% (p=0.000 n=10) MulAddVWW/5-4 2.349Gi ± 0% 3.013Gi ± 0% +28.28% (p=0.000 n=10) MulAddVWW/10-4 2.975Gi ± 0% 4.130Gi ± 0% +38.79% (p=0.000 n=10) MulAddVWW/100-4 3.891Gi ± 0% 6.930Gi ± 0% +78.11% (p=0.000 n=10) MulAddVWW/1000-4 4.039Gi ± 0% 7.380Gi ± 0% +82.72% (p=0.000 n=10) MulAddVWW/10000-4 2.922Gi ± 0% 4.346Gi ± 0% +48.74% (p=0.000 n=10) MulAddVWW/100000-4 2.884Gi ± 0% 4.313Gi ± 0% +49.52% (p=0.000 n=10) geomean 2.321Gi 3.202Gi +37.95% Change-Id: If08191607913ce5c7641f34bae8fa5c9dfb44777 Reviewed-on: https://go-review.googlesource.com/c/go/+/595399 Reviewed-by: -
Joel Sing authored
Provide an optimised assembly implementation of sha256 for riscv64. This results in considerable performance gains. On a StarFive VisionFive 2: │ sha256.1 │ sha256.2 │ │ sec/op │ sec/op vs base │ Hash8Bytes/New-4 7.820µ ± 0% 5.193µ ± 0% -33.59% (p=0.000 n=10) Hash8Bytes/Sum224-4 7.918µ ± 0% 5.294µ ± 0% -33.15% (p=0.000 n=10) Hash8Bytes/Sum256-4 7.950µ ± 0% 5.320µ ± 0% -33.08% (p=0.000 n=10) Hash1K/New-4 108.03µ ± 0% 66.12µ ± 0% -38.79% (p=0.000 n=10) Hash1K/Sum224-4 108.12µ ± 0% 66.22µ ± 0% -38.76% (p=0.000 n=10) Hash1K/Sum256-4 108.15µ ± 0% 66.24µ ± 0% -38.75% (p=0.000 n=10) Hash8K/New-4 808.5µ ± 0% 493.0µ ± 0% -39.02% (p=0.000 n=10) Hash8K/Sum224-4 808.6µ ± 0% 493.1µ ± 0% -39.02% (p=0.000 n=10) Hash8K/Sum256-4 808.6µ ± 0% 493.1µ ± 0% -39.02% (p=0.000 n=10) geomean 88.37µ 55.61µ -37.08% │ sha256.1 │ sha256.2 │ │ B/s │ B/s vs base │ Hash8Bytes/New-4 996.1Ki ± 0% 1503.9Ki ± 0% +50.98% (p=0.000 n=10) Hash8Bytes/Sum224-4 986.3Ki ± 0% 1474.6Ki ± 0% +49.50% (p=0.000 n=10) Hash8Bytes/Sum256-4 986.3Ki ± 0% 1464.8Ki ± 0% +48.51% (p=0.000 n=10) Hash1K/New-4 9.041Mi ± 0% 14.772Mi ± 0% +63.40% (p=0.000 n=10) Hash1K/Sum224-4 9.031Mi ± 0% 14.744Mi ± 0% +63.25% (p=0.000 n=10) Hash1K/Sum256-4 9.031Mi ± 0% 14.744Mi ± 0% +63.25% (p=0.000 n=10) Hash8K/New-4 9.661Mi ± 0% 15.850Mi ± 0% +64.07% (p=0.000 n=10) Hash8K/Sum224-4 9.661Mi ± 0% 15.841Mi ± 0% +63.97% (p=0.000 n=10) Hash8K/Sum256-4 9.661Mi ± 0% 15.841Mi ± 0% +63.97% (p=0.000 n=10) geomean 4.386Mi 6.966Mi +58.85% Change-Id: Ieead7b7c02291d70ddc472a7a8cf3c044c1da4b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/519695 Reviewed-by: -
Kir Kolyshkin authored
1. Replace "rooted path name" with a more accurate "absolute path name". Using "absolute" seems to be preferred terminology on Unix. On Windows, there are multiple roots in Windows, thus "a rooted path name" can be one relative to a drive letter or a server name. Note that Windows' GetCurrentDirectory documentation [1] also says "the absolute path to the current directory". 2. Add a note about using $PWD on Unix. [1]: https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getcurrentdirectory Change-Id: Ic310f0f8776ff059544789306ae5cfa1fa267b12 Reviewed-on: https://go-review.googlesource.com/c/go/+/607615 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by:
-
Xiaolin Zhao authored
Go asm syntax: BSTRPICK{W/V} $msb, RJ, $lsb, RD BSTRINS{W/V} $msb, RJ, $lsb, RD Equivalent platform assembler syntax: bstrpick.{w/d} rd, rj, $msb, $lsb bstrins.{w/d} rd, rj, $msb, $lsb Ref: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html Change-Id: I8b89b766ed22a96da7d8d5b2b2873382a49208de Reviewed-on: https://go-review.googlesource.com/c/go/+/604735 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by:abner chenc <chenguoqi@loongson.cn> Reviewed-by:
-
- Aug 22, 2024
-
-
Kir Kolyshkin authored
CL 574695 added caching the os.Chdir argument for Windows, and used the cached value to assess the length of the current working directory in addExtendedPrefix (used by fixLongPath). It did not take into account that Chdir can accept relative paths, and thus the pathLength calculation in addExtendedPrefix can be wrong. Let's only cache the os.Chdir argument if it's absolute, and clean the cache otherwise, thus improving the correctness of fixLongPath. For #41734 For #21782 For #36375 Change-Id: Ie24a5ed763a7aacc310666d2e4cbb8e298768670 Reviewed-on: https://go-review.googlesource.com/c/go/+/607437 Reviewed-by:
Alex Brainman <alex.brainman@gmail.com> Reviewed-by:
Damien Neil <dneil@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by:
Quim Muntal <quimmuntal@gmail.com> Reviewed-by:
-
Michael Matloob authored
This change adds documentation to "go help telemetry" and "go help environment" for the unsettable GOTELEMETRY and GOTELEMETRYDIR go env variables. For #68928 Change-Id: I8c139bd8585ffb0c45b9dd722ef6e7a9a33df192 Reviewed-on: https://go-review.googlesource.com/c/go/+/607855 Reviewed-by:
Robert Findley <rfindley@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
-
Michael Matloob authored
The commands to build the bootstrap toolchains and go commands are run from modules created by two bootstrap go.mod files: one is used when building toolchain1 and go_bootstrap, and the other is used for toolchain2 and toolchain3, and the final build. Currently the first has a go directive specifying go 1.20, and the second one does not have a go directive at all. This affects the default GODEBUG setting when building the final toolchain: the default GODEBUG value is based on the go version of the go.mod file, and when the go.mod file does not have a version it defaults to go1.16. We should set the go directive on the bootstrap used for the second half of the builds to use the current go verison from the std's go.mod file (which is the same as the version on cmd's go.mod file). The go.mod file used for the initial bootstrap should have a go directive with the minimum version of the toolchain required for bootstrapping. That version is the current version - 2 rounded down to an even number. For #64751 Fixes #68797 Change-Id: Ibdddf4bc36dc963291979d603c4f3fc55264f65b Reviewed-on: https://go-review.googlesource.com/c/go/+/604799 Reviewed-by:
Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by:
-
qmuntal authored
nanotime1 is broken on windows/arm since CL 526358, which unintentionally removed a necessary instruction. It hasn't been noticed till now because the there is no windows/arm builder. This CL restores the instruction. Fixes #68996. Change-Id: I52ef6891a3bd8e608b8538f456d181e08f93efaa Reviewed-on: https://go-review.googlesource.com/c/go/+/607776 Reviewed-by:
-
Xiaolin Zhao authored
goos: linux goarch: loong64 pkg: crypto/sha1 cpu: Loongson-3A6000 @ 2500.00MHz │ bench.old │ bench.new │ │ sec/op │ sec/op vs base │ Hash8Bytes/New 489.8n ± 0% 280.6n ± 0% -42.71% (p=0.000 n=20) Hash8Bytes/Sum 496.6n ± 0% 288.9n ± 0% -41.82% (p=0.000 n=20) Hash320Bytes/New 2251.0n ± 0% 992.0n ± 0% -55.93% (p=0.000 n=20) Hash320Bytes/Sum 2258.0n ± 0% 998.0n ± 0% -55.80% (p=0.000 n=20) Hash1K/New 6.113µ ± 0% 2.583µ ± 0% -57.75% (p=0.000 n=20) Hash1K/Sum 6.117µ ± 0% 2.588µ ± 0% -57.69% (p=0.000 n=20) Hash8K/New 45.42µ ± 0% 18.79µ ± 0% -58.63% (p=0.000 n=20) Hash8K/Sum 45.43µ ± 0% 18.80µ ± 0% -58.62% (p=0.000 n=20) geomean 4.192µ 1.926µ -54.05% │ bench.old │ bench.new │ │ B/s │ B/s vs base │ Hash8Bytes/New 15.57Mi ± 0% 27.19Mi ± 0% +74.59% (p=0.000 n=20) Hash8Bytes/Sum 15.36Mi ± 0% 26.41Mi ± 0% +71.88% (p=0.000 n=20) Hash320Bytes/New 135.6Mi ± 0% 307.6Mi ± 0% +126.90% (p=0.000 n=20) Hash320Bytes/Sum 135.2Mi ± 0% 305.8Mi ± 0% +126.22% (p=0.000 n=20) Hash1K/New 159.8Mi ± 0% 378.1Mi ± 0% +136.69% (p=0.000 n=20) Hash1K/Sum 159.7Mi ± 0% 377.4Mi ± 0% +136.38% (p=0.000 n=20) Hash8K/New 172.0Mi ± 0% 415.8Mi ± 0% +141.75% (p=0.000 n=20) Hash8K/Sum 172.0Mi ± 0% 415.6Mi ± 0% +141.65% (p=0.000 n=20) geomean 87.09Mi 189.5Mi +117.64% goos: linux goarch: loong64 pkg: crypto/sha1 cpu: Loongson-3A5000 @ 2500.00MHz │ bench.old │ bench.new │ │ sec/op │ sec/op vs base │ Hash8Bytes/New 565.9n ± 0% 374.5n ± 1% -33.82% (p=0.000 n=20) Hash8Bytes/Sum 571.3n ± 0% 366.7n ± 1% -35.81% (p=0.000 n=20) Hash320Bytes/New 2.662µ ± 0% 1.201µ ± 0% -54.88% (p=0.000 n=20) Hash320Bytes/Sum 2.662µ ± 0% 1.194µ ± 0% -55.15% (p=0.000 n=20) Hash1K/New 7.171µ ± 0% 3.084µ ± 0% -56.99% (p=0.000 n=20) Hash1K/Sum 7.171µ ± 0% 3.076µ ± 0% -57.11% (p=0.000 n=20) Hash8K/New 53.10µ ± 0% 22.24µ ± 0% -58.12% (p=0.000 n=20) Hash8K/Sum 53.09µ ± 0% 22.23µ ± 0% -58.12% (p=0.000 n=20) geomean 4.900µ 2.348µ -52.08% │ bench.old │ bench.new │ │ B/s │ B/s vs base │ Hash8Bytes/New 13.48Mi ± 0% 20.38Mi ± 1% +51.10% (p=0.000 n=20) Hash8Bytes/Sum 13.35Mi ± 0% 20.80Mi ± 1% +55.82% (p=0.000 n=20) Hash320Bytes/New 114.6Mi ± 0% 254.0Mi ± 1% +121.61% (p=0.000 n=20) Hash320Bytes/Sum 114.6Mi ± 0% 255.6Mi ± 0% +123.00% (p=0.000 n=20) Hash1K/New 136.2Mi ± 0% 316.7Mi ± 0% +132.54% (p=0.000 n=20) Hash1K/Sum 136.2Mi ± 0% 317.5Mi ± 0% +133.19% (p=0.000 n=20) Hash8K/New 147.1Mi ± 0% 351.3Mi ± 0% +138.79% (p=0.000 n=20) Hash8K/Sum 147.2Mi ± 0% 351.4Mi ± 0% +138.78% (p=0.000 n=20) geomean 74.51Mi 155.5Mi +108.69% Change-Id: I716babd19c18dc2c3314d972ced9d83de2d93cb2 Reviewed-on: https://go-review.googlesource.com/c/go/+/589775 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by:Qiqi Huang <huangqiqi@loongson.cn> Reviewed-by:
-
Kir Kolyshkin authored
With this, ReadDir will fail a tad earlier (on open rather than on readdir syscall). This should be the only effect of this change. Change-Id: Icf2870f47ea6c19aad29670e78ba9bfcc13c0ac3 Reviewed-on: https://go-review.googlesource.com/c/go/+/588915 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by:
Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by:
-
Joel Sing authored
This provides an assembly implementation of subVW for riscv64, processing up to four words per loop, resulting in a significant performance gain. On a StarFive VisionFive 2: │ subvw.1 │ subvw.2 │ │ sec/op │ sec/op vs base │ SubVW/1-4 57.43n ± 0% 41.45n ± 0% -27.82% (p=0.000 n=10) SubVW/2-4 69.31n ± 0% 48.15n ± 0% -30.53% (p=0.000 n=10) SubVW/3-4 76.12n ± 0% 54.87n ± 0% -27.92% (p=0.000 n=10) SubVW/4-4 85.47n ± 0% 56.14n ± 0% -34.32% (p=0.000 n=10) SubVW/5-4 96.15n ± 0% 62.83n ± 0% -34.65% (p=0.000 n=10) SubVW/10-4 149.60n ± 0% 89.55n ± 0% -40.14% (p=0.000 n=10) SubVW/100-4 1115.0n ± 0% 549.3n ± 0% -50.74% (p=0.000 n=10) SubVW/1000-4 10.732µ ± 0% 5.071µ ± 0% -52.75% (p=0.000 n=10) SubVW/10000-4 153.0µ ± 0% 103.7µ ± 0% -32.21% (p=0.000 n=10) SubVW/100000-4 1.542m ± 0% 1.046m ± 0% -32.13% (p=0.000 n=10) SubVWext/1-4 57.42n ± 0% 41.45n ± 0% -27.81% (p=0.000 n=10) SubVWext/2-4 69.33n ± 0% 48.15n ± 0% -30.55% (p=0.000 n=10) SubVWext/3-4 76.12n ± 0% 54.93n ± 0% -27.84% (p=0.000 n=10) SubVWext/4-4 85.47n ± 0% 56.14n ± 0% -34.32% (p=0.000 n=10) SubVWext/5-4 96.15n ± 0% 62.83n ± 0% -34.65% (p=0.000 n=10) SubVWext/10-4 149.60n ± 0% 89.56n ± 0% -40.14% (p=0.000 n=10) SubVWext/100-4 1115.0n ± 0% 549.3n ± 0% -50.74% (p=0.000 n=10) SubVWext/1000-4 10.732µ ± 0% 5.061µ ± 0% -52.84% (p=0.000 n=10) SubVWext/10000-4 152.5µ ± 0% 103.7µ ± 0% -32.02% (p=0.000 n=10) SubVWext/100000-4 1.533m ± 0% 1.046m ± 0% -31.75% (p=0.000 n=10) geomean 1.005µ 633.7n -36.92% │ subvw.1 │ subvw.2 │ │ B/s │ B/s vs base │ SubVW/1-4 132.9Mi ± 0% 184.1Mi ± 0% +38.54% (p=0.000 n=10) SubVW/2-4 220.1Mi ± 0% 316.9Mi ± 0% +43.95% (p=0.000 n=10) SubVW/3-4 300.7Mi ± 0% 417.1Mi ± 0% +38.72% (p=0.000 n=10) SubVW/4-4 357.1Mi ± 0% 543.6Mi ± 0% +52.24% (p=0.000 n=10) SubVW/5-4 396.7Mi ± 0% 607.2Mi ± 0% +53.03% (p=0.000 n=10) SubVW/10-4 510.1Mi ± 0% 851.9Mi ± 0% +67.01% (p=0.000 n=10) SubVW/100-4 684.2Mi ± 0% 1388.9Mi ± 0% +102.99% (p=0.000 n=10) SubVW/1000-4 710.9Mi ± 0% 1504.5Mi ± 0% +111.63% (p=0.000 n=10) SubVW/10000-4 498.7Mi ± 0% 735.7Mi ± 0% +47.52% (p=0.000 n=10) SubVW/100000-4 494.8Mi ± 0% 729.1Mi ± 0% +47.34% (p=0.000 n=10) SubVWext/1-4 132.9Mi ± 0% 184.1Mi ± 0% +38.53% (p=0.000 n=10) SubVWext/2-4 220.1Mi ± 0% 316.9Mi ± 0% +44.00% (p=0.000 n=10) SubVWext/3-4 300.7Mi ± 0% 416.7Mi ± 0% +38.57% (p=0.000 n=10) SubVWext/4-4 357.1Mi ± 0% 543.6Mi ± 0% +52.24% (p=0.000 n=10) SubVWext/5-4 396.7Mi ± 0% 607.2Mi ± 0% +53.04% (p=0.000 n=10) SubVWext/10-4 510.1Mi ± 0% 851.9Mi ± 0% +67.01% (p=0.000 n=10) SubVWext/100-4 684.2Mi ± 0% 1388.9Mi ± 0% +102.99% (p=0.000 n=10) SubVWext/1000-4 710.9Mi ± 0% 1507.6Mi ± 0% +112.07% (p=0.000 n=10) SubVWext/10000-4 500.1Mi ± 0% 735.7Mi ± 0% +47.10% (p=0.000 n=10) SubVWext/100000-4 497.8Mi ± 0% 729.4Mi ± 0% +46.52% (p=0.000 n=10) geomean 387.6Mi 614.5Mi +58.51% Change-Id: I9d7fac719e977710ad9db9121fa298db6df605de Reviewed-on: https://go-review.googlesource.com/c/go/+/595398 Reviewed-by: -
Joel Sing authored
This provides an assembly implementation of addVW for riscv64, processing up to four words per loop, resulting in a significant performance gain. On a StarFive VisionFive 2: │ addvw.1 │ addvw.2 │ │ sec/op │ sec/op vs base │ AddVW/1-4 57.43n ± 0% 41.45n ± 0% -27.83% (p=0.000 n=10) AddVW/2-4 69.31n ± 0% 48.15n ± 0% -30.53% (p=0.000 n=10) AddVW/3-4 76.12n ± 0% 54.97n ± 0% -27.79% (p=0.000 n=10) AddVW/4-4 85.47n ± 0% 56.14n ± 0% -34.32% (p=0.000 n=10) AddVW/5-4 96.16n ± 0% 62.82n ± 0% -34.67% (p=0.000 n=10) AddVW/10-4 149.60n ± 0% 89.55n ± 0% -40.14% (p=0.000 n=10) AddVW/100-4 1115.0n ± 0% 549.3n ± 0% -50.74% (p=0.000 n=10) AddVW/1000-4 10.732µ ± 0% 5.060µ ± 0% -52.85% (p=0.000 n=10) AddVW/10000-4 151.7µ ± 0% 103.7µ ± 0% -31.63% (p=0.000 n=10) AddVW/100000-4 1.523m ± 0% 1.050m ± 0% -31.03% (p=0.000 n=10) AddVWext/1-4 57.42n ± 0% 41.45n ± 0% -27.81% (p=0.000 n=10) AddVWext/2-4 69.32n ± 0% 48.15n ± 0% -30.54% (p=0.000 n=10) AddVWext/3-4 76.12n ± 0% 54.87n ± 0% -27.92% (p=0.000 n=10) AddVWext/4-4 85.47n ± 0% 56.14n ± 0% -34.32% (p=0.000 n=10) AddVWext/5-4 96.15n ± 0% 62.82n ± 0% -34.66% (p=0.000 n=10) AddVWext/10-4 149.60n ± 0% 89.55n ± 0% -40.14% (p=0.000 n=10) AddVWext/100-4 1115.0n ± 0% 549.3n ± 0% -50.74% (p=0.000 n=10) AddVWext/1000-4 10.732µ ± 0% 5.060µ ± 0% -52.85% (p=0.000 n=10) AddVWext/10000-4 150.5µ ± 0% 103.7µ ± 0% -31.10% (p=0.000 n=10) AddVWext/100000-4 1.530m ± 0% 1.049m ± 0% -31.41% (p=0.000 n=10) geomean 1.003µ 633.9n -36.79% │ addvw.1 │ addvw.2 │ │ B/s │ B/s vs base │ AddVW/1-4 132.8Mi ± 0% 184.1Mi ± 0% +38.55% (p=0.000 n=10) AddVW/2-4 220.1Mi ± 0% 316.9Mi ± 0% +43.96% (p=0.000 n=10) AddVW/3-4 300.7Mi ± 0% 416.4Mi ± 0% +38.48% (p=0.000 n=10) AddVW/4-4 357.1Mi ± 0% 543.6Mi ± 0% +52.25% (p=0.000 n=10) AddVW/5-4 396.7Mi ± 0% 607.2Mi ± 0% +53.06% (p=0.000 n=10) AddVW/10-4 510.1Mi ± 0% 852.0Mi ± 0% +67.02% (p=0.000 n=10) AddVW/100-4 684.1Mi ± 0% 1389.0Mi ± 0% +103.03% (p=0.000 n=10) AddVW/1000-4 710.9Mi ± 0% 1507.8Mi ± 0% +112.08% (p=0.000 n=10) AddVW/10000-4 503.1Mi ± 0% 735.8Mi ± 0% +46.26% (p=0.000 n=10) AddVW/100000-4 501.0Mi ± 0% 726.5Mi ± 0% +45.00% (p=0.000 n=10) AddVWext/1-4 132.9Mi ± 0% 184.1Mi ± 0% +38.55% (p=0.000 n=10) AddVWext/2-4 220.1Mi ± 0% 316.9Mi ± 0% +43.98% (p=0.000 n=10) AddVWext/3-4 300.7Mi ± 0% 417.1Mi ± 0% +38.73% (p=0.000 n=10) AddVWext/4-4 357.1Mi ± 0% 543.6Mi ± 0% +52.25% (p=0.000 n=10) AddVWext/5-4 396.7Mi ± 0% 607.2Mi ± 0% +53.05% (p=0.000 n=10) AddVWext/10-4 510.1Mi ± 0% 852.0Mi ± 0% +67.02% (p=0.000 n=10) AddVWext/100-4 684.2Mi ± 0% 1389.0Mi ± 0% +103.02% (p=0.000 n=10) AddVWext/1000-4 710.9Mi ± 0% 1507.7Mi ± 0% +112.08% (p=0.000 n=10) AddVWext/10000-4 506.9Mi ± 0% 735.8Mi ± 0% +45.15% (p=0.000 n=10) AddVWext/100000-4 498.6Mi ± 0% 727.0Mi ± 0% +45.79% (p=0.000 n=10) geomean 388.3Mi 614.3Mi +58.19% Change-Id: Ib14a4b8c1d81e710753bbf6dd5546bbca44fe3f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/595397 Reviewed-by: -
Joel Sing authored
Add basic test coverage for the intrinisic table - this at least allows us to tell if intrinsics are added or removed unexpectedly. Code generation changes resulting from intrinsics is not covered and is left for test/codegen and others. Change-Id: I3d538708b90cd04d3f449945e0fd9388097d683e Reviewed-on: https://go-review.googlesource.com/c/go/+/605475 Reviewed-by:
-
Xiaolin Zhao authored
goos: linux goarch: loong64 pkg: crypto/md5 cpu: Loongson-3A6000 @ 2500.00MHz │ bench.old │ bench.new │ │ sec/op │ sec/op vs base │ Hash8Bytes 276.6n ± 0% 219.7n ± 0% -20.57% (p=0.000 n=20) Hash64 445.8n ± 0% 339.9n ± 0% -23.76% (p=0.000 n=20) Hash128 632.0n ± 0% 468.1n ± 0% -25.93% (p=0.000 n=20) Hash256 1005.0n ± 0% 723.8n ± 0% -27.98% (p=0.000 n=20) Hash512 1.749µ ± 0% 1.238µ ± 0% -29.22% (p=0.000 n=20) Hash1K 3.238µ ± 0% 2.265µ ± 0% -30.05% (p=0.000 n=20) Hash8K 24.09µ ± 0% 16.66µ ± 0% -30.83% (p=0.000 n=20) Hash1M 3.049m ± 0% 2.105m ± 0% -30.97% (p=0.000 n=20) Hash8M 24.39m ± 0% 16.84m ± 0% -30.97% (p=0.000 n=20) Hash8BytesUnaligned 284.1n ± 0% 227.2n ± 0% -20.03% (p=0.000 n=20) Hash1KUnaligned 3.238µ ± 0% 2.265µ ± 0% -30.05% (p=0.000 n=20) Hash8KUnaligned 24.09µ ± 0% 16.66µ ± 0% -30.82% (p=0.000 n=20) geomean 7.142µ 5.164µ -27.70% │ bench.old │ bench.new │ │ B/s │ B/s vs base │ Hash8Bytes 27.58Mi ± 0% 34.73Mi ± 0% +25.93% (p=0.000 n=20) Hash64 136.9Mi ± 0% 179.6Mi ± 0% +31.15% (p=0.000 n=20) Hash128 193.1Mi ± 0% 260.8Mi ± 0% +35.03% (p=0.000 n=20) Hash256 243.0Mi ± 0% 337.3Mi ± 0% +38.82% (p=0.000 n=20) Hash512 279.1Mi ± 0% 394.3Mi ± 0% +41.25% (p=0.000 n=20) Hash1K 301.6Mi ± 0% 431.1Mi ± 0% +42.94% (p=0.000 n=20) Hash8K 324.3Mi ± 0% 468.9Mi ± 0% +44.56% (p=0.000 n=20) Hash1M 327.9Mi ± 0% 475.0Mi ± 0% +44.86% (p=0.000 n=20) Hash8M 328.0Mi ± 0% 475.1Mi ± 0% +44.86% (p=0.000 n=20) Hash8BytesUnaligned 26.86Mi ± 0% 33.58Mi ± 0% +25.04% (p=0.000 n=20) Hash1KUnaligned 301.6Mi ± 0% 431.1Mi ± 0% +42.95% (p=0.000 n=20) Hash8KUnaligned 324.3Mi ± 0% 468.9Mi ± 0% +44.56% (p=0.000 n=20) geomean 182.5Mi 252.4Mi +38.31% goos: linux goarch: loong64 pkg: crypto/md5 cpu: Loongson-3A5000 @ 2500.00MHz │ bench.old │ bench.new │ │ sec/op │ sec/op vs base │ Hash8Bytes 346.0n ± 0% 289.1n ± 0% -16.45% (p=0.000 n=20) Hash64 521.2n ± 0% 409.3n ± 0% -21.47% (p=0.000 n=20) Hash128 707.1n ± 0% 537.8n ± 0% -23.94% (p=0.000 n=20) Hash256 1080.0n ± 0% 795.8n ± 0% -26.31% (p=0.000 n=20) Hash512 1.826µ ± 0% 1.311µ ± 0% -28.20% (p=0.000 n=20) Hash1K 3.315µ ± 0% 2.342µ ± 0% -29.35% (p=0.000 n=20) Hash8K 24.19µ ± 0% 16.78µ ± 0% -30.65% (p=0.000 n=20) Hash1M 3.052m ± 0% 2.110m ± 0% -30.86% (p=0.000 n=20) Hash8M 24.41m ± 0% 16.88m ± 0% -30.85% (p=0.000 n=20) Hash8BytesUnaligned 345.9n ± 0% 289.0n ± 0% -16.45% (p=0.000 n=20) Hash1KUnaligned 3.316µ ± 0% 2.342µ ± 0% -29.37% (p=0.000 n=20) Hash8KUnaligned 24.19µ ± 0% 16.78µ ± 0% -30.66% (p=0.000 n=20) geomean 7.673µ 5.648µ -26.39% │ bench.old │ bench.new │ │ B/s │ B/s vs base │ Hash8Bytes 22.05Mi ± 0% 26.39Mi ± 0% +19.68% (p=0.000 n=20) Hash64 117.1Mi ± 0% 149.1Mi ± 0% +27.32% (p=0.000 n=20) Hash128 172.6Mi ± 0% 227.0Mi ± 0% +31.49% (p=0.000 n=20) Hash256 226.0Mi ± 0% 306.8Mi ± 0% +35.77% (p=0.000 n=20) Hash512 267.4Mi ± 0% 372.5Mi ± 0% +39.26% (p=0.000 n=20) Hash1K 294.6Mi ± 0% 417.0Mi ± 0% +41.53% (p=0.000 n=20) Hash8K 322.9Mi ± 0% 465.7Mi ± 0% +44.20% (p=0.000 n=20) Hash1M 327.7Mi ± 0% 474.0Mi ± 0% +44.64% (p=0.000 n=20) Hash8M 327.8Mi ± 0% 474.1Mi ± 0% +44.62% (p=0.000 n=20) Hash8BytesUnaligned 22.06Mi ± 0% 26.40Mi ± 0% +19.67% (p=0.000 n=20) Hash1KUnaligned 294.5Mi ± 0% 417.0Mi ± 0% +41.60% (p=0.000 n=20) Hash8KUnaligned 322.9Mi ± 0% 465.7Mi ± 0% +44.21% (p=0.000 n=20) geomean 169.9Mi 230.8Mi +35.85% Change-Id: Iffddd60e3fc0b3bb265289f836a2d875f0805f64 Reviewed-on: https://go-review.googlesource.com/c/go/+/589540 Reviewed-by:
-
- Aug 21, 2024
-
-
Kir Kolyshkin authored
When looking for \0, use clen which may be optimized. Also, return EINVAL when returned string is empty. This makes it similar to how it is implemented in *bsd and solaris. Change-Id: I3e37ed25f47110eafd12c80291f7746de9db7b23 Reviewed-on: https://go-review.googlesource.com/c/go/+/606902 TryBot-Bypass: Ian Lance Taylor <iant@golang.org> Reviewed-by:
-
Tobias Klauser authored
Now that Go 1.22.6 is the minimum bootstrap toolchain (cf. CL 606156), the fallback implementation for Go versions <1.21 can be dropped. For #61180 For #64751 Change-Id: Idfeca0a6e9f490e1ab0f308ead372612402923ea Reviewed-on: https://go-review.googlesource.com/c/go/+/607315 Reviewed-by:
-
Vladimir Varankin authored
Following up to CL 603959, update internals of testing package to reduce the confusion around "context". The changes rename testContext/benchContext/fuzzContext to testState/benchState/fuzzState. Change-Id: Ib8855dab456d41ab343488fcf5fefff2431f7b72 Reviewed-on: https://go-review.googlesource.com/c/go/+/607555 Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by:
Alan Donovan <adonovan@google.com> Reviewed-by:
-
Manuel Sabin authored
This CL creates tests for the cipher.AEAD interface in the new cryptotest package. This set of tests is called from the tests of implementations of the AEAD interface, such as the GCM blockmode. Updates #25309 Change-Id: I7612fa6fb6c1505bdf1a2cd71180dd43dc50bf4a Reviewed-on: https://go-review.googlesource.com/c/go/+/601778 Reviewed-by:
Filippo Valsorda <filippo@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by:
Russell Webb <russell.webb@protonmail.com> Reviewed-by:
-
Srinivas Pokala authored
This CL provides vendor support for s390x disassembler gnu syntax. go get golang.org/x/arch@master go mod tidy go mod vendor For #15255 Change-Id: Ia75fa515e7ea7d56913a28147c65650a7ab3062c Reviewed-on: https://go-review.googlesource.com/c/go/+/581015 Reviewed-by:
Vishwanatha HD <vishwanatha.hd@ibm.com> Run-TryBot: Cherry Mui <cherryyz@google.com> Auto-Submit: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by:
Bill O'Farrell <billotosyr@gmail.com>
-
qmuntal authored
Update #21867. Update #68312. Update #68647. Change-Id: Ic41d6747c5a54ba28c1292258aa4d318ccb9fe40 Reviewed-on: https://go-review.googlesource.com/c/go/+/604395 Reviewed-by:
-
qmuntal authored
[This is a roll-forward of CL 597255, which had to be rolled back because it broke the windows-arm64 builder, whose current user display name is unavailable. This new CL fixes the issue by reintroducing the historical behavior of falling back to the user name instead of returning an error]. user.Current is slow on Windows sessions connected to an Active Directory domain. This is because it uses Windows APIs that do RPC calls to the domain controller, such as TranslateAccountW and NetUserGetInfo. This change speeds up user.Current by using the GetUserNameEx API instead, which is already optimized for retrieving the current user name in different formats. These are the improvements I see with the new implementation: goos: windows goarch: amd64 pkg: os/user cpu: Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz │ old.txt │ new.txt │ │ sec/op │ sec/op vs base │ Current-12 501.8µ ± 7% 118.6µ ± 11% -76.36% (p=0.000 n=10) │ old.txt │ new.txt │ │ B/op │ B/op vs base │ Current-12 888.0 ± 0% 832.0 ± 0% -6.31% (p=0.000 n=10) │ old.txt │ new.txt │ │ allocs/op │ allocs/op vs base │ Current-12 15.00 ± 0% 11.00 ± 0% -26.67% (p=0.000 n=10) Updates #5298 Fixes #21867 Fixes #68312 Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest,gotip-windows-arm64 Change-Id: Ib7f77086d389cccb9d91cb77ea688d438a0ee5fd Reviewed-on: https://go-review.googlesource.com/c/go/+/605135 Reviewed-by:Mauri de Souza Meneguzzo <mauri870@gmail.com> Reviewed-by:
-
apocelipes authored
Implement the encoding.(Binary|Text)Appender interfaces for "x509.OID". Implement the encoding.BinaryAppender interface for "rand/v2.PCG" and "rand/v2.ChaCha8". "rand/v2.ChaCha8.MarshalBinary" alse gains some performance benefits: │ old │ new │ │ sec/op │ sec/op vs base │ ChaCha8MarshalBinary-8 33.730n ± 2% 9.786n ± 1% -70.99% (p=0.000 n=10) ChaCha8MarshalBinaryRead-8 99.86n ± 1% 17.79n ± 0% -82.18% (p=0.000 n=10) geomean 58.04n 13.19n -77.27% │ old │ new │ │ B/op │ B/op vs base │ ChaCha8MarshalBinary-8 48.00 ± 0% 0.00 ± 0% -100.00% (p=0.000 n=10) ChaCha8MarshalBinaryRead-8 83.00 ± 0% 0.00 ± 0% -100.00% (p=0.000 n=10) │ old │ new │ │ allocs/op │ allocs/op vs base │ ChaCha8MarshalBinary-8 1.000 ± 0% 0.000 ± 0% -100.00% (p=0.000 n=10) ChaCha8MarshalBinaryRead-8 2.000 ± 0% 0.000 ± 0% -100.00% (p=0.000 n=10) For #62384 Change-Id: I604bde6dad90a916012909c7260f4bb06dcf5c0a GitHub-Last-Rev: 78abf9c5dfb74838985637798bcd5cb957541d20 GitHub-Pull-Request: golang/go#68987 Reviewed-on: https://go-review.googlesource.com/c/go/+/607079 Reviewed-by: -
Kir Kolyshkin authored
Change-Id: Iadd69360fb09714a280c4dae26639834df28a7dc Reviewed-on: https://go-review.googlesource.com/c/go/+/606659 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by:
-
Kir Kolyshkin authored
Change-Id: I2022fa27b072f9b34413a04a794aeb6d3c02166c Reviewed-on: https://go-review.googlesource.com/c/go/+/606658 Reviewed-by:
-
Robert Griesemer authored
Change-Id: I71d1dfec11657ffa8ffe12e87f6dbd65cbb1854b Reviewed-on: https://go-review.googlesource.com/c/go/+/607475 Reviewed-by:
-
Michael Anthony Knyszek authored
Currently the handle test code has a lot of duplicate type parameters that are already inferred. This results in IDE warnings which are annoying. Clean this up by consistently explicitly calling out the type in the argument, not the type parameter. Change-Id: I756203f37fc97c793cd5c5e612c6fd1802a84bc1 Reviewed-on: https://go-review.googlesource.com/c/go/+/607356 Reviewed-by:
-
Michael Anthony Knyszek authored
Currently the first thing Make does it get the abi.Type of its argument, and uses abi.TypeOf to do it. However, this has a problem for interface types, since the type of the value stored in the interface value will bleed through. This is a classic reflection mistake. Fix this by implementing and using a generic TypeFor which matches reflect.TypeFor. This gets the type of the type parameter, which is far less ambiguous and error-prone. Fixes #68990. Change-Id: Idd8d9a1095ef017e9cd7c7779314f7d4034f01a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/607355 Reviewed-by:
-
Cherry Mui authored
Add export functions to the wasm module on GOOS=js. (Other parts work the same way as wasip1.) Add a test. Fixes #65199. Change-Id: Ia22580859fe40631d487f70ee293c12867e0c988 Reviewed-on: https://go-review.googlesource.com/c/go/+/606855 Reviewed-by:
Zxilly Chou <zxilly@outlook.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by:
Michael Knyszek <mknyszek@google.com> Reviewed-by:
Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
-
