I am packaging the latest Win32 candidate tonignt. When I return home I will perform a trial install on my home Win2K box. If all goes well then I expect that we will upload OpenCyc release 0.7 for Linux and Win32 this week to SourceForge. I still have a KB conversion utility to write and test.
-Steve On Sun, 1 Dec 2002, maitri wrote: > Steve, > > Sounds like some good stuff you are working on with Cyc... > > Do you have any dates for the availablility of the OpenCyc Win 32 version??? > > Kevin > > ----- Original Message ----- > From: "Stephen Reed" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, December 01, 2002 6:30 PM > Subject: RE: [agi] An idea for promoting AI development. > > > > 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] > > > > > ------- > To unsubscribe, change your address, or temporarily deactivate your subscription, > please go to http://v2.listbox.com/member/?[EMAIL PROTECTED] > -- =========================================================== 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]
