From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LedlU-0005PC-H9 for qemu-devel@nongnu.org; Tue, 03 Mar 2009 18:11:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LedlT-0005No-FN for qemu-devel@nongnu.org; Tue, 03 Mar 2009 18:11:07 -0500 Received: from [199.232.76.173] (port=39944 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LedlT-0005Na-4G for qemu-devel@nongnu.org; Tue, 03 Mar 2009 18:11:07 -0500 Received: from soufre.accelance.net ([213.162.48.15]:60267) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LedlS-0007LX-Ls for qemu-devel@nongnu.org; Tue, 03 Mar 2009 18:11:06 -0500 Received: from [192.168.0.5] (potipota.net [88.168.176.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by soufre.accelance.net (Postfix) with ESMTP id 0EC3F4502B for ; Wed, 4 Mar 2009 00:11:03 +0100 (CET) Subject: Re: [Qemu-devel] sh : performance problem From: Lionel Landwerlin In-Reply-To: <49AD50E2.7000401@juno.dti.ne.jp> References: <49A6C317.1080202@juno.dti.ne.jp> <1236038327.4975.16.camel@coalu.atr> <49AD50E2.7000401@juno.dti.ne.jp> Content-Type: text/plain; charset=utf-8 Date: Wed, 04 Mar 2009 00:11:39 +0100 Message-Id: <1236121899.4005.17.camel@coalu.atr> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Le mercredi 04 mars 2009 =C3=A0 00:46 +0900, Shin-ichiro KAWASAKI a =C3=A9= crit : > Lionel Landwerlin wrote: > > Shin-ichiro, > >=20 > > Sorry, but I cannot apply your patch cleanly on the last qemu-svn. > >=20 > > Instead, I would like to try another approach. The patch you proposed= to > > find (or not) a valid TLB entry has a complexity of O(log2(n)) (or > > something like that if I remember) instead here is a patch with a > > complexity of O(1). >=20 > Good work. I evaluated your patch on my environment, measuring > compile time for empty main() with gcc. >=20 > sh4 : 5.8 [seconds] O(n) utlb search. > sh4 : 4.6 [seconds] O(log2(n)) utlb search. > sh4 : 4.1 [seconds] O(1) utlb search by Lionel > arm : 0.8 [seconds] (-M versatilepb + Debian ARM) >=20 > Your patch has a nice score! >=20 > Now I've done the work to increase number of utlb entries from 64 to 25= 6, > and found that the score get arround 2.4 seconds. > I'm trying to increase it to 4096. Your O(1) search will be more impor= tant > as the entry number increase. We should setup a git repository to improve that or at least work on the same basis. Do you have a lot of patch on top of the last svn ? --=20 Lionel Landwerlin