Hi, On Wed, Jul 22, 2026 at 1:58 PM Bernd Boeckmann via Freedos-devel <[email protected]> wrote: > > > Am 21.07.2026 um 19:47 schrieb Jim Hall via Freedos-devel > > <[email protected]>: > > Watcom performs significantly worse than even Turbo C++ on 386 and 486. That > is not something I expected. > > Also: 286 and 386 are both ~4 times as fast per clock cycle than the 8088, > and the 486 is even ~10 times as fast > per clock cycle than the 8088, and >2 times than the 386.
There's cpu-specific optimizations, compiler-specific optimizations, OS-specific optimizations, API-specific optimizations, and then just general optimizations that are applicable everywhere (e.g. don't DIV if you can SHR instead). But it's hard to prove or utilize specific optimizations because old hardware (and/or compilers or OSes) is less prevalent these days. Everyone seems to just use whatever GCC is on latest Ubuntu LTS. Basically, they're chasing newer standards (at best, if any ... C23 or GNU23 + POSIX 2024) or just using whatever they have available. (Last I heard, Linux requires GCC 8+.) They are not worried about ANSI C on a 286 running FreeDOS. Blended optimizations are when you can target (e.g.) both 386 and 486 at the same time in the same binary. You do things that don't negatively affect either one. GCC (e.g. DJGPP) never did any specific 486 optimizations besides adding alignment. That's because the 486 was *very* sensitive to aligned code and data (but the Pentium less so). Nowadays newer GCCs enable -finline-functions even at -Os and -O2. (-Oz doesn't seem to do much, but on Clang it's quite a savings.) Normally -O3 is where -funroll-loops and -finline-functions is enabled by default, but that breaks some programs, so most people stick to good ol' reliable -O2 for releases. OpenWatcom has switches -3 -4 -5 -6 , but AFAIK those never emit anything past 386, just reschedule things to be slightly more comfortable. (Here I specifically mean 32-bit code from wcc386. The 16-bit compiler, wcc, will probably emit some bit of 386 code if you use -3.) IIRC, the 8086 didn't have an ALU, so the 286 sped up code A LOT compared to older cpus. You'd have to ask an expert like Jim Leonard, but the 8086 was slow at [bx+di+2] effective addresses. Code should be kept simple, small, and avoid unnecessary jumps. Even the 386 (with no hardware cpu cache) preferred small, tight code. The 486, however, was pipelined and preferred simpler RISC-y code. But the 486 was also twice as fast as the 386 at the same clock speed. The fastest 386 instruction was 2 cycles while the 486 could run many instructions in 1 cycle. And the 486 often (but not always) came with an FPU. By the time the Pentium (aka 586) came along, it was superscalar (and mandatory pipelined FPU) with U and (weaker) V pipes for faster thoroughput, which means it could do more at once (if scheduled properly). GCC 2.8.1 did add -mpentium support. In short, optimization is an ongoing quest. You start with something, benchmark it, then keep retesting until you stop. Just because you give up doesn't mean there isn't a better, faster way. If you're truly interested in 8086 speed improvements, I would keep digging. Otherwise, it may not be a good way to spend your free time (unless you're just ultra curious). As shown, newer cpus are probably "good enough". But there's always room for improvement _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
