diff options
author | Axel Waggershauser <awagger@gmail.com> | 2013-03-15 00:42:15 +0100 |
---|---|---|
committer | The Qt Project <gerrit-noreply@qt-project.org> | 2013-03-16 20:22:50 +0100 |
commit | b11317a64339f5a4bcffc8234ecaf15c7fb416f2 (patch) | |
tree | f81e40ee49f5109b4100048d131d5bb922b448aa /tests/benchmarks/README | |
parent | 72367a94a750355eb748793ce8c365373a332c9c (diff) |
Whitespace cleanup: remove trailing whitespace
Remove all trailing whitespace from the following list of files:
*.cpp *.h *.conf *.qdoc *.pro *.pri *.mm *.rc *.pl *.qps *.xpm *.txt *README
excluding 3rdparty, test-data and auto generated code.
Note A): the only non 3rdparty c++-files that still
have trailing whitespace after this change are:
* src/corelib/codecs/cp949codetbl_p.h
* src/corelib/codecs/qjpunicode.cpp
* src/corelib/codecs/qbig5codec.cpp
* src/corelib/xml/qxmlstream_p.h
* src/tools/qdoc/qmlparser/qqmljsgrammar.cpp
* src/tools/uic/ui4.cpp
* tests/auto/other/qtokenautomaton/tokenizers/*
* tests/benchmarks/corelib/tools/qstring/data.cpp
* util/lexgen/tokenizer.cpp
Note B): in about 30 files some overlapping 'leading tab' and
'TAB character in non-leading whitespace' issues have been fixed
to make the sanity bot happy. Plus some general ws-fixes here
and there as asked for during review.
Change-Id: Ia713113c34d82442d6ce4d93d8b1cf545075d11d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Diffstat (limited to 'tests/benchmarks/README')
-rw-r--r-- | tests/benchmarks/README | 48 |
1 files changed, 24 insertions, 24 deletions
diff --git a/tests/benchmarks/README b/tests/benchmarks/README index d437299fee..8d017cd9a7 100644 --- a/tests/benchmarks/README +++ b/tests/benchmarks/README @@ -2,7 +2,7 @@ The most reliable way of running benchmarks is to do it in an otherwise idle system. On a busy system, the results will vary according to the other tasks demanding attention in the system. -We have managed to obtain quite reliable results by doing the following on +We have managed to obtain quite reliable results by doing the following on Linux (and you need root): - switching the scheduler to a Real-Time mode @@ -10,23 +10,23 @@ Linux (and you need root): - disabling the other thread of the same core This should work rather well for CPU-intensive tasks. A task that is in Real- -Time mode will simply not be preempted by the OS. But if you make OS syscalls, -especially I/O ones, your task will be de-scheduled. Note that this includes -page faults, so if you can, make sure your benchmark's warmup code paths touch +Time mode will simply not be preempted by the OS. But if you make OS syscalls, +especially I/O ones, your task will be de-scheduled. Note that this includes +page faults, so if you can, make sure your benchmark's warmup code paths touch most of the data. -To do this you need a tool called schedtool (package schedtool), from +To do this you need a tool called schedtool (package schedtool), from http://freequaos.host.sk/schedtool/ From this point on, we are using CPU0 for all tasks: -If you have a Hyperthreaded multi-core processor (Core-i5 and Core-i7), you -have to disable the other thread of the same core as CPU0. To discover which +If you have a Hyperthreaded multi-core processor (Core-i5 and Core-i7), you +have to disable the other thread of the same core as CPU0. To discover which one it is: $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list -This will print something like 0,4, meaning that CPUs 0 and 4 are sibling +This will print something like 0,4, meaning that CPUs 0 and 4 are sibling threads on the same core. So we'll turn CPU 4 off: (as root) @@ -34,7 +34,7 @@ threads on the same core. So we'll turn CPU 4 off: To turn it back on, echo 1 into the same file. -To run a task on CPU 0 exclusively, using FIFO RT priority 10, you run the +To run a task on CPU 0 exclusively, using FIFO RT priority 10, you run the following: (as root) @@ -43,38 +43,38 @@ following: For example: # schedtool -F -p 10 -a 1 -e ./tst_bench_qstring -tickcounter -Warning: if your task livelocks or takes far too long to complete, your system -may be unusable for a long time, especially if you don't have other cores to +Warning: if your task livelocks or takes far too long to complete, your system +may be unusable for a long time, especially if you don't have other cores to run stuff on. To prevent that, run it before schedtool and time it. -You can also limit the CPU time that the task is allowed to take. Run in the +You can also limit the CPU time that the task is allowed to take. Run in the same shell as you'll run schedtool: $ ulimit -s 300 To limit to 300 seconds (5 minutes) -If your task runs away, it will get a SIGXCPU after consuming 5 minutes of CPU +If your task runs away, it will get a SIGXCPU after consuming 5 minutes of CPU time (5 minutes running at 100%). -If your app is multithreaded, you may want to give it more CPUs, like CPU0 and +If your app is multithreaded, you may want to give it more CPUs, like CPU0 and CPU1 with -a 3 (it's a bitmask). -For best results, you should disable ALL other cores and threads of the same -processor. The new Core-i7 have one processor with 4 cores, -each core can run 2 threads; the older Mac Pros have two processors with 4 -cores each. So on those Mac Pros, you'd disable cores 1, 2 and 3, while on the +For best results, you should disable ALL other cores and threads of the same +processor. The new Core-i7 have one processor with 4 cores, +each core can run 2 threads; the older Mac Pros have two processors with 4 +cores each. So on those Mac Pros, you'd disable cores 1, 2 and 3, while on the Core-i7, you'll need to disable all other CPUs. -However, disabling just the sibling thread seems to produce very reliable -results for me already, with variance often below 0.5% (even though there are +However, disabling just the sibling thread seems to produce very reliable +results for me already, with variance often below 0.5% (even though there are some measurable spikes). Other things to try: -Running the benchmark with highest priority, i.e. "sudo nice -19" -usually produces stable results on some machines. If the benchmark also -involves displaying something on the screen (on X11), running it with -"-sync" is a must. Though, in that case the "real" cost is not correct, +Running the benchmark with highest priority, i.e. "sudo nice -19" +usually produces stable results on some machines. If the benchmark also +involves displaying something on the screen (on X11), running it with +"-sync" is a must. Though, in that case the "real" cost is not correct, but it is useful to discover regressions. Also; not many people know about ionice (1) |