| Age | Commit message (Collapse) | Author |
|---|
|
It is annoying that non-x86 implementations of shlVU and shrVU
have to go out of their way to handle the trivial case shift==0
with their own copy loops. Instead, arrange to never call them
with shift==0, so that the code can be removed.
Unfortunately, there are linknames of shlVU, so we cannot
change that function. But we can rename the functions and
then leave behind a shlVU wrapper, so do that.
Since the big.Int API calls the operations Lsh and Rsh, rename
shlVU/shrVU to lshVU/rshVU. Also rename various other shl/shr
methods and functions to lsh/rsh.
Change-Id: Ieaf54e0110a298730aa3e4566ce5be57ba7fc121
Reviewed-on: https://go-review.googlesource.com/c/go/+/664896
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
|
|
Append operations in the decimal String function may cause several allocations.
Use make to pre allocate slices in String that have enough capacity to avoid additional allocations in append operations.
name old time/op new time/op delta
DecimalConversion-8 139µs ± 7% 109µs ± 2% -21.06% (p=0.000 n=10+10)
Change-Id: Id0284d204918a179a0421c51c35d86a3408e1bd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/233980
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Trust: Martin Möhrmann <moehrmann@google.com>
|
|
Change-Id: Id003e2dbecad7b3c249a747f8b4032135dfbe34f
Reviewed-on: https://go-review.googlesource.com/60670
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
|
|
Inspired by Alberto Donizetti's observations in
https://go-review.googlesource.com/#/c/30099/.
name old time/op new time/op delta
DecimalConversion-8 138µs ± 1% 136µs ± 2% -1.85% (p=0.000 n=10+10)
10 runs each, measured on a Mac Mini, 2.3 GHz Intel Core i7.
Performance improvements varied between -1.25% to -4.4%; -1.85% is
about in the middle of the observed improvement. The generated code
is slightly shorter in the inner loops of the conversion code.
Change-Id: I10fb3b2843da527691c39ad5e5e5bd37ed63e2fa
Reviewed-on: https://go-review.googlesource.com/31250
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
- renamed (nat) itoa to utoa (since that's what it is)
- added (nat) itoa that takes a sign parameter; this helps removing a few string copies
- used buffers instead of string+ in Rat conversions
Change-Id: I6b37a6b39557ae311cafdfe5c4a26e9246bde1a9
Reviewed-on: https://go-review.googlesource.com/14995
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
Eliminated unnecessary string conversions throughout and removed
(internal) capability for arbitrary character sets in conversion
routines (functionality was not exported and not used internally).
benchmark old ns/op new ns/op delta
BenchmarkDecimalConversion-8 198283 187085 -5.65%
BenchmarkStringPiParallel-8 46116 47822 +3.70%
BenchmarkString10Base2-8 216 166 -23.15%
BenchmarkString100Base2-8 886 762 -14.00%
BenchmarkString1000Base2-8 7296 6625 -9.20%
BenchmarkString10000Base2-8 72371 65563 -9.41%
BenchmarkString100000Base2-8 725849 672766 -7.31%
BenchmarkString10Base8-8 160 114 -28.75%
BenchmarkString100Base8-8 398 309 -22.36%
BenchmarkString1000Base8-8 2650 2244 -15.32%
BenchmarkString10000Base8-8 24974 21745 -12.93%
BenchmarkString100000Base8-8 245457 217489 -11.39%
BenchmarkString10Base10-8 337 288 -14.54%
BenchmarkString100Base10-8 1298 1046 -19.41%
BenchmarkString1000Base10-8 6200 5752 -7.23%
BenchmarkString10000Base10-8 24942 22589 -9.43%
BenchmarkString100000Base10-8 8012921 7947152 -0.82%
BenchmarkString10Base16-8 156 107 -31.41%
BenchmarkString100Base16-8 344 255 -25.87%
BenchmarkString1000Base16-8 2067 1705 -17.51%
BenchmarkString10000Base16-8 19026 16112 -15.32%
BenchmarkString100000Base16-8 184038 163457 -11.18%
Change-Id: I68bd807529bd9b985f4b6ac2a87764bcc1a7d2f7
Reviewed-on: https://go-review.googlesource.com/14926
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
Current result of DecimalConversion benchmark (for future reference):
BenchmarkDecimalConversion-8 10000 204770 ns/op
Measured on Mac Mini (late 2012) running OS X 10.10.5,
2.3 GHz Intel Core i7, 8 GB 1333 MHz DDR3.
Also: Removed comment suggesting to implement decimal by representing
digits as numbers 0..9 rather than ASCII chars '0'..'9' to avoid
repeated +/-'0' operations. Tried and it appears (per above benchmark)
that the +/-'0' operations are neglibile but the addition conversion
passes around it are not and that it makes things significantly slower.
Change-Id: I6ee033b1172043248093cc5d02abff5fc54c2e7a
Reviewed-on: https://go-review.googlesource.com/14857
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
Enabled all but a handful of disabled Float formatting test cases.
Fixes #10991.
Change-Id: Id18e160e857be2743429a377000e996978015a1a
Reviewed-on: https://go-review.googlesource.com/14850
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
A decimal represented 0.0 with a 0-length mantissa and undefined
exponent, but the formatting code assumes a valid zero exponent
if the float value is 0.0. The code worked because we allocate a
new decimal value each time and because there's no rounding that
lead to 0.0.
Change-Id: Ifd771d7709de83b87fdbf141786286b4c3e13d4f
Reviewed-on: https://go-review.googlesource.com/10448
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
This is a fairly significant _internal_ representation change. Instead
of encoding 0, finite, infinite, and NaN values with special mantissa
and exponent values, a new (1 byte) 'form' field is used (without making
the Float struct bigger). The form field permits simpler and faster
case distinctions. As a side benefit, for zero and non-finite floats,
fewer fields need to be set. Also, the exponent range is not the full
int32 range (in the old format, infExp and nanExp were used to represent
Inf and NaN values and tests for those values sometimes didn't test
for the empty mantissa, so the range was reduced by 2 values).
The correspondence between the old and new fields is as follows.
Old representation:
x neg mant exp
---------------------------------------------------------------
+/-0 sign empty 0
0 < |x| < +Inf sign mantissa exponent
+/-Inf sign empty infExp
NaN false empty nanExp
New representation (- stands for ignored fields):
x neg mant exp form
---------------------------------------------------------------
+/-0 sign - - zero
0 < |x| < +Inf sign mantissa exponent finite
+/-Inf sign - - inf
NaN - - - nan
Client should not be affected by this change.
Change-Id: I7e355894d602ceb23f9ec01da755fe6e0386b101
Reviewed-on: https://go-review.googlesource.com/6870
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
Change-Id: Id508ca2f6c087861e8c6bc536bc39e54dce09825
Reviewed-on: https://go-review.googlesource.com/3840
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
Change-Id: Ic0153397922ded28a5cb362e86ecdfec42e92163
Reviewed-on: https://go-review.googlesource.com/3752
Reviewed-by: Alan Donovan <adonovan@google.com>
|
