Lines Matching +full:3 +full:- +full:ch1 +full:- +full:supply
18 3. If you've changed APIs, update the documentation.
30 Zstd uses a branch-based workflow for making changes to the codebase. Typically, zstd
51 git checkout -b <branch-name>
52 git push origin <branch-name>
57 git add -u && git commit -m <message>
58 git push origin <branch-name>
93 3. Merge and Release
113 executing it. It usually helps us find many simple bugs. Zstd uses clang's `scan-build` tool for
114 …install it by following the instructions for your OS on https://clang-analyzer.llvm.org/scan-build.
122 In general, you can use `scan-build` to static analyze any build script. For example, to static ana…
126 scan-build make -C contrib/largeNbDicts largeNbDicts
130 `scan-build` is part of our regular CI suite. Other static analyzers are not.
134 - Static analyzers are full of false positive. The signal to noise ratio is actually pretty low.
135 - A good CI policy is "zero-warning tolerance". That means that all issues must be solved, includin…
136 - Multiple static analyzers will feature multiple kind of false positives, sometimes applying to th…
139 - As if that was not enough, the list of false positives change with each version. It's hard enough…
153 re-run tests and cancel running tests from the PR page or from the respective CI's dashboard.
161 ### Third-party CI
163 For these, we use a variety of third-party services (listed below). It is not necessary to set
168 …-----------|--------------------------------------------------------------------------------------…
169 …-x86 architectures such as PowerPC | https://docs…
170 … | https://www.appveyor.com/blog/2018/10/02/github-apps-integration/ <br> h…
171 … | https://github.com/marketplace/cirrus-ci/ …
172 …ci.com/docs/2.0/getting-started/#setting-up-circleci <br> https://youtu.be/Js3hMUsSZ2c <br> https:…
181 landscape and corresponding trade-offs have been adequately analyzed, reproduced, and presented.
184 always welcome contributions to improve performance (or worsen performance for the trade-off of
191 would-be PR. Of course, just because a topic has already been discussed (and perhaps rejected
197 take the time to run extensive, long-duration, and potentially cross-(os, platform, process, etc)
202 3. Optimizing performance for a certain OS, processor vendor, compiler, or network system is a perf…
205 submitting changes that are clang-specific, windows-specific, etc.
218 Of course, benchmarking can be done on non-hyper-stable machines as well. You will just have to
245 another cpu/memory-intensive application in the background. If you are running benchmarks on your
254 …s, you can "Set Processor Affinity" using https://www.thewindowsclub.com/processor-affinity-windows
255 …pple.com/library/archive/releasenotes/Performance/RN-AffinityAPI/#//apple_ref/doc/uid/TP40006635-C…
256 3. To benchmark, you will likely end up writing a separate c/c++ program that will link libzstd.
269 The fastest signal you can get regarding your performance changes is via the in-build zstd cli
271 and then additionally also specify the `-b#` option. Doing this will run our benchmarking pipeline
277 is `zstd -b`. You might try to do something like this. Note: you can use the `-i` option to
278 specify a running time for your benchmark in seconds (default is 3 seconds).
282 $ git checkout <commit-before-your-change>
283 $ make && cp zstd zstd-old
284 $ git checkout <commit-after-your-change>
285 $ make && cp zstd zstd-new
286 $ zstd-old -i5 -b1 <your-test-data>
287 1<your-test-data> : 8990 -> 3992 (2.252), 302.6 MB/s , 626.4 MB/s
288 $ zstd-new -i5 -b1 <your-test-data>
289 1<your-test-data> : 8990 -> 3992 (2.252), 302.8 MB/s , 628.4 MB/s
295 changed but there could be a small <3% improvement that the noise on the host machine
296 obscured. So unless you see a large performance win (10-15% consistently) using just
328 3. Close all other applications except for your instruments window and your terminal
335 $ zstd -b1 -i5 <my-data> # this will run for 5 seconds
344 you think you have collected enough samples (usually this is the case after 3 seconds of
350 you will have to supply the `-g` flag alone with your build script. You might also
351 have to provide the `-fno-omit-frame-pointer` flag
364 * Use `perf stat -r # <bench-program>` to quickly get some relevant timing and
367 * Perf has a long list of hardware counters that can be viewed with `perf --list`.
371 counter `L1-dcache-load-misses`
390 The following is a non-exhaustive list of rules employed in zstd code base:
394 with 2 extensions : 64-bit `long long` types, and variadic macros.
396 Sub-project in `contrib/` are allowed to use other conventions.
406 - Reduce dependencies to the minimum possible level.
411 - Within `lib/`, this policy is even more drastic.
416 Other accepted non-symbol headers are `<stddef.h>` and `<limits.h>`.
417 - Within the project, there is a strict hierarchy of dependencies that must be respected.
423 - Functions in `lib/` must use very little stack space,
437 - `PREFIX_prefix2_camelCase`
438 - `PREFIX_camelCase_extendedQualifier`
439 * Multi-words names generally consist of an action followed by object:
440 - for example : `ZSTD_createCCtx()`
442 - `goBackward` rather than `notGoForward`
455 Any variable that can be `const` (aka. read-only) **must** be `const`.
459 …Conversely, non-const variables are a signal to readers to watch out for modifications later on in…