DOS ain't dead - Assembler optimisation

Assembler optimisation - speed, size, etc (Developers)

posted by ecm , Düsseldorf, Germany, 16.05.2012, 16:59

> Size matters A LOT, especially when you are dealing with DOS programs, and
> even more when you are dealing with TSR's. To me, this is not necessarily
> the size of the executable program file itself, but the amount of memory it
> ultimately requires.

So actually we could draw a distinction between "executable size on disk" and "process size in memory". The latter can even, if applicable, further be split into "transient memory usage" and "resident memory usage".

Speaking of which, I'm just now writing an experimental program where I expect the core loop's speed might noticeably affect "user" experience, so to say. Hence, while I could have optimised it for size as usual, I instead put most of that loop into a macro and then use that to write several different variants of the loop code to be used in various circumstances. (For example, the default pair of the loop's variants only handles continuous single file regions up to 8 KiB. In 99% of usage cases, that will suffice, but I added an alternative pair that is able to handle regions up to 512 MiB instead - this is only executed when needed.) This program only ever executes its code in a transient/"foreground" process, so a bit of "wasted" code size isn't very relevant.

> In most
> (but not all) situations, speed is a relatively minor concern.

I'd say the speed of most code generally is rather unimportant. To improve timing, one should focus on the parts of their code that the program actually spends a lot of time in. Putting a lot of effort into optimising all of a program's code for speed is unnecessary.

> Even then,
> though, the speed issues don't usually involve specific CPU instructions,
> but more a "philosophy" of how to write the program (e.g., minimizing the
> number of switches between PM and V86/RM).

True. Just recently, I noticed that a program I was using/developing employed a rather suboptimal algorithm for table lookup. It wasn't a critical problem (at least not on modern CPUs), it just wasn't designed very well. Purely for amusement, I set up a sort of benchmark for the affected algorithm, and determined that my (very simplistic) improvement consistently sped that section up by more than ten times.

---
l

Post reply

Complete thread:

Assembler optimalisation - how to avoid a jump? - Laaca, 13.05.2012, 20:38 (Developers)
- Assembler optimalisation - how to avoid a jump? - Rugxulo, 13.05.2012, 21:10
  - Assembler optimalisation - how to avoid a jump? - Laaca, 13.05.2012, 22:15
    - Assembler optimalisation - how to avoid a jump? - marcov, 13.05.2012, 23:22
- Assembler optimisation - how to avoid a jump? - ecm, 13.05.2012, 23:32
  - Assembler optimisation - how to avoid a jump? - Laaca, 14.05.2012, 18:15
    - Assembler optimisation - variant 3, sbb - ecm, 14.05.2012, 18:22
    - Assembler optimisation - how to avoid a jump? - Rugxulo, 16.05.2012, 10:34
      - Assembler optimisation - how to avoid a jump? - bretjohn, 16.05.2012, 16:42
        Assembler optimisation - speed, size, etc - ecm, 16.05.2012, 16:59