Message boards :
Number crunching :
Size of L2 cache
Message board moderation
Author | Message |
---|---|
edshubert Send message Joined: 6 Jun 99 Posts: 1 Credit: 46,805 RAC: 0 |
Does the size of the cpu l2 cache really improve the speeds of seti and other projects? Iam looking at several AMD cpu's with either 1MG or 512K size caches. Even though not much of a price difference, if the larger cache sizes don't help then I don't need them. tia |
Divide Overflow Send message Joined: 3 Apr 99 Posts: 365 Credit: 131,684 RAC: 0 |
Seti@Home will run noticeably faster on a CPU with a larger L2 cache. From what I've seen, 1 MB seems to be the "sweet spot". |
7822531 Send message Joined: 3 Apr 99 Posts: 820 Credit: 692 RAC: 0 |
It's been my experience that an L2 is crucial. Don't chintz out - get the 1MB. Your CPU will thank you with much faster computation. |
mikey Send message Joined: 17 Dec 99 Posts: 4215 Credit: 3,474,603 RAC: 0 |
> Does the size of the cpu l2 cache really improve the speeds of seti and other > projects? Iam looking at several AMD cpu's with either 1MG or 512K size > caches. Even though not much of a price difference, if the larger cache sizes > don't help then I don't need them. tia > The Seti client size is 384k so anything less than that means it won't all fit, which is why the Celeron, Duron and Sempron cpu's are sooo slow. From 512k up is more user choice. If you are still running Classic you can run multiple CLI's in each 512k, meaning that in the 1 meg you cited you could process 2 units at the same time. With Boinc that is not possible, YET! One never knows what Berkeley is going to come up with. Beyond Boinc...think of the L2 cache as an index of a book. The larger the L2 cache size the longer you get to look at it to find what you are looking for. Example...no L2 cache, no looking at the index, 128k L2 cache, look for a couple of seconds, 512k you get to look for a minute of so. BUT with a 1 meg or greater L2 cache you can look for just about as long as you wih to look. The computer stores info in the L2 cache about where the next thing you want to do with is stored, the larger the L2 cache the more it can store and the quicker it can get there. Info still might not be in the cache but over time your computer will "learn" what you do next and have a greater chance of storing it. It "learns" by defragging and putting most often used programs closer to the beginning of the drive. ie..closer together, more chance for the L2 cache to have it in its storage. |
Hans Dorn Send message Joined: 3 Apr 99 Posts: 2262 Credit: 26,448,570 RAC: 0 |
> Beyond Boinc...think of the L2 cache as an index of a book. Not quite :o) The L1 and L2 caches are made of fast RAM, about 8x faster than main memory, and contain copies of data from main memory. There is some indexing involved: The CPU has to remember which parts of the main memory are held in the cache ATM. The best cache size for seti would be anything from 2MB and up, since the large FFTs take up 1MB of RAM, and you need some room for auxilliary data and your code, too. Regards Hans |
Benher Send message Joined: 25 Jul 99 Posts: 517 Credit: 465,152 RAC: 0 |
Not to mention it works with blocks of up to 256,000 floating point numbers at a time, in a repeating manner (re-uses each number sevral times). Each floating number is 4 bytes long, so 4 x 256,000 = 1Meg. There are some other complicated items that L2 cache helps with as well. Interesting side note...the AMD 64 Bit CPUs combine the sizes of their L1 and L2 caches...what this means is, no value will be both in L1 and L2 at the same time. So if L1 is 32K and L2 is 1Meg, total cache size is 1024 + 32K. (Yes, L1 is still faster of course) |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
The theory behind this is that 10% of any given program is responsible for 90% of the execution time. So if you take a hypothetical "SETI" client, the code that handles loading and unloading work is called infrequently, but you want the whole FFT loop in the fastest cache. ... and given something data intensive like FFTs, you want the whole data-set in cache if at all possible. It's also good to have more cache if your machine is doing more than just crunching (as I do with mine). More cache is always better. |
Paul D. Buck Send message Joined: 19 Jul 00 Posts: 3898 Credit: 1,158,042 RAC: 0 |
The good news is that we are starting to see some chip carriers with L3 Cache ... The Power 5 for one... 4 dual cores on one chip ... yum - yum ... L2 cache shared with the 2-cores and is only 2M, but each owns its own 36M L3 cache. Oh, they also say that each core is multi-threaded... 2x2x4=16 logical CPUs ... oh my ... |
Jord Send message Joined: 9 Jun 99 Posts: 15184 Credit: 4,362,181 RAC: 3 |
> The Seti client size is 384k so anything less than that means it won't all > fit, which is why the Celeron, Duron and Sempron cpu's are sooo slow. Errm... L2 cache isn't used to store the actual client in. The level 2 cache works like this: If you have 512MB of RAM in your PC, yet your CPU only has 128KB of L2 cache, then the CPU will cache the first 128MB of RAM. Nothing more, nothing less. So if your CPU has 512KB of L2 cache, while you are using 1024MB of RAM, you are caching the first 512MB of RAM. Of course, if your actual RAM is lower than your L2 cache, all of your RAM is cached. By cached I mean, it'll make a case file of commands, pages, drive positions used, for the next time your CPU needs those. It's faster to get from L2 cache as that RAM is faster, then it is to get from actual RAM (or reload the numbers) BOINC/Seti sits in your RAM, not in your L2 cache of your CPU! |
mikey Send message Joined: 17 Dec 99 Posts: 4215 Credit: 3,474,603 RAC: 0 |
> > The Seti client size is 384k so anything less than that means it won't > all > > fit, which is why the Celeron, Duron and Sempron cpu's are sooo slow. > > Errm... L2 cache isn't used to store the actual client in. > > The level 2 cache works like this: > If you have 512MB of RAM in your PC, yet your CPU only has 128KB of L2 cache, > then the CPU will cache the first 128MB of RAM. Nothing more, nothing less. > > So if your CPU has 512KB of L2 cache, while you are using 1024MB of RAM, you > are caching the first 512MB of RAM. > > Of course, if your actual RAM is lower than your L2 cache, all of your RAM is > cached. > > By cached I mean, it'll make a case file of commands, pages, drive positions > used, for the next time your CPU needs those. It's faster to get from L2 cache > as that RAM is faster, then it is to get from actual RAM (or reload the > numbers) > > BOINC/Seti sits in your RAM, not in your L2 cache of your CPU! > I think you have mb and k intertwined too much! You are saying that if I have 512k of L2 cache that 512meg of ram can be cached in it! Not in this lifetime!! AND you CANNOT have less than your L2 cache level of ram for your machine! Windows WILL NOT run with only 512k of memory!!!! It REQUIRES MEGABYTES of memory, NOT just kilobytes! |
7822531 Send message Joined: 3 Apr 99 Posts: 820 Credit: 692 RAC: 0 |
I think he means like an index of main RAM's contents similarly to the way indexing works on databases. IIRC, cache is little more than a smart buffer between the CPU and the mobo RAM - smart enough to keep data that keeps called on, but dumb enough to try to predict what data the CPU will want ten cycles in advance. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13746 Credit: 208,696,464 RAC: 304 |
> Of course, if your actual RAM is lower than your L2 cache, all of your RAM is cached. Actually all x86 CPUs since (and including) the Pentium Pro have been able to cache 1GB of RAM or more. The Pentium CPUs were limited by the motherboard chipset as to how much RAM they could cache as it was all on the motherboard (The FX chipset could only cache 64MB of RAM, more RAM than that & your system would actually become slower. The HX chipset could cache upto 512MB of RAM once you added the Tag ram to it); the Pentium Pro/PentiumII & onward have the cache & tag RAM in the CPU package itself. Grant Darwin NT |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.