I'm not sure if this code even uses the x87 opcodes or software emulation for the floats!

First of all, the source defines a "FloatType", which is set to "Real". But the real type is a 6-byte float type optimised for software floating point routines! I'd like to see the results when using the "Single" and "Double" types.

Also, it's easy to forget that x87 code generation in TP3 is an option that defaults to "don't".

There's a bullet point in the TP3 section where the author's saying:

  I used TURBO-87.COM to compile the code with floating point 
  support (no doubles, just single precision) to SMALLPT.COM

(There's also a subroutine in the .com file which starts with an fninit instruction. :)

I rememeber that TurboBASIC (Borland's clone of QBasic), could use x87 math. And it was using a TurboC like IDE

I'm not arguing TP3 couldn't produce x87 opcodes - I'm wondering if the author remembered to properly tell it to do so!

If you like something like DOSbox but with better performance (near native, perhaps ?) you should have try DOSEmu.

Really, the difference of speed and performance is abysmal.

https://en.wikipedia.org/wiki/DOSEMU

Except DOSEMU is Linux-only, whereas DOSbox is portable.

Well, works at very low level stuff, do real virtualization, instead emulating. The most similar stuff is using VirtualBox or KVM.

DOSemu was really joy to use for gaming even on Linux+486 + 10 Megs of ram. Oh those were the days :>

I remember them fondly. 10 MB RAM, though? What kind of high roller were you?! ;)

Hehee, my dad ended up buying some demo/test machine from AST in 92 or so. The comp had quite high end specs for it's time. It actually ran really fine for long time because of switching to Linux. Stopped using it in 1998. Probably could still remember all the IO, DMA, IRQ settings for hardware ^___^

I am a bit surprised by the bad performances of TP3. I remember that it was difficult to beat the compiler by using hand written assembly. Recent compilers may be far better than I imagined.

The TP compilers were pretty bad, all the way up to TP7. I (tried to) write a clone of Wolfenstein back in the day and the only way I could get close to the performance of the real Wolf3D was by replacing the inner loop by raw x86.

I even still have the source (keep in mind this was written ~20 years ago):

https://grack.com/code/legacy/deathmatch3d/

IIRC the TP3 compiler was very fast because it didn't optimise much. Compilers at the time were far easier to beat with Asm than ones today.

Also, as this is highly parallelisable problem, autovectorisation with SIMD instructions will produce huge performance boosts.

Compilers have been always pretty easy to beat. IIRC, Turbo Pascal time inline assembler could beat the compiler in tight loops 3-10x pretty easily. In things like sprite engines and texture mapping.

At the time, even C/C++ compilers had little memory available to perform any meaningful optimization. GCC on UNIX, for example, had optimizations that would be unthinkable for C compilers running on DOS. Microsoft was the first to invest in better optimization for Windows, and since then TC++ was left in the dust.

Hilarious, and a good remedy for my surprisingly frequent nostalgia for Turbo Pascal.