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 Rugxulo Homepage, Usono, 09.06.2010, 04:23

>
> 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 :-)
I would bet that most software, even so-called 586-optimized, has lots of cache misses and unpaired instructions. I need to test more (e.g. VP21, which only goes up to 586, oddly enough.)

> > Anyways, I just now tried a bit messing with GPC. Seems that the
> linking stage takes the longest
>
> 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.
Well, you once told me a horror story about GNU ld, so you can't be that surprised. Maybe I'll swap to 2.16.1 temporarily and use HDPMI32.

> > 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 :-)
Benchmarking only on newer computers is fine, but it doesn't give you the full picture.

> > 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.

I originally didn't care about TP at all, but since it exists and I can test it, I tried. It works there too, so I'm happy. I don't need much RAM here (Befunge93). Plus I can (maybe) tell Trixter to test it on his 8088! ;-)

> Anyway, TP and VP share the problem that they are unmaintained, something
> that I avoid for active development.
More important is bugs (TMT -> EDGETEST.BEF) or lack of OS support to actually run them (Win64)! (VP21 has a leg up there.)

> > 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 there is no integrated linker for DOS FPC (despite being a variant of COFF), and LD 2.19 isn't supported in 2.4.0 (bug, "already fixed").

> 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.
It only has to be reasonable, not blisteringly fast. I don't think most people try one-pass compilation anymore. It would matter more on a 486 or with a big project.

> Lastely there is the 300 pound gorilla, the delphi commandline compiler
> with wdosx, generating wdosx apps.
I don't have any Delphi, though, so I can't test. Besides, to be honest, WDOSX works well, but it has some compatibility issues.

---
Know your limits.h

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