From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3CF42C433DB for ; Thu, 21 Jan 2021 20:11:25 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8AE1223A5C for ; Thu, 21 Jan 2021 20:11:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8AE1223A5C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=eik.bme.hu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:59974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2gId-000747-IQ for qemu-devel@archiver.kernel.org; Thu, 21 Jan 2021 15:11:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41296) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2gGT-0005bZ-Bd for qemu-devel@nongnu.org; Thu, 21 Jan 2021 15:09:09 -0500 Received: from zero.eik.bme.hu ([152.66.115.2]:18391) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2gGP-0007AE-V3 for qemu-devel@nongnu.org; Thu, 21 Jan 2021 15:09:08 -0500 Received: from zero.eik.bme.hu (blah.eik.bme.hu [152.66.115.182]) by localhost (Postfix) with SMTP id 9F5BE7456E3; Thu, 21 Jan 2021 21:09:00 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 753A47456B8; Thu, 21 Jan 2021 21:09:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 7364D7456B7; Thu, 21 Jan 2021 21:09:00 +0100 (CET) Date: Thu, 21 Jan 2021 21:09:00 +0100 (CET) From: BALATON Zoltan To: Richard Henderson Subject: Re: [PATCH 0/5] tcg: Dynamically allocate temporaries In-Reply-To: <7595e6e-bc3d-d626-656b-e7ba3bfd8b90@eik.bme.hu> Message-ID: <4d24ab64-6b6-ae28-4e34-9d68c99a4a48@eik.bme.hu> References: <20210119183428.556706-1-richard.henderson@linaro.org> <7595e6e-bc3d-d626-656b-e7ba3bfd8b90@eik.bme.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Received-SPF: pass client-ip=152.66.115.2; envelope-from=balaton@eik.bme.hu; helo=zero.eik.bme.hu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lvivier@redhat.com, alistair23@gmail.com, qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, 20 Jan 2021, BALATON Zoltan wrote: > On Tue, 19 Jan 2021, Richard Henderson wrote: >> My recent change for caching tcg constants has, in a number of cases, >> overflowed the statically allocated array of temporaries. Change to >> dynamic allocation. > > This seems to work for me so > > Tested-by: BALATON Zoltan > > but have you done any performance tests to check that this actually improves > emulation speed? To mee it seems slower. Booting AmigaOS on sam460ex with > c0dd6654f207 (just before your TCG series) takes: > > real 0m33.829s > user 0m34.432s > sys 0m0.296s > > but on HEAD with this series: > > real 0m44.381s > user 0m46.058s > sys 0m0.532s > > This is noticable decrease in speed also without measuring it. With just > increasing the TCG_MAX_TEMPS to 2048 on 7c79721606be without this series I > get: > > real 0m42.681s > user 0m44.208s > sys 0m0.435s > > So the performance regression is somewhere in the original series not in this > fix up series. I've tried to do more measurements to identify where it got slower but I could not reproduce it today. I'm now getting around 42 seconds both before and after the series so not sure what made it faster before but it's probably not because of a code change then. Regards, BALATON Zoltan