From owner-cvs-all@FreeBSD.ORG Sat Oct 25 23:41:47 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 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> Date: Sat, 25 Oct 2003 23:41:45 -0700 From: Peter Wemm Message-Id: <20031026064145.18F0E2A8D5@canning.wemm.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 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 06:41:47 -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