From owner-cvs-all@FreeBSD.ORG Mon Nov 10 21:07:57 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EE5B16A4CE for ; Mon, 10 Nov 2003 21:07:57 -0800 (PST) Received: from vette.gigo.com (vette.gigo.com [216.218.228.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3841043FAF for ; Mon, 10 Nov 2003 21:07:54 -0800 (PST) (envelope-from lioux@brturbo.com) Received: from 200.101.111.208 (200-101-111-208.bsace705.dsl.brasiltelecom.net.br [200.101.111.208]) by vette.gigo.com (Postfix) with ESMTP id D28075574 for ; Mon, 10 Nov 2003 20:53:53 -0800 (PST) Received: (qmail 26673 invoked by uid 1001); 11 Nov 2003 04:07:34 -0000 Message-ID: <20031111040734.26672.qmail@exxodus.fedaykin.here> Received: (qmail 19730 invoked from network); 26 Oct 2003 06:47:51 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 26 Oct 2003 06:47:51 -0000 Received: from pop3.uol.com.br by localhost with POP3 (fetchmail-6.2.5) for lioux-freebsd@localhost (single-drop); Sun, 26 Oct 2003 04:47:29 -0200 (BRST) Received: from peart.uol.com.br (172.26.5.186) by mtauol7.mail.sys.intranet (5.1.071) id 3EDB5C0C01D6B21D for lioux-freebsd@uol.com.br; Sun, 26 Oct 2003 03:42:24 -0300 Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by storm4.uol.com.br (Postfix) with ESMTP id DE0DCE632 for ; Sun, 26 Oct 2003 04:42:23 -0200 (BRST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id B6E7F56BBB for ; Sat, 25 Oct 2003 23:42:22 -0700 (PDT) (envelope-from owner-src-committers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id 4584E16A4E4; Sat, 25 Oct 2003 23:42:20 -0700 (PDT) Delivered-To: lioux@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 2385A16A4C0; Sat, 25 Oct 2003 23:42:19 -0700 (PDT) Delivered-To: src-committers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA32416A4B3; Sat, 25 Oct 2003 23:41:47 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3096B43FA3; Sat, 25 Oct 2003 23:41:45 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 18F0E2A8D5; Sat, 25 Oct 2003 23:41:45 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Jeff Roberson In-Reply-To: <20031025192122.Q43805-100000@mail.chesapeake.net> From: Peter Wemm Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 pmap.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 11 Nov 2003 05:07:57 -0000 X-Original-Date: Sat, 25 Oct 2003 23:41:45 -0700 X-List-Received-Date: Tue, 11 Nov 2003 05:07:57 -0000 Jeff Roberson wrote: > On Sat, 25 Oct 2003, Peter Wemm wrote: > Wow, pentium4 sucks. Yes, I agree then, we should revert the change. I'll do it. > > Intel looks more disappointing every day. Well, think of their optimization goals... The pentium4 was designed for two things.. 1) to increase MHz, since thats all dumbass customers and sales droids understand, and 2) to increase game framerate benchmarks. Anything that didn't contribute to that goal and consumed transistors started losing. For example.. you dont need a barrel shifter for graphics for values other than the standard vga plane depths (1,2,4,8,15,16,24) so out that goes. Graphics processing doesn't need cli/sti, so that gets demoted to 300 clock cycles instead of 8. invlpg isn't a graphics critical function, so there isn't any need to waste transisitors and microcode on it.. Massively deep pipelines help get the MHz up, and careful optimization can stop it affecting frame rates. But it blows chunks if you mispredict a branch in typical gcc generated code. Or take our libc syscall stubs.. every single one will be mispredicted because the usual case (no errors) has an opposite direction branch to what intel's static branch prediction expects. Argh. I'm too cynical. I'd better stop now before I really upset somebody. Anyway, if you can figure out a way to make invlpg affect graphics performance in a big way, then you can expect the next microcode update to do something dramatic about it. :-) Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5