From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4939815F.9020509@telus.net> Date: Fri, 5 Dec 2008 11:30:39 -0800 From: Paul Lalonde User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <13426df10812042239pde2100dw696049def0160c4a@mail.gmail.com> <39cb2be32e592403f7336c6200cf56a3@quanstro.net> <13426df10812051049j40b40b78u4ae74a3fc7df07a3@mail.gmail.com> <49397F3E.9070801@telus.net> <57cb40901c57600ac592ec15ccb1a687@coraid.com> In-Reply-To: <57cb40901c57600ac592ec15ccb1a687@coraid.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [9fans] image/memimage speed Topicbox-Message-UUID: 5b3b58d4-ead4-11e9-9d60-3106f5b1d025 But random access patterns suck at being speculatively cached. Linear access patterns still require reasonably careful work for the caching to do the right thing. Expecting your entire frame buffer to be cached in L2 isn't particularly reasonable. Paul erik quanstrom wrote: > On Fri Dec 5 14:23:22 EST 2008, plalonde@telus.net wrote: > >> Again, you can stream a whole frame buffer reasonably fast - that should >> be nearly full-rate; it should be full rate if you pre-fetch with >> sufficient advance notice (500-1000 clocks), or DMA. But random access >> reads *have* to be slow: you get a stall while the system goes to PCIe >> for each cache line you attempt to read from. >> >> Paul >> > > the cpu is allowed to speculatively cache WC memory. > > - erik > >