CompuServe Messages

Scott, we're WAY behind on our Compuserve reading here, so I just now saw your message from November 26. Perhaps others have already answered your question better than I can, but here are my comments: Windows no. !OS/2 si! Why? 3DSr3 or "r4" (r3.5) running under OS/2 2.11 (I haven't tried Warp 3 yet) can, under the right circumstances, render FASTER than under DOS! How can this be, when under DOS the program has nearly 100% of the CPU's attention and it must by definition have less than that under OS/2? Two reasons: virtualization and full 32-bit DPMI swapping! To run in extended memory and protected mode under DOS 3DS must resort to the Phar Lap 386|DOS-Extender, a library developers use to allow 286 and 386 protected mode programs to work under DOS (to the best of my knowledge, there are no special 486 or Pentium protected modes, just a few extra instructions and registers and faster overall operation). Phar Lap can use any form of extended memory and protected mode access, including EMS, XMS, DPMI, and VCPI. DPMI in particular not only allows a DOS program to access extended memory, but to actually run in protected mode and still access real-mode MS-DOS services (INT 21 DOS calls, etc.). When a program such as 3DS needs more memory than your computer has physically, Phar Lap automatically "swaps out" the least recently used blocks of memory to a hard drive (your "swapdir") and frees up the RAM that was being used by those blocks of data. When 3DS needs to access the memory that was swapped out, Phar Lap swaps them back in and swaps something else out to make room. This works fine, but it takes time since even the fastest hard drives are WWWAAAAAAAAYYY slower than even the slowest RAM! Moreover, when Phar Lap has to do its swapping, it has to call DOS to do the actual reading and writing (otherwise it would have to concern itself with just what kind of hard drive and controller you have, and how to access it on the low levels, and how the drive is partitioned, etc. Notice that when you configure 3DS, nowhere does it ask you any of that stuff. It doesn't CARE! It let's DOS handle that stuff! That's what operating systems are FOR!!) Since DOS is running in real mode and the application Phar Lap is mediating (in this case, 3DS) is running in the protected mode, the CPU has to switch from protected mode to real mode, then call DOS to read or write the blocks needed to do part of the swap, then switch BACK to protected mode, and so on and so on. This takes time since mode switches involve a LOT of CPU overhead. Furthermore, since the data that is being swapped is in extended memory, Phar Lap has to map or buffer it into real memory, and that ALSO takes time. All of this is why 3DS rendering slows to a crawl when you try to render a project that needs more memory than you have. As soon as you see "Swap: " show anything other than "Swap: 0" in the rendering status line, you can count on the rendering taking many times longer than it otherwise would have. And the bigger the "Swap: " number and the more the "Page Faults" (number of times swapping had to be done) in the 3DS System Status, the slower it gets. Enter OS/2. Now, 3DS is not an OS/2 program, so OS/2 can't do as much for it as it could for genuine OS/2 programs. But the things it DOES do are major helps to improving efficiency! First off, MS-DOS is virtualized (unless you're running what is known as a "specific DOS session," otherwise known as a Virtual DOS Machine or VDM). This means that whenever a program thinks it is calling DOS, it is actually calling OS/2, and OS/2 does the real work, while doing a darn good impersonation of DOS that would put both Rich Little and Dana Carvey to shame. But since OS/2 is in protected mode, its impersonations of DOS calls are also in protected mode and so run faster. Also, the mere fact that DOS is 16-bit and OS/2 is 32-bit means that OS/2 can process the calls faster than DOS can. We still need mode switches, though, since PharLap doesn't know this and proceeds to map everything to conventional RAM before swapping and switching to real mode before calling "DOS" (OS/2). So this alone doesn't buy us much extra performance (though it does help). Where the REAL gains come in is through OS/2's own DPMI support for DOS (both real and virtual) sessions. Phar Lap, being DPMI-aware, will ask DPMI for memory first before it asks other protocols such as XMS or EMS, presuming it sees a DPMI server loaded. Windows in 386 Enhanced Mode is a DPMI server, as is 386-to-the-Max and QEMM's QDPMI.SYS, etc., but they don't do anywhere near as good a job as OS/2's DPMI does. For OS/2's DPMI tells DPMI applications that there is more PHYSICAL memory available than there really is, and OS/2 itself handles the swapping via its SWAPPER.DAT file. You decide how much DPMI will tell 3DS it has, up to the limit of the free space on the hard drive you're using for OS/2 swapping, or 512 megabytes, whichever is smaller. Let me repeat that: 512 MEGAbytes!! Can you afford to put 512MB of SIMMs in your CPU? Can your motherboard even take that much? Probably not. But can you afford that much free hard disk space? A lot more easily than you can afford 512MB of RAM!! So 3DS is running under Phar Lap which is running under what it thinks is DOS but is really OS/2. 3DS is doing a big render job, and it needs lots of memory to do it. It calls Phar Lap and says, "Gimme RAM!!" If this were just MS-DOS and you didn't have that much RAM, Phar Lap would have to go shopping in its swap files, which involves mode switching and calls to 16-bit MS-DOS. SLLLOOOOWWW!! But not now, baby! Phar Lap asks DPMI for the memory and is told that it's available! Phar Lap doesn't know that OS/2's DPMI had to go shopping in the swap files, so it didn't do any swapping of its own! But why is it better for OS/2's DPMI to swap than for Phar Lap to swap? Because OS/2's DPMI is in protected mode! It doesn't need to do all those mode switches! It doesn't need to call DOS, either — not even OS/2's virtualized DOS — since OS/2 itself can do the work better and faster, being fully 32-bit and multithreading and all that! Indeed, the actual disk reads and writes can happen at the SAME TIME as your 3DS is doing render work! Phar Lap itself wouldn't begin to start its own slow swaps until 3DS needs more than 512MB of RAM, which I have never seen happen even when rendering a detailed model of downtown Shreveport, LA! I have personally tested 3DSr3 under OS/2 2.1, and I've found that renders that wouldn't have required swapping anyway (simple geometry, etc.) run almost as fast as they would have under DOS, so long as the 3DS render task is in the foreground and little else is running. But when the project is big enough that swapping would have happened under DOS, then 3DS renders noticeably FASTER under OS/2! And here's the BIG advantage: you can have TWO copies of 3DS running at a time! Set up one to run in background as an icon, with the NULL display driver, lots of DPMI memory, etc. Set up the other to run with the video driver needed for getting actual work done, and to run in full-screen mode. Give it some DPMI memory, too, but not as much as the render task. Set the background task to be a network render slave with its own copy of 3DSNET.SET and a different name and ID# from the other 3DS foreground work task. Now you can have ONE machine and do backround rendering while you're working on another 3DS project! When you're actually working in the main 3DS task, the render task will slow down or even pause briefly depending on how much CPU time the foreground task is needing at the time, but when you're not doing much CPU stuff with the foreground task (and let's face it: most of the time spent in 3DS design work is spent sitting, thinking, and maybe moving the mouse around a bit), the background task runs nearly full throttle! And all this happens AUTOMATICALLY, thanks to true PRE-EMPTIVE multitasking! I've heard that OS/2 Warp 3 is noticeably slower than 2.11 in real operations, but it "feels" faster because the user-interface has been tuned for snappier response to user commands, even though the real work happens slower. I don't like this change. If there is a way to tweak OS/2 Warp 3 to put more CPU time back into the real work and less into the user interface, I'd really like to know. We won't get Warp 3 here until we find out for sure on this. So get 2.11 if you can. For well under $100, it's an outstanding value to any 3DSr3 or r"4" user!