Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:13153 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16074 invoked by uid 1010); 4 Oct 2004 19:27:02 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 16048 invoked from network); 4 Oct 2004 19:27:01 -0000 Received: from unknown (HELO jan.prima.de) (83.97.50.139) by pb1.pair.com with SMTP; 4 Oct 2004 19:27:01 -0000 Received: from BAUMBART (pD95F871C.dip.t-dialin.net [::ffff:217.95.135.28]) (IDENT: HydraIRC, AUTH: LOGIN tobi) by jan.prima.de with esmtp; Mon, 04 Oct 2004 19:27:00 +0000 Date: Mon, 4 Oct 2004 21:26:51 +0200 Reply-To: Marcus Boerger X-Priority: 3 (Normal) Message-ID: <4710058306.20041004212651@marcus-boerger.de> To: Sterling Hughes CC: Ilia Alshanetsky , Sebastian Bergmann , internals@lists.php.net In-Reply-To: <24e5f3b7041004121810f59641@mail.gmail.com> References: <41619EE0.70307@prohost.org> <24e5f3b7041004121810f59641@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] GCC/CFLAGS Benchmark for HEAD and PHP_5_0 From: helly@php.net (Marcus Boerger) Hello Sterling, hello Sebastian, Monday, October 4, 2004, 9:18:47 PM, you wrote: > On Mon, 04 Oct 2004 15:05:04 -0400, Ilia Alshanetsky wrote: >> Very interesting numbers, I'd like to second Marcus' request for a 4.3 >> benchmark. >> >> I was somewhat surprised by O2 and O1 being slower then Os, while O3 in >> some cases may end over optimizing which would it explain it's poor >> showing. However, it could be that it makes simple situations slower, >> while more complex operations that are generally more CPU intensive will >> in fact become faster. If you don't mind, could you please all include >> data for "time make test" as it seems to cover a much greater quantity >> of code. >> > Thies and I found the same thing when we did our patch. It relates to > the size of the executor loop that is generated, if you have too much > inlining you end up blowing your instruction cache. That means not using all opcodes could result in faster execution with the function based executor. Maybe sebastian could try that too? -- Best regards, Marcus mailto:helly@php.net