lkml.org 
[lkml]   [1998]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.044 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site