Re: [Qemu-devel] [PATCH] target-sparc: Store mmu index in TB flags

[Dennis Luehring]

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 :)