Date: Sat, 25 Oct 2003 23:41:45 -0700 From: Peter Wemm <peter@wemm.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 pmap.c Message-ID: <20031026064145.18F0E2A8D5@canning.wemm.org> In-Reply-To: <20031025192122.Q43805-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031026064145.18F0E2A8D5>