#RENDERING 486/66DX2
22 messages in this thread
I WOULD LIKE TO KNOW IF ANYONE OUT THERE HAS DONE ANY TIME TRAILS TO
COMPARE THE RENDERING TIME BETWEEN A 486/33 AND A 486/66 DX2 .
There's a small doc that was just uploaded a couple days ago that goes into
that very thing: rendering times on various configurations of hardware. It
was called 3DSBEN.TXT, I believe: 3DS Bench Mark.
Phil,
No 66's at Adesk yet, huh? Nothing in that library file about them. I also
found some of the figures improbable – they seemed to indicate that a
486/33 was faster than a 486/33 with a weitek co-processor…. say
what!???? I'll have to read it again and try and make sense of it.
Martin
Yes, we puzzled over that a bit ourselves: the 33MHz Intel being faster
than a 33MHz Weitek. I don't what the answer to that one is. As for "no
66's at Autodesk yet" we tried to purchase some 66MHz chips (33MHz DX2's)
and we told by purchasing "there ain't no such thing." Oh well. 🙂 But
if you come up with numbers for 66MHz vs 33MHz or 50MHz, let us know.
PhilD,
The 66dx2 is being advertised now all over the place so you might suggest
that purchasing get out a little more (or read PC magazines instead of
Marvel comics) <g>. Sorry, I'm sure they are very nice folks 🙂
I did my own tests and here they are (I don't have a 66dx2 yet):
test1 test2 test3 test4
—– —–
—– —–
Tristar 486/33 w/ Weitek 4167/33 316 617 273 546
Micronics 486/50dx2 222 433 190 377
This caused me some puzzles because my Tristar has proven much faster than
comparable AST configs before. One important parameter that "the boyz" left
out was shadows. Please check if it was ON or OFF. My numbers were with it
ON. This is very important since my Tristar's ego is very bruised right now
having benched 11%-15% slower than the AST in your tests. TIA.
Martin
I'll check on whether that was with or without shadows.
You can certainly run a 33/4167 fslower than an Intel-only machine by doing
one thing… running the Weitek machine without an expanded memory manager,
while you run the Intel machine with QEMM or 386-to-the-max. I've got no
idea how these specific benchmarks were run, but that's a probable cause
for the discrepancy.
– G
Gary,
Well, I took the Yost recommendation to install QEMM a long time ago <g>
and couldn't really concieve of not using it now…
Martin
What really bothers me is that I KNOW there are a LOT of folks out thre
using 3DS without a memory manager and getting almost half the performance
that they ought to be getting. Argh.
– G
Gary:
A memory manager makes absolutely no difference in the performance of 3DS
unless you have a number of drivers that you want to load hi… or unless
you're saying that expanded memory is faster than extended memory (depends
on whether 3DS likes to address memory in page frames or continous ram…).
3DS will recognize all of someone's extended memory without ANYTHING loaded
as a memory manager on a 386 or 486 system…
C#
~~A memory manager makes absolutely no difference in the performance of
3DS>>
Not trying to argue with you, Craig, (I mean, you could well be right) but
that isn't what we're finding. Take otherwise the same configuration, just
put qemm on one of them, don't do anything else differently, and 3DS seems
to run faster with qemm than without. Could be related to the hardware
we're using as much as anything else. Could even be early on set of
senility and myopia. 🙂
Phil:
I'm not sure I understand… QEMM makes memory available to applications in
either expanded or extended memory format as they request. If you don't use
QEMM to load anything high, thereby increasing base ram available, then the
only performance enhancement that should be available is due to the way
that 3DS is accessing memory. If you don't load himem.sys (with DOS 5.0)
then 3DS (pharlap) is managing the memory. What you're saying is that QEMM
is better at managing memory than 3DS?
Well, you learn something new every day (thank god…) and so, I guess I
will try it out to see if I'm getting senile too! <g>.
I thought that Gary meant that 3DS couldn't access extended memory properly
without a memory manager and that wasn't the case… he doesn't care about
hardware anyway <grin>…
C#
What can I say? As I mentioned, this may be due to the particular
hardware, or something like that. QEMM might be straightening out certain
quirks in the addressing scheme or providing a better memory management to
get along with phar lapp, or something of that sort.
Craig, we've tested this with about 8 different clones, and I can guarantee
you that on THEM, using a memory manager with 3DS makes the program run
about 50-60% faster. You guess correctly about the reason… expanded
memory runs much faster under Pharlap than extended does.
– G
G:
Whoa! I'm gonna go try this tonight! 50-60% increase?? I always thought
Pharcrap was a quirky bird! Now I don't think there's any question… that
is, assuming we're not venturing forth into areas which we have no idea
what we're talking about… which is what the PharLap guys want us to think
<Grin>.
C#
Craig,
OK, I'd like to put this little piece of folklore to bed. I have
just run a test, with QEMM, w/no memory manager, and with HIMEM.SYS.
*EXACT* same rendering times, to the second! I can only presume that
Gary's system is running faster w/QEMM due to QEMM handling better some
possible system conflicts (that otherwise slow things down) or to QEMM
RAM/ROM shadowing, where these would otherwise need to be disabled because
of hardware incompatibility. 50-60% faster. Nonsense! Nonsense, I say!
Kevin Krell – Computer Support Associates
Kevin, my system isn't the only one at Autodesk that has exhibited this
problem. The QA dept. just finished benchmarking all the computers in
their facility, and it turns out that all the AST's did it as well. (the
Compaq's didn't because of their proprietary memory manager)
If you'd like to come up to Sausalito for lunch, I'd be happy to show you
in person!
– G
I just sprinkle a few chicken feathers and a couple of drops of goat's
blood on my monitor to achieve at least a 33% speedup in screen redraw
time. This also seems to increase my RAM marginally.
– Jack
Kevin:
Like I said, other drivers… maybe they are all loading drivers for their
controllers, etc? It could also be that the difference may start to show up
when you are using ALOT of memory (which Autodesk probably has gobs of…).
I can imagine that expanded memory is better for 3DS when you have 32 megs
of ram or so… but I can't stand it anymore, I'm going to go try this
out…
It seems a bit funny to me… did you try it with HIMEM.SYS AND EMM386.EXE
converting ALL of the memory to expanded? (What I'm going to do… you
could save me some time <grin>)?
C#
I'm very curious to see what happens for you. This is getting
interestinger and interestinger. (especially after Kevin's comment)
Although I've got no idea why this is happening, I've seen it on at least 5
or 6 other machines.
– G
Gary:
My rendering times were exactly the same with or without the memory
manager… I didn't force a setup using emm386.exe, however… I don't
belive that QEMM would force expanded memory unless PharLap has a
preference, either… but I will try that next.
OK… I'm back. While I was waiting for my rendering I looked at 3DS's
I&PG…
On page 65, just before 'Important:' I think the manual is a little
misleading… Himem.sys without emm386.exe creates extended memory.
Himem.sys with emm386.exe creates expanded (XMS) memory. Adding a memory
amount to exclude behind emm386.exe returns the memory to extended… at
least, that's the way I understand it (I've been wrong many times before…
and I will be again..<g>). PharLap will not use XMS memory.
I did notice, using the complete compliment of himem.sys and emm386.exe to
create extended memory that I had an improvement of .86 percent in
rendering times (yes, that's correct… less than one percent). It may be
that QEMM will do better (I don't have it here…)… But I can't see
50-60% on this machine… SVGA, 486/33, 16M of memory… total clone.
There has to be a difference in the way that Autodesk has their CMOS's
setup…
C#
Other than the stated hardware configuration, the~ benchmarks were run
under EXACTLY that same configuration (same computer brand, same config.sys
and autoexec.bat, etc.).