From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZU8x4-00039z-DI for qemu-devel@nongnu.org; Tue, 25 Aug 2015 03:47:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZU8x0-0008C8-4L for qemu-devel@nongnu.org; Tue, 25 Aug 2015 03:47:26 -0400 Received: from mout.gmx.net ([212.227.15.15]:55229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZU8wz-0008Ag-QR for qemu-devel@nongnu.org; Tue, 25 Aug 2015 03:47:22 -0400 References: <1440476386-7365-1-git-send-email-rth@twiddle.net> <55DC00F7.5010100@gmx.net> From: Dennis Luehring Message-ID: <55DC1D6F.4070301@gmx.net> Date: Tue, 25 Aug 2015 09:46:55 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-sparc: Store mmu index in TB flags List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: Mark Cave-Ayland , qemu-devel , Aurelien Jarno , Richard Henderson 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 :)