Author: Matt Taylor
Date: 19:27:24 12/31/02
Go up one level in this thread
On December 31, 2002 at 21:05:55, Bob Durrett wrote: >On December 31, 2002 at 20:30:43, Matt Taylor wrote: > >>On December 31, 2002 at 19:44:51, Bob Durrett wrote: >> >>>On December 31, 2002 at 18:40:13, Dan Andersson wrote: >>> >>>>There are a few tricks available before we need use future tech. The caches can >>>>be made more efficient by using assymetric mappings. And caching on ram and in >>>>the memory controllers are relatively unused. >>>> >>>>MvH Dan Andersson >>> >>>That sounds really good! At the risk of getting an answer I will not >>>understand, let me ask anyway: How would current chess engine code be changed >>>to take advantage of: >>> >>>(a) asymmetric mappings, >>> >>>(b) caching on ram, and >>> >>>(c) caching in the memory controllers? >>> >>>You may wish to address this to the computer programmers, since THEY will be the >>>ones who will write the new chess engine code. [i.e. use "pseudo code," >>>etceteras] >> >>Caching is invisible to software. The operating system usually doesn't worry >>about the cache, though in some rare cases it needs to. > >Well, others here have already confirmed that there would be a HUGE gain in >chess engine performance if the chess engine and its hash tables could be loaded >into a very large cache. > >I don't understand the comment about the operating system. : ( The operating system has to be involved in the guts of the machine. The operating system can flush the caches, but usually it doesn't need to. The point is that caching is nearly invisible to all software, not just application code. While it would be a nice gain if the hash tables could be loaded into a cache, you're going to need a hefty cache for some of the tables. My preference would be to alleviate DRAM latency with a large amount of SRAM. You will still need long traces and suffer penalties for it, but they will not be as high. (The extra space, heat, cost, and other factors complicate the practicality of such a scheme.) >I thought that typical guru chess programmers ALWAYS find ways to take advantage >of the special features of the processors and other hardware. The operating >system is merely there to make life easier for the programmer! The guru >programmer will NOT ALLOW himself or herself to be restricted by the operating >system. The operating system is merely a servant of the programmer, not visa >versa. The same applies to compilers. [Who is in charge???] This is very true, though the purpose of an operating system isn't necessarily to provide access to the special hardware features. The purpose of an operating system is to manage hardware resources (ram, cpu time, I/O devices) so that programs don't trample each other. The accessibility of a feature has a lot to do with the usefulness of that feature to an application programmer. The only control that the programmer has over the cache is the ability to hint to the CPU that a particular piece of memory should be cached, and that is only useful if you know ahead-of-time what you're going to need. The scheme works well if your data is sequential in memory, but it doesn't help as much when you randomly access data -- you have to insert some sort of useful work between computation of the memory address and access of its data. It takes a relatively long time to load memory. -Matt
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.