evans@syd.dit.CSIRO.AU (Bruce.Evans) (05/15/91)
djgcc uses the "vdisk method" for cooperative access to extended memory. I have not found a disk cache that uses this method (I only tried smartdrv and hyperdisk). djgcc is very slow without extended memory (it swaps all the time) and fairly slow without a cache in 7MB extended memory (it accesses the disk a lot). What disk caches use the vdisk method? -- Bruce Evans evans@syd.dit.csiro.au
dj@ctron.com (DJ Delorie) (05/16/91)
In article <1991May15.150542.24705@syd.dit.CSIRO.AU>, evans@syd.dit.CSIRO.AU (Bruce.Evans) writes: > djgcc uses the "vdisk method" for cooperative access to extended > memory. I have not found a disk cache that uses this method (I > only tried smartdrv and hyperdisk). djgcc is very slow without > extended memory (it swaps all the time) and fairly slow without > a cache in 7MB extended memory (it accesses the disk a lot). > What disk caches use the vdisk method? I don't "use" the VDISK method - I "allow" it. If VDISK is installed, I'll avoid using that memory. I also check int 15h and XMS to see where else memory might be used. After all this, whatever is left is MINE. If XMS is installed, I'll register with it that I'm taking the memory. I use Super PC-Kwik for a disk cache, but I've used SmartDrive. You just have to tell them to not use all the extended memory. I find that 1.5M of extended memory free, and the rest for cache, leaves enough for most compiles and runs. If you use PC-Kwik, don't use the Q option, as it can't handle the protected mode interrupt latency. DJ (author of go32) dj@ctron.com
zuazaga@ucunix.san.uc.edu (Humberto Oritz-Zuazaga) (05/16/91)
In article <1991May15.150542.24705@syd.dit.CSIRO.AU> evans@syd.dit.CSIRO.AU (Bruce.Evans) writes: >only tried smartdrv and hyperdisk). djgcc is very slow without >extended memory (it swaps all the time) and fairly slow without >a cache in 7MB extended memory (it accesses the disk a lot). Try setting TMP as a ramdisk. With 7megs of memory, you should have room to spare. Failing that, I'd try putting the compiler passes in a ramdisk (the passes are 500k and 700k). But I'm running on a 20MHz 386SX with 4meg and I don't find it that slow. P.S. What am I supposed to do with those long attribution lines, wrap them or send them out >80 columns? -- Humberto Ortiz-Zuazaga University of Cincinnati Physiology & Biophysics zuazaga@ucunix.san.uc.edu Cincinnati OH 45267-0576
evans@syd.dit.CSIRO.AU (Bruce.Evans) (05/17/91)
In article <1502@balrog.ctron.com> dj@ctron.com writes: >I use Super PC-Kwik for a disk cache, but I've used SmartDrive. You >just have to tell them to not use all the extended memory. I find My mistake was attempting to use the smartdrv.sys that came with windows instead of the one with DOS 4. The windows one requires himem.sys or some other extended or expanded memory driver. himem.sys is not compatible with djgcc. -- Bruce Evans evans@syd.dit.csiro.au
dj@ctron.com (DJ Delorie) (05/17/91)
In article <1991May17.113928.27055@syd.dit.CSIRO.AU>, evans@syd.dit.CSIRO.AU (Bruce.Evans) writes: > > In article <1502@balrog.ctron.com> dj@ctron.com writes: > >I use Super PC-Kwik for a disk cache, but I've used SmartDrive. You > >just have to tell them to not use all the extended memory. I find > > My mistake was attempting to use the smartdrv.sys that came with windows > instead of the one with DOS 4. The windows one requires himem.sys or some > other extended or expanded memory driver. himem.sys is not compatible with > djgcc. djgcc *is* compatible with himem.sys, as long as you have the XMS version of himem.sys, and tell smartdrive not to use all of the XMS memory! You might have an old (pre-XMS) version of djgcc also. BTW: I changed the name to "djgpp" to indicate that it has C++ in it as well. DJ dj@ctron.com
evans@syd.dit.CSIRO.AU (Bruce.Evans) (05/19/91)
In article <1506@balrog.ctron.com> dj@ctron.com writes: >djgcc *is* compatible with himem.sys, as long as you have the XMS >version of himem.sys, and tell smartdrive not to use all of the XMS >memory! You might have an old (pre-XMS) version of djgcc also. I tried himem.sys again and found it does work, but only with the old smartdrv.sys. The exact versions are himem.sys 2.04 from DOS 4.01 (not tried) himem.sys 2.60 from Windows 3.0 (works) smartdrv.sys 2.10 from DOS 4.01 (works) smartdrv.sys 3.03 from Windows 4.01 (doesn't work) 'device=\win\smartdrv.sys 3072 1024' makes 7168K extended memory invisible to djgpp though it only gives a 3072K cache. DOS's mem command reports 7168K is in use. However, td386 (Turbo debugger) uses the missing memory. hyperdisk with himem 2.60 leaves plenty of extended memory for djgpp too. However, it did not work when I tried it last week - maybe the order of installation of the drivers is important. With smartdrv, the write-through cache resulted in a lot of sluggish disk activity from djgpp. This is easy to fix for small compiles by using a RAM isk for gcctmp. However, for large compiles (and large 32-bit programs), at best the RAM disk will use memory better given to the program. At worse the program will swap to the RAM disk (duh). This seems to always happen now. Am I messing some swaptmp variable in TFM? -- Bruce Evans evans@syd.dit.csiro.au