On Sun, 1 Dec 2002, Gary Miller wrote: > On Sun 12/1 Stephen Reed wrote: > > "because the Cyc KB is currently memory resident we cannot contain the > full Cyc KB in Win32" > > Stephen I believe this to be a an architectural design problem > regardless of whether you are on Linux or Windows.
I meant to say virtual memory resident. So the headroom limit for Cyc today is the amount of virtual memory that the OS gives to a process. For Linux-32 we find the limit to be 3 GB. For Win32 we find the limit to be 2 GB. > > Both operating systems have the capability of virtual memory to swap out > the least recently used seqments in memory. Agreed. > In Windows for instance if you made your knowledge base a memory mapped > file, at run time it would all be loaded into memory if there was room > and the least frequently used segments could be swapped out. Agreed. On both Linux and Win32, Cyc's KB is a memory mapped file. > In your current architecture you may not hit your head on the memory > ceiling as soon but you will eventually hit it. We are over the 2 GB limit now on Win32 and are now thinking about when the 3 GB limit on Linux-32 will be reached. > A good architecture should allow your most frequently accessed knowledge > to stay resident while infrequently or hardly accessed knowledge remain > on disk or virtual memory. This would allow your application to run on > machines with much smaller amounts of memory but at a performance > penalty. We already use virtual memory and are have a preliminary design for a backing store that extends the knowledge base (KB) to disk under our control - not using the OS paging system. > Another approach would be to store knowledge in a relational database. > These system also cache and manage the tabel data the first time it is > read. If it is frequently accessed it will stay in cache and be > accessed and memory speeds. Most RDBMS have superior indexing and will > retrieve records much faster from cache than a linear search of memory. We do this now read-only and call it Semantic Knowledge Source Integration (SKSI). We treat columns in an RDB as logical sentences with the table name being the relationship (predicate) of each sentence. This is a tedious special case of the disk backing store that ultimately will be a better solution for Cyc's expected growth. > If your actual application is written in Java vs. a true compiled > language you are also incurring a large performance penalty. In my > experience there is no such thing as fast Java. When all of the ERP > system vendors switched from client server to web based Java interfaces > all their response times went in the toilet. And with all of the R&D > dollars Oracle has, if they can't make it run fast nobody can. > Larry Ellison bet the ranch on the thin-client being the wave of the > future. So far all he has are a lot of dissatified customers! Some of our applications are java and our java API is open-source at SourceForge, but our object store, indexing, garbage collection, compiled (via translation to C) lisp, and lisp interpreter are all highly optimized C objects for the Cyc KB and we know that a rewrite to java would result in a much larger memory footprint and slower run times. The java application code we do use is slow but the time consumed in our applications is primarily within Cyc inference so we use java for all its well known benefits. My dream is that someday Cyc will be able to reason about its own behavior as UML state machines and then supercompile (drive the state machine) into optimal machine code for the expected 64-bit CPUs. I have a UML state machine interpreter working now in java and can represent all the UML objects as Cyc assertions. -Steve > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > Behalf Of Stephen Reed > Sent: Sunday, December 01, 2002 12:19 AM > To: [EMAIL PROTECTED] > Subject: RE: [agi] An idea for promoting AI development. > > > > On 30 Nov 2002, James Rogers wrote: > > > On Fri, 2002-11-29 at 19:38, John Rose wrote: > > > But if I were building > > > a new PC-based AI design, just from my experience, I would jump all > > > over Windows and it's offerings ... as well take a side glance at > > > Lindows :) > > At Cycorp, we switched from Symbolics Lisp Machines to Linux three years > ago, and although we have a port of the Cyc knowledge base for Win32 we > are now blocked by the memory model of Win32 which reserves 2GB of > virtual memory for the OS. Linux reserves only 1 GB and because the Cyc > KB is currently memory resident we cannot contain the full Cyc KB in > Win32 (max user address space is 2 GB) but we can contain the full Cyc > KB in Linux (max user address space is 3GB). > > Another problem with Win32 is price/behavior between > desktop Win32 and Server Win32. In desktop Win32, the bias is towards > fast Office application launch time and you will find server > applications suffering in that memory paging occurs even if sufficient > RAM exists. The Win32 server OS is much more expensive and still does > not completely solve this performance problem. > > The main problem with Win32 is the total cost of ownership issue, when > you multiply the total number of computers (desktops, laptops, servers, > work-at-home computers) by the cost of Win32 server + MS Visual Studio, > which must be upgraded every two-three years -- Compared to Linux in > which upgrades are free and most required software is free. > > Of course some individuals may find Linux difficult to install for a > particular computer, but Cycorp has sysadmins to overcome that problem > and we purchase "white box" high performance computers with Linux > installed to our specs. > > At Cycorp we put Win32 on the slowest, oldest computers (for > non-technical tasks) and are still running Windows NT on most of those. > We put Linux on the majority of our fast AMD boxes which run the Cyc KB > best. The Cyc KB uses HTML as its interface so we do not get value from > the Windows desktop, and we use java as the main interface language. > > I have Win2K and WinXP at home on two computers and Linux on my faster > home servers. I expect that some year I will retire Win32 and convert > mainly to Linux-64 at the rate at which Linux is improving. > > -Steve > > > -- =========================================================== Stephen L. Reed phone: 512.342.4036 Cycorp, Suite 100 fax: 512.342.4040 3721 Executive Center Drive email: [EMAIL PROTECTED] Austin, TX 78731 web: http://www.cyc.com download OpenCyc at http://www.opencyc.org =========================================================== ------- To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?[EMAIL PROTECTED]
