Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

Re: UIDE Unloading And Cache-Sizes. (Announce)

posted by marcov, 08.06.2010, 23:18

> > get discarded, when more new data arrives. Keeping DOS directories
> > "in cache" is the GREATEST advantage of using UIDE, as DOS otherwise
> > does only SLOW "designed in 1981" single-sector directory handling!
>
> The problem is that backends for GCC 3.4.4 (which I use there) are 3.5 MB
> unpacked. (Latest DJGPP GCC 4.4.2 is 8.5 MB for CC1.EXE, yikes.) The 2.04
> libc itself is 800k. And the assembler and linker (AS, LD) are also pretty
> big (800k, 600k). The internal Pentium cache is ridiculously small.
But only the working set size matters for cache, not the overall size. If you have a 99.99% hit ratio in 32k, it will work fine :-)

> Anyways, I just now tried a bit messing with GPC. Seems that the linking
> stage takes the longest, so copying the relevant libs to RAM disk and
> using -L. speeds it up more than UIDE /S15 did. Hence, I'll stick to /S5
> for now. (Plus I usually need the RAM for other stuff. And this is also
> why I like TDSK to be able to resize, as by default I use 5 MB for it
> too.)
This is some what strange. While I do directly understand that the ramdisk speeds up, I'm a bit surprised this is very noticable in the linking step.

> > Using a 5-MB cache, if you have no files larger than about 2-MB, you
> > can copy such files using 4-MB of cache (2 for input, 2 for output),
> > and you still have about 1-MB left for directories. When DOS wants
> > to copy another file or load a new program, it loses NO speed, since
> > the directories were not discarded due to too-much "new" cache data.
>
> Well, choice of software affects this, and you can indeed blame me for
> using either a "low RAM" cpu or bloated compiler or whatnot.

You forgot the most important part: choice of computers :-)

> I know TP55 and TMT are probably faster, but they aren't as good for some
> (most?) things.

Depends on what you do. For a quick calculation TP55 might be quite ok. (at least if it supports copro), but with serious programs, you get out of memory fast.

Anyway, TP and VP share the problem that they are unmaintained, something that I avoid for active development.

> Haven't benchmarked FPC on that clunker yet (have to pare it down
> first, been busy with other things). They always claim faster compilation,
> so it would be nice to see if that's true. ;-)
Its not so much the compilation as the integrated assembler/linker.

But contrary to other systems, I assume DJGPP might have had a lot of dos-specific work done to mitigate the standard naieve approach of the GNU toolchain, so it might not be so prominent on Dos.

Note that that is fast compared to GCC/GPC, not to the rest.

Lastely there is the 300 pound gorilla, the delphi commandline compiler with wdosx, generating wdosx apps.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22781 Postings in 2123 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum