Messages in this thread | | | From | "Khimenko Victor" <> | Date | Mon, 27 Apr 1998 19:54:35 +0400 (MSD) | Subject | Re: faster strcpy() |
| |
PA> On Mon, 27 Apr 1998, Khimenko Victor wrote: PA> PA> #> > You're using a single buffer, which has vastly different L1 PA> #> > characteristics than multiple buffers; and different characteristics from PA> #> > what real-world apps would see because they have other things polluting PA> #> > the L1. I bring up this point mostly because the strlen/memcpy version is PA> #> > probably better on the pentium because of the L1 cache design, this is PA> #> > less likely to be an issue on the pentium pro. PA> #> > PA> #> I am using two buffers, one a source and another a destination. They PA> #> are deliberately the same buffers for both tests. There is no way that PA> #> the execution of one string function could affect the other since PA> #> the strings are way too long to fit in a cache. PA> #> PA> #"Way to long" ? What you mean ? Pentium MMX (and if I am remeber right PII) PA> #has >=16K data cache ! The same with K6 ... Even standard Pentium has 8K data PA> #cache ... PA> PA> Cache Clearup Time(tm). PA> PA> Pentium has 16K (2x8K), IIRC PA> P5MMX has 32K (2x16K), IIRC PA> K5 has 16K (2x8K), IIRC PA> K6 has 64K (2x32K), IIRC PA> Cx6x86 has 32K (1x32K (Unified Cache IS Faster(tm))) PA> Cx6x86MX has 64K (1x64K) PA> PentiumII varies. I believe Celerons have no internal cache, relying PA> entirely on the L2. Xeon I don't remember offhand. I'm not a Wintel kinda PA> guy. :) PA> I am know about [almost] all information below :-) Really I am only want say that P5MMX, K5, K6, etc. will use ONLY CACHE in this test (memory will be accessed only for writing) -- there are two buffers 4K each plus few variables in stack and very small amount of code (less then 1K in any cases). So 4K string is WAY TOO SMALL to overflow even L1 caches in most current processors, not "way too long to fit in a cache" !! Especially when you have L2 cache as well...
PA> The L1 cache is used for instructions. The more you have, the more PA> instructions you can cache. The more instructions you can cache, the more PA> you can do. PA> You are wrong (not you really but text above is wrong -- I am pretty sure that you are undestood all this stuff right :-) L1 cache is used not only for instructions cacheing but also for data cacheing (that's why there are 2x8K: 8K for instructions and 8K for data :-)... In this test case all instructions and all data MUST be cached! If I am remeber right all modern processors are 4-way (at least) associative caches so even usage of library will not hurt this...
PA> However, you run into the issue with cache block sizes. If you have 64K in PA> 4 16K blocks, it will seem like you have 32K, because the latency will PA> increase from having to address each cache block to get the instructions PA> out of it. If you have a 64K cache in 32K blocks, you won't really notice PA> any decrease. If you have 64K cache unified, it's a lot faster. Block PA> sizes also count when you're doing LONG instructions. If you've got 8K PA> blocks, and you've got a 24K instruction, it has to span three blocks, PA> which gives you a MAJOR performance hit right there, because it has to PA> waste cycles addressing and retrieving from each block, and then PA> combining. PA> PA> So, in short; not only does cache size count, but cache addressing and PA> block sizes. PA> PA> Oh, BTW, has anybody gotten their hands on the new Cyrix mII-300 yet? I PA> don't want to order mine till I know how Linux likes 'em so far. I haven't PA> had time to check the datasheets, much less print them, but as far as I PA> can guess, with the kind of FPU performance I've been seeing from my PA> 6x86MX's, they're using a dual-line FPU, which makes me wonder if that's PA> going to raise any issues in the kernel. (No, mII-300 isn't Cayenne core PA> yet. They're talking December or 1st Quarter 99 for the Cayennes, with the PA> quad-line FPU. (Intel, eat your heart out.;)) PA> PA> -Phil R. Jaenke (kernel@nls.net / prj@nls.net) PA> TheGuyInCharge(tm), Ketyra Designs - We get paid to break stuff :) PA> Linux pkrea.ketyra.INT 2.0.33 #15 Sat Apr 18 00:40:21 EDT 1998 i586 PA> Linux eiterra.nls.net 2.0.33 #15 Fri Apr 17 00:22:13 EDT 1998 i586 PA> - Linus says for 'brave people only.' I say 'keep a backup.' - :) PA> PA>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |