Hi, On Sun, Apr 8, 2012 at 12:44 PM, Michael B. Brutman <mbbrut...@brutman.com> wrote: > On 4/3/2012 1:18 AM, Michael Robinson wrote: >> There is a syntax error message that flashes before the where to install >> freedos to and from menu comes up. Another problem, install freezes at >> installing command.com. Uge! > > Are you installing on old hardware or in a virtual machine? > > Some of us figured out that on ancient hardware (8088, 80286, etc.) the > decompression process takes a long time. If you are running in a > virtual machine and your underlying hardware/operating system does not > fully support virtualization then you are emulating the machine > instruction by instruction, and that can take forever too.
I don't know if it's strictly "instruction by instruction", but it's certainly slow. Though I thought VirtualBox had a JIT, but I can't tell where or when. (Old QEMU used to support KQEMU driver, but that's long been deprecated, presumably in lieu of whatever, KVM, Xen, I have no idea ....) > My 2009 vintage Intel quad-core supports virtualzation well so I have > very little instruction emulation. But a user with a newer Atom tried > it and noticed the horrible slowdown. Apparently the Atom isn't fully > capable of virtualization so QEMU was resorting to emulating each > instruction, and that is very slow. Not all computers support virtualization. It's sad, really, as it's really quite painful without it (though bugs are a bigger showstopper, even patience can't fix that). Well, how would you benchmark such a thing anyways? Aren't all benchmarks arbitrary and pointless? Well, here goes nothing! ;-) VirtualBox 4.1.8 (though latest is 4.1.12) 64-bit atop Win7 Home Premium SP1 64-bit Core i5 650 3.2 Ghz 32nm with Turbo Boost, SSE4.2, Nehalem VT-X, 6 GB RAM (I don't know if any of that matters, I didn't enable anything special, just trying to be explicit here "just in case".) I know I know, my own personal benchmark is really lame, but it's better than nothing (in a pinch). It's stuffed in here: https://sites.google.com/site/rugxulo/BEFI_3I.ZIP?attredirects=0 Basically it counts down from zero (by 100) until wrapping over into signed int32_t positive area and then stops and prints its value. Very lame and useless, but so are most benchmarks. I booted up FreeDOS in the VM (kernel 2040, FreeCOM 0.84-pre2 XMS_Swap) in clean mode via F5, so nothing else was loaded. No runtime.com found (Bernd??), so I had to use my own timeit.rex script with Regina. This was interesting as, for simplicity (eh? heheh) I used WDOSX 0.97's STUBIT on a copy of REGINA.EXE (3.5, default DJGPP build) and used WDOSX's WDMEM to limit the RAM to 0x4FFF000 so that it would permit shelling out. (That number was arbitrary, probably should've set it much lower, but the VM has 512 MB of RAM allocated.) The three tools I'm testing are: BEF93TP.EXE (Turbo Pascal 5.5, 8086), BEFI.COM (pure assembly, 16-bit real mode with 386 instructions using prefix), BEF93W32.EXE (Virtual Pascal, Win32 console, used "upx -d --strip-relocs=0" then STUBIT from above). So I figured that was a good mix of instructions and modes so that it might test better than just one alone. (VT-X and nested paging are enabled) for %a in (bef93tp befi bef93w32) do regina timeit.rex %a bench2.bef (save timeit.log, shut down VM, disable VT-X and nested paging, try again) Here are the results: (VT-X and nested paging): bef93tp bench2.bef Elapsed: 112.71 seconds. befi bench2.bef Elapsed: 3.57 seconds. bef93w32 bench2.bef Elapsed: 17.03 seconds. (normal VirtualBox emulation): bef93tp bench2.bef Elapsed: 972.29 seconds. befi bench2.bef Elapsed: 87.33 seconds. bef93w32 bench2.bef Elapsed: 162.91 seconds. So VT-X is 8.6 times faster (16-bit), 24.4 times faster (mostly 16-bit with some 32-bit pieces), and 9.5 times faster (32-bit). But maybe I threw it for a loop with some weird use of a FS: segreg as scratch register (optimized asm version for small size only). Oh, and that version still uses some self-modifying code, so you know that probably hurts too. But it still wins overall here (no surprise, it's ultra lean). P.S. Bernd, if unpacking COMMAND.COM is the real bottleneck that puts everybody off, perhaps you should compress it with LHA? At least that (IIRC) shows progress info when decompressing (and I can't seem to find any "obvious" similar feature for Info-Zip's UNZIP 6.00, though I know ZIP 3.0 has it; guess somebody could eventually hack it to work, heh). ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
