Am 25.08.2015 um 08:44 schrieb Artyom Tarasenko:
>your patch gives the worst result in stream benchmark but nearly the best in
>pugixml compile times and prime.c runtime
>every tried patch or branch nearly halfs the speed of the stream benchmark
>comapred to qemu-git-master
This is very surprising: the patch should have no effect on a sun4u machine.
Have you applied it to the master or some other branch?
Have you pulled the master branch recently? Maybe there was another
change affecting the performance?
i've completely removed my git qemu folder and freshly cloned the
qemu-master, applied the patch
and rechecked if applied - and these are my numbers
i always remove my qemu-master (i always use master, other branch or
clean master + patch) and build completely and im always using the same
settings, remadisk etc. for compilation and benchmarking
and its not realy surprising - there are ~5 people in the talk - each
with different ideas where the slowness
comes from and all use different or non formalized "bechmark-suits"
(like your combination or my 3 tests) -
each test i've made seems to give wired or suprising results - so my
conclusion is: no one realy knows what it is and where it
comes from - and as long as there is no equal benchmark-suite (for
example NetBSD + the 3 tests) it will go on to be
surprising or wired when i post results
Example:
at first it was - your RAM is full, your system is swapping, your
harddisk is slow etc. talks with "Artyom Tarasenko", "Aurelien Jarno"
and some others
- none of these are a problem - i've got more then enough RAM and CPU
power in my host and free in the guest, and using a ramdisk for the
image make IO less noisy
"Aurelien Jarno" said it could be the 32bit userland in the my debian
7.8 SPARC64 system - and showed numbers with prime.c that proves it
i've rechecked that and came to the same results and switched over to
NetBSD SPARC64 (a pure 64bit system) that make prime.c the fastest
but that does not realy reduce the pugixml compile times (my host needs
3sek, NetBSD takes ~3minutes, building cmake need ~10 hours or longer)
then someone said it could be IO - so i put the NetBSD image on a
ramdisk - helped a little
then "Karel Gardas" got the idea that the compilation process is primary
memory bound - so asked me to use the stream-benchmark - i've posting
results on every change
and i still don't know if the numbers im getting from the benchmark are
relevant in any way (no one realy replies to them) - but they seems to
be very relevant
then i've tested the branch from tgc-indirect branch - prime.c get a
little better, stream get slower
the last patch from Richard Henderson gives still unclear results -
prime.c get a little better, stream get the slowest
the next thing i will do is a complete script based qemu-compilation and
benchmark run in my NetBSD image - then the human-factor is down to 0%
and the
only source of suprising/wired results is my host-hardware
is threre any interest in my NetBSD image (or the installation process)?
(to have a change to get to similar results in the differences)
should i add some other tests?
what is usualy in use for performance tests? still no answer on that
question
im ready and happy to compile/run all your got/want :)
