aboutsummaryrefslogtreecommitdiff
path: root/.appveyor.yml
AgeCommit message (Collapse)Author
2020-07-30Merge #18011: Replace current benchmarking framework with nanobenchWladimir J. van der Laan
78c312c983255e15fc274de2368a2ec13ce81cbf Replace current benchmarking framework with nanobench (Martin Ankerl) Pull request description: Replace current benchmarking framework with nanobench This replaces the current benchmarking framework with nanobench [1], an MIT licensed single-header benchmarking library, of which I am the autor. This has in my opinion several advantages, especially on Linux: * fast: Running all benchmarks takes ~6 seconds instead of 4m13s on an Intel i7-8700 CPU @ 3.20GHz. * accurate: I ran e.g. the benchmark for SipHash_32b 10 times and calculate standard deviation / mean = coefficient of variation: * 0.57% CV for old benchmarking framework * 0.20% CV for nanobench So the benchmark results with nanobench seem to vary less than with the old framework. * It automatically determines runtime based on clock precision, no need to specify number of evaluations. * measure instructions, cycles, branches, instructions per cycle, branch misses (only Linux, when performance counters are available) * output in markdown table format. * Warn about unstable environment (frequency scaling, turbo, ...) * For better profiling, it is possible to set the environment variable NANOBENCH_ENDLESS to force endless running of a particular benchmark without the need to recompile. This makes it to e.g. run "perf top" and look at hotspots. Here is an example copy & pasted from the terminal output: | ns/byte | byte/s | err% | ins/byte | cyc/byte | IPC | bra/byte | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 2.52 | 396,529,415.94 | 0.6% | 25.42 | 8.02 | 3.169 | 0.06 | 0.0% | 0.03 | `bench/crypto_hash.cpp RIPEMD160` | 1.87 | 535,161,444.83 | 0.3% | 21.36 | 5.95 | 3.589 | 0.06 | 0.0% | 0.02 | `bench/crypto_hash.cpp SHA1` | 3.22 | 310,344,174.79 | 1.1% | 36.80 | 10.22 | 3.601 | 0.09 | 0.0% | 0.04 | `bench/crypto_hash.cpp SHA256` | 2.01 | 496,375,796.23 | 0.0% | 18.72 | 6.43 | 2.911 | 0.01 | 1.0% | 0.00 | `bench/crypto_hash.cpp SHA256D64_1024` | 7.23 | 138,263,519.35 | 0.1% | 82.66 | 23.11 | 3.577 | 1.63 | 0.1% | 0.00 | `bench/crypto_hash.cpp SHA256_32b` | 3.04 | 328,780,166.40 | 0.3% | 35.82 | 9.69 | 3.696 | 0.03 | 0.0% | 0.03 | `bench/crypto_hash.cpp SHA512` [1] https://github.com/martinus/nanobench ACKs for top commit: laanwj: ACK 78c312c983255e15fc274de2368a2ec13ce81cbf Tree-SHA512: 9e18770b18b6f95a7d0105a4a5497d31cf4eb5efe6574f4482f6f1b4c88d7e0946b9a4a1e9e8e6ecbf41a3f2d7571240677dcb45af29a6f0584e89b25f32e49e
2020-07-04Remove cached directories and associated script blocks from appveyor CI ↵Aaron Clauson
configuration.
2020-06-13Replace current benchmarking framework with nanobenchMartin Ankerl
This replaces the current benchmarking framework with nanobench [1], an MIT licensed single-header benchmarking library, of which I am the autor. This has in my opinion several advantages, especially on Linux: * fast: Running all benchmarks takes ~6 seconds instead of 4m13s on an Intel i7-8700 CPU @ 3.20GHz. * accurate: I ran e.g. the benchmark for SipHash_32b 10 times and calculate standard deviation / mean = coefficient of variation: * 0.57% CV for old benchmarking framework * 0.20% CV for nanobench So the benchmark results with nanobench seem to vary less than with the old framework. * It automatically determines runtime based on clock precision, no need to specify number of evaluations. * measure instructions, cycles, branches, instructions per cycle, branch misses (only Linux, when performance counters are available) * output in markdown table format. * Warn about unstable environment (frequency scaling, turbo, ...) * For better profiling, it is possible to set the environment variable NANOBENCH_ENDLESS to force endless running of a particular benchmark without the need to recompile. This makes it to e.g. run "perf top" and look at hotspots. Here is an example copy & pasted from the terminal output: | ns/byte | byte/s | err% | ins/byte | cyc/byte | IPC | bra/byte | miss% | total | benchmark |--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|---------------:|--------:|----------:|:---------- | 2.52 | 396,529,415.94 | 0.6% | 25.42 | 8.02 | 3.169 | 0.06 | 0.0% | 0.03 | `bench/crypto_hash.cpp RIPEMD160` | 1.87 | 535,161,444.83 | 0.3% | 21.36 | 5.95 | 3.589 | 0.06 | 0.0% | 0.02 | `bench/crypto_hash.cpp SHA1` | 3.22 | 310,344,174.79 | 1.1% | 36.80 | 10.22 | 3.601 | 0.09 | 0.0% | 0.04 | `bench/crypto_hash.cpp SHA256` | 2.01 | 496,375,796.23 | 0.0% | 18.72 | 6.43 | 2.911 | 0.01 | 1.0% | 0.00 | `bench/crypto_hash.cpp SHA256D64_1024` | 7.23 | 138,263,519.35 | 0.1% | 82.66 | 23.11 | 3.577 | 1.63 | 0.1% | 0.00 | `bench/crypto_hash.cpp SHA256_32b` | 3.04 | 328,780,166.40 | 0.3% | 35.82 | 9.69 | 3.696 | 0.03 | 0.0% | 0.03 | `bench/crypto_hash.cpp SHA512` [1] https://github.com/martinus/nanobench * Adds support for asymptotes This adds support to calculate asymptotic complexity of a benchmark. This is similar to #17375, but currently only one asymptote is supported, and I have added support in the benchmark `ComplexMemPool` as an example. Usage is e.g. like this: ``` ./bench_bitcoin -filter=ComplexMemPool -asymptote=25,50,100,200,400,600,800 ``` This runs the benchmark `ComplexMemPool` several times but with different complexityN settings. The benchmark can extract that number and use it accordingly. Here, it's used for `childTxs`. The output is this: | complexityN | ns/op | op/s | err% | ins/op | cyc/op | IPC | total | benchmark |------------:|--------------------:|--------------------:|--------:|----------------:|----------------:|-------:|----------:|:---------- | 25 | 1,064,241.00 | 939.64 | 1.4% | 3,960,279.00 | 2,829,708.00 | 1.400 | 0.01 | `ComplexMemPool` | 50 | 1,579,530.00 | 633.10 | 1.0% | 6,231,810.00 | 4,412,674.00 | 1.412 | 0.02 | `ComplexMemPool` | 100 | 4,022,774.00 | 248.58 | 0.6% | 16,544,406.00 | 11,889,535.00 | 1.392 | 0.04 | `ComplexMemPool` | 200 | 15,390,986.00 | 64.97 | 0.2% | 63,904,254.00 | 47,731,705.00 | 1.339 | 0.17 | `ComplexMemPool` | 400 | 69,394,711.00 | 14.41 | 0.1% | 272,602,461.00 | 219,014,691.00 | 1.245 | 0.76 | `ComplexMemPool` | 600 | 168,977,165.00 | 5.92 | 0.1% | 639,108,082.00 | 535,316,887.00 | 1.194 | 1.86 | `ComplexMemPool` | 800 | 310,109,077.00 | 3.22 | 0.1% |1,149,134,246.00 | 984,620,812.00 | 1.167 | 3.41 | `ComplexMemPool` | coefficient | err% | complexity |--------------:|-------:|------------ | 4.78486e-07 | 4.5% | O(n^2) | 6.38557e-10 | 21.7% | O(n^3) | 3.42338e-05 | 38.0% | O(n log n) | 0.000313914 | 46.9% | O(n) | 0.0129823 | 114.4% | O(log n) | 0.0815055 | 133.8% | O(1) The best fitting curve is O(n^2), so the algorithm seems to scale quadratic with `childTxs` in the range 25 to 800.
2020-04-15Merge #18640: appveyor: Remove clcacheMarcoFalke
fac0c8db9f634ea7231fb0b6dc139ae0bda4a051 appveyor: Remove clcache (MarcoFalke) Pull request description: The build time without cache seems to be 47 minutes and with cache 46 minutes. Maybe we can save more time by not installing clcache. Top commit has no ACKs. Tree-SHA512: ce503641a465f5e49deb7aa6b566aaab5e567148c001704451891c49ba7ade3219ca788bc0d8e55565febb9aadd579e26894f6c03b99755eb8b5d1498acf4dc9
2020-04-14appveyor: Remove clcacheMarcoFalke
2020-04-14appveyor: Disable functional tests for nowMarcoFalke
Also add a draft for a Windows build on cirrus. The draft can be finished later.
2020-04-08appveyor: Enable minimal unit test logging to aid debuggingMarcoFalke
2020-01-25Updated appveyor job to checkout a specific vcpkg commit ID.Aaron Clauson
2019-12-12Update msvc build for Visual Studio 2019 v16.4Aaron Clauson
msvc warning C4834 for the Bitcoin Core build was introduced by Visual Studio 16.4.0. This PR adds an ignore rule for the warning (it's related to the nodiscard attribute and is not considered relevant). An additional side effect of the msvc compiler update is the prebuilt Qt5.9.8 libraries cannot be linked due to being built with an earlier version of the compiler. To fix this a new Qt5.9.8 version has been compiled and the appveyor job updated to use them. The GitHub Actions job needs to continue to use the original Qt5.9.8 libraries until the latest GitHub Windows image also updates to >= Visual Studio 2019 v16.4.
2019-11-10Moves vcpkg list to a text file and updates the appveyor job and readme to ↵Aaron Clauson
use it.
2019-11-06Updated appveyor config:Aaron Clauson
- Update build image from Visual Studio 2017 to Visual Studio 2019. - Updated Qt static library from Qt5.9.7 to Qt5.9.8. - Added commands to update vcpkg port files (this does not update already installed packages). - Updated vcpkg package list as per #17309. - Removed commands setting common project file options. Now done via common.init.vcxproj include. - Changed msbuild verbosity from normal to quiet. Normal rights a LOT of logs and impacts appveyor job duration. Updated msvc project configs: - Updated platform toolset from v141 to v142. - Updated Qt static library from Qt5.9.7 to Qt5.9.8. - Added ignore for linker warning building bitcoin-qt program. - Added missing util/str.cpp class file to test_bitcoin project file.
2019-09-08Added libbitcoin_qt and bitcoin-qt to the msbuild configuration.Aaron Clauson
2019-07-31Changes the verbosity of msbuild from quiet to normal in the appveyor ↵Aaron Clauson
script. Increasing the verbosity helps to identify the cause of build errors which is the main purpose of the appveyor script.
2019-07-01[MSVC] Copy build output to src/ automatically after buildnicolas.dorier
2019-06-21[MSVC]: Create the config.ini as part of bitcoind buildnicolas.dorier
2019-04-26appveyor: Write @PACKAGE_NAME@ to configMarcoFalke
2019-03-01appveyor: Don't build debug libraries instead of "build and delete"Chun Kuan Lee
2019-02-17appveyor: Remove unused NDEBUG removalChun Kuan Lee
2019-02-17Merge #15398: msvc: add rapidcheck property testsWladimir J. van der Laan
d067e81dcf574b6504813bbf742cd5af057e8e9b msvc: add rapid check property tests (Chun Kuan Lee) Pull request description: This PR add the property tests into the binaries built by MSVC. And another trivial change is that I reordered the appveyor package list. Tree-SHA512: 25d66db464beb7b512cc1f88d8557d6a047000a97d78f49884bb91a65ec142e0458039c919f51bf73413359fcf3e63e1ea4d76586b862f1c140d2ca05ee8b23d
2019-02-14[build] AppVeyor: clean cache when build configuration changesSjors Provoost
2019-02-12appveyor: Remove outdated librariesChun Kuan Lee
2019-02-07test_runner: Remove unused --force optionMarcoFalke
2019-02-04msvc: add rapid check property testsChun Kuan Lee
2019-02-01msvc: build leveldb locallyChun Kuan Lee
2019-02-01msvc: build secp256k1 locallyChun Kuan Lee
2019-01-15Fix remaining compiler warnings (MSVC). Move disabling of specific warnings ↵practicalswift
from /nowarn to project file.
2018-11-06appveyor: Script improvement part IIChun Kuan Lee
2018-11-01test_runner: Remove travis specific codeMarcoFalke
2018-10-24appveyor: Enable multiwallet testChun Kuan Lee
2018-10-05appveyor: trivial build cache modificationsChun Kuan Lee
2018-10-03tests: Make appveyor run with --useclipracticalswift
2018-09-26tests: exclude all tests with difference parametersChun Kuan Lee
2018-09-25Merge #14306: AppVeyor: Move AppVeyor YAML to dot-file-style YAMLMarcoFalke
ff40357da1 AppVeyor: Move AppVeyor YAML to dot-file-style YAML (Mitchell Cash) Pull request description: AppVeyor supports dot-file-style YAML named `.appveyor.yml` as is. This helps keep the root of the repository clean(ish) and readable by having the CI files as dot-files. Source: https://www.appveyor.com/docs/build-configuration/#yaml-file-alternative-naming Tree-SHA512: da2a78aff775e5e146f0784b1a6617d0371a5821da8a53be9e4aa57409cb16360f43d0afa5745f81f776599950cab4219a5d7ee7247d42e25861963ea487db66
2018-09-25AppVeyor: Move AppVeyor YAML to dot-file-style YAMLMitchell Cash
AppVeyor supports dot-file-style YAML named .appveyor.yml as is. This helps keep the root of the repository clean(ish) and readable by having the CI files as dot-files.