Hi,
On Friday, September 12, 2014 5:12:27 AM UTC-5, Alexei A. Frounze wrote:
>
> I've just implemented extension checking in system() (and started
> supplying ".exe" in the commands passed to my system()) and I'm
> running self-compiled DOS versions of my compiler under DosBox
> and smlrcc invokes NASM, which, as you probably know, is distributed
> as a DJGPP DPMI binary for DOS, and everything seems to work. The
> only problem is that NASM is tremendously slow under DosBox.
Everything is slow under DOSBox. It's not fast. It's full software
emulation. It's a "fast" 486, at best (on a 1 Ghz host machine).
It's not really meant for anything besides games. You'd get better
results testing elsewhere, obviously. But I don't know what host
OS you're using or what you would prefer (VirtualBox with VT-X,
NTVDM, native FreeDOS via RUFUS USB, QEMU, etc).
You could probably tweak/clone the dosbox.conf (core=dynamic) and/or
up the cycles, up the frameskip, or try a third-party build (or
even a newer MSVC build, allegedly faster). It's not totally
impossible, but honestly I never do any of that, so I'm probably
not the one to be giving much advice here. :-)
> Heck, under Windows it isn't blazingly fast either.
Back in the day, when I still used NTVDM (before I gave up due to
billions of bugs), it was discovered that a UPX'd DJGPP binary
was twice (or more) as slow than a non-UPX'd binary. You could
try decompressing it (upx -d), and see if that helps.
> I'm suspecting the relative jump optimization needs algorithmic
> improvement. And there may be something else. But that's just
> a speculation. I haven't looked into it.
You mean -Ox? That's been default turned on for a few years now
(apparently since 2.09, according to the online doc). It used to
be optional (unlike YASM or FASM). You can disable that, of
course (-O0), even via %NASMENV% environment variable. Somehow
I don't think this is your problem, but who knows. For me, it
was never noticeable except on really old machines. But
some things make it more obvious than others. (I never messed
with ZSNES, but I vaguely recall that they claimed it exposed
something ridiculous that made it painfully slow. Dunno the
details, you'd have to ask Frank Kotler.)