The original design of the daase files was from the VMLisp version. They are random access files. You get a location from the index and perform a disk seek. With electronic storage this is no longer relevant but still exists.
The current design was my work, a result of the effort to put Scratchpad on a 640k computer running DOS. Compress.daase was added to ensure that the daase files could fit on individual floppy disks. This is also no longer relevant. Unlike the other daase files, the compress.daase file could be deleted with a single update. I pushed out as much algebra as possible and created the 'getdatabase' API to give uniform, single location access. It would make sense to simply put all of the algebra inline and remove the daase files. The decisions that created them are based on hardware constraints that no longer exist. The whole idea of a 'database' for algebra is not necessary. Maintaining such a structure is unnecessary overhead. Tim On Thursday, December 7, 2023 at 7:00:59 PM UTC-5 oldk1331 wrote: > I think current design comes from over 30 years ago, where system has > only a few MB memory in total. > > - Qian > > On 12/8/23 07:50, Hill Strong wrote: > > If the daase is so small that it only takes 23 Mbytes to load into > memory, > > it would be worth it if it took 100 Mbytes to load into memory. How many > of > > our machines would be constrained by this? My current machine is old and > it > > has 7.7 Gbytes usable. It is nothing special - a stock standard HP > laptop. > > > > The question to ask is: why has this not been done sooner? > > > > regards to all > > > > Hill Strong. > > > > On Fri, Dec 8, 2023 at 1:45 AM Qian Yun <oldk...@gmail.com> wrote: > > > >> I did some experiments on putting daase into memory instead of disk. > >> > >> For the 8.5MB interp.daase, load it into memory takes 23MB: > >> > >> (sb-ext:gc) > >> (room) ;; Dynamic space usage is: 19,602,224 bytes. > >> (setq l1 '()) > >> (with-open-file (s "interp.daase") > >> (do ((item (read s nil 'eof) (read s nil 'eof))) > >> ((eq item 'eof)) > >> (setq l1 (cons item l1)))) > >> (sb-ext:gc) > >> (room) ;; Dynamic space usage is: 42,911,520 bytes. > >> > >> The number is reasonable: viewing l1 as a tree, it has 1.4 million > >> leaves (which are symbol or number), and requires 1.4 million cons > >> cells, and each takes a machine word -- 64 bits so: > >> 1.4 million x 2 x 8 bytes = 22.4 MB > >> > >> Of course, if we want all of database in memory, why not put > >> it directly in the various hash tables? I have not tested how > >> much memory this would require, should be much less than 23 MB. > >> > >> Bzip2 compress interp.daase gives 504K, that's also reasonable > >> considering there's so much duplicated sub-expressions in it. > >> > >> So I wonder does in memory daase (then dump to disk image) have > >> advantages over current external text daase? > >> > >> Or consider a crazier thing: load everything into memory (image) > >> and distribute FriCAS as a single executable! It actually can > >> be a good idea for Windows. > >> > >> A rough test using fricas0 shows that loading the 1383 algebra > >> fasl files (39MB) into memory takes 26MB RAM, interp/ takes 13MB. > >> > >> - Qian > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "FriCAS - computer algebra system" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to fricas-devel...@googlegroups.com. > >> To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/fricas-devel/2e092244-2c7a-4f8c-b16b-d60c78c686fd%40gmail.com > >> . > >> > > > -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/b60a902d-254c-4dfe-9b49-a15d3da706f2n%40googlegroups.com.
