From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30269 invoked by alias); 11 Feb 2004 12:33:49 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30262 invoked from network); 11 Feb 2004 12:33:48 -0000 Received: from unknown (HELO smtp.uk.superh.com) (193.128.105.170) by sources.redhat.com with SMTP; 11 Feb 2004 12:33:48 -0000 Received: from sh-uk-ex01.uk.w2k.superh.com (sh-uk-ex01 [192.168.16.17]) by smtp.uk.superh.com (8.12.10/8.12.10) with ESMTP id i1BCXFAA029463; Wed, 11 Feb 2004 12:33:17 GMT Received: from linsvr1.uk.superh.com ([192.168.16.50]) by sh-uk-ex01.uk.w2k.superh.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 11 Feb 2004 12:34:44 +0000 Received: (from renneckej@localhost) by linsvr1.uk.superh.com (8.11.6/8.11.6) id i1BCXF727696; Wed, 11 Feb 2004 12:33:15 GMT From: Joern Rennecke Message-Id: <200402111233.i1BCXF727696@linsvr1.uk.superh.com> Subject: Re: [RFA (revised)] sh-sim, expand the opcode table To: msnyder@redhat.com (Michael Snyder) Date: Wed, 11 Feb 2004 12:33:00 -0000 Cc: amylaar@fairadsl.co.uk (Joern Rennecke), joern.rennecke@superh.com, gdb-patches@sources.redhat.com In-Reply-To: <402979E9.7030902@redhat.com> from "Michael Snyder" at Feb 10, 2004 04:40:09 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Feb 2004 12:34:44.0589 (UTC) FILETIME=[6D99A9D0:01C3F09B] X-Scanned-By: MIMEDefang 2.39 X-SW-Source: 2004-02/txt/msg00280.txt.bz2 > > This is a multi-part message in MIME format. > --------------020902070606080708050409 > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Transfer-Encoding: 7bit > > Hi Joern, > > Here are some benchmark results. Following your advice, I took the > arith-rand test, increased its main loop count until it took around > 10 seconds to run on my test machine, and tested it against the eight > optimization combinations that are tested for in the gcc torture test > [see methodology notes attached] > > > I found that my change increased the runtime by 1.5 to 2 percent > (even when I added the new instructions that I'm working on). Was that with or without ACE_FAST ? > That didn't seem too bad to me, but I took some advice from Alex > Oliva and tried simply changing the sh_jmp_table from char to short. > This much simpler change increased the runtime by only 0.5 to 1 > percent, at the cost of 64k more data space. That makese sense... but what is the cost of adding the new instructions?