Renderosity Forums / Poser - OFFICIAL
Welcome to the Poser - OFFICIAL Forum
Forum Coordinators: RedPhantom
Poser - OFFICIAL F.A.Q (Last Updated: 2024 Nov 27 2:10 pm)
Subject: P5 CPU Test results:
Op, the benchmarks are in the previous thread on this by Jim Burton in this forum, and he also put an abbreviated list in his freestuff item today. I am surprised that the G5s and Panther are 3 times as fast as the G4s and Jaguar, which were all we could use in Jim's previous test.
Message edited on: 12/20/2004 23:44
Attached Link: http://www.renderosity.com/freestuff.ez?Form.Contrib=Jim+Burton&Topsectionid=0
At the link :-)"you are terrifying
and strange and beautiful
something not everyone knows how to love." - Warsan
Shire
" Op, the benchmarks are in the previous thread on this by Jim Burton in this forum, and he also put an abbreviated list in his freestuff item today. I am surprised that the G5s and Panther are 3 times as fast as the G4s and Jaguar, which were all we could use in Jim's previous test." I'm not too suprised: (G5 vs. G4) http://www.theandyzone.com/computer/shootout/shootout.html Also, my Runtime wasn't built for the Mac (aside from rinsing the thing through MacConverter), though I don't know if that had anything to do with it. I suspect that if I were to toss in an extra GB of RAM I'd prolly be able to improve things a bit. /P
Hey, great results, but one little thing, though "basically I ditched as many excess processes as was safe" do you normally run this way? ;-) Once you start optimizing you computer to a state you don't normally run it, or optimize Poser (as some others have done, I think), it isn't really a fair test anymore, I just wanted to point out. I'm running my 2.8 Ghz Pentium 4 overclocked 10%, it has a pair of SATA RAID 0 drives (which do about double drive transfer speed), and 2GB of matched Corsair DDAM Twinx1024-3200LLPT memory, in an ASUS P4G800-E motherboard with optomized settings, in Win 2K, which (at one point, anyway) was thought of as being slightly faster than Win XP, due to less overhead. The reason I mention the above was my time for the test is 207 seconds, and some PC guys have reported rather faster times than this, and other than faster clockspeeds on the CPUs and faster (SCSI) (I assume P5 still accesses the drives during a render, like P4 always does) drives, I don't see how they are getting them, either. ;-) However, a MAC is another story. Shame they gave up the SCSI drives.
"do you normally run this way? ;-)" Actually, yes. There are a ton of things floating around in the Runlevels that I honestly never use, and it doesn't seem to restrict what I need to do. I keep a backup of what was default just in case I hit a snag, but I do fairly well w/o it. Come to think of it, I should've tried running it with just a default Poser install (and no big-assed Runtime), which would cull Poser's overhead by a lot (IIRC it loads a reference index of the Runtime contents during load, yes?) "and some PC guys have reported rather faster times than this, and other than faster clockspeeds on the CPUs and faster..." I'm not surprised. Like someone had said in the thread that spawned this one - Poser 5 was/is basically a kludge. "Shame they gave up the SCSI drives." Dunno... having SATA by default isn't so bad :) I also noticed that the test file actually ran slower than my normal files do. It may be the reflections, but I'm not sure. I'll run it again and this time see what the System Monitor shows as far as usage, because for some odd reason I don't think it's even using a quarter of the capacity(for instance I know the Altivec engine isn't even being touched.) /P
P4 2.4 1GigRam XP Home 274 seconds.
No optimazation of any kind, LOL!
I had a few mail and broswer windows open and a text editor. My speed slower, just a little, than others reported on the ReadMe. It's because my sys is undefragmented, in last 2% of HD space and got a pretty big Poser system. No complaints.
What about Mac trials? Has anyone run this on a G4 or G5 in addition to penguin?. I have both, but no poser on them.
::::: Opera :::::
Message edited on: 12/21/2004 12:59
shadowdancer: Unoptimised PC. AMD Athlon 64 3200+ (actual clock speed 2.2 ghz), 1.5 Gb Ram, OS Win XP Pro SP2, 165 seconds. can you or anyone comment on this fast result, with regard to: does XPPro vs XPHone contribute? contribution of SP2 over SP1 is there something about that particular AMD chip? As opposed to the AMDs just under it in power? If your time is accurate, your sys is getting better than 1/3 more speed than mine, and you are significatly faster than anyone on the ReadMe included with the test, and I want your speed and secret. What is the factor? ::::: Opera :::::
Mac G5 here. Dual 2GHz, 1 GB RAM. Safari, BBEdit, TextEdit, Mail running in the background. I ran the test a couple of times and seemed to get different speeds each time. One was 5 min 7 seconds, another 4 min 35 seconds. Then I increased the bucket size to 128, which is what I normally use, and then the render took just under 3 minutes. Decreased bucket to 32 again and got another 4 min 35 seconds.
Marianne,what is the bucket? The system cache? [no manual RAM allocation per app on OSX, right?] OKAY richardson, that is TIGHT! (i have a teenager). That is the 2400, not the 3400??? Must be the RAM. Or the Win2K. Anything special about your RAM modules? What is their spec? [i am serious, if i can cut render times in half, i am shopping, right now.] ::::: Opera ::::: OT P.S. i used to really like BBEDit for html when I was webmastering on Mac, now use EditPlus on PC.
Okay, Jim... just to satisfy all questions: I restored all the default settings on the Mac, and ran the test again under five different Render setups (while running Safari to park all this commentary somewhere as it unfolded) Best time is set in bold type : Bucket Size = 512: 3 minutes 23 sec (203 sec.) Bucket Size = 256: 3 minutes 2 seconds (182 sec.) Bucket Size = 128: 3 minutes 37 sec. (217 sec.) Bucket Size = 64 : 4 minutes 28 sec ( 278 sec.) Bucket Size = 32 (default): 5 minutes 14 seconds. (314 sec.) It appears that there are diminishing returns once you bump it up past a certain point, and at the 512 size, I began to see the ol' Spinning Beachball of Busyness. Dunno what 1024 would've gotten me. If I get more RAM like I plan to, I may have to find out :) Mind, the higher-speed G5's might see small increases in render speeds - the bus speed jumps up from 900MHz (me @ 1.8GHz CPU) to 1GHz (the dual 2GHz CPUs) and 1.25GHz (the 2.5GHz beauties), but we're all stuck with the same SATA hard drive speeds, so there are limiting factors at play no matter what G5 box you get. HTH a little, /P
Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=589354
Original thread from '02.
Barry - the bucket size makes a huge difference. While the PC doesn't see too much gain from it (though not bad all the same), increasing bucket size somehow brings more system resources to attention when rendering. The reason your speed and mine are pretty close is because we both have the same SATA drive bus, and drive access speed looks to be the biggest bottleneck in performance as far as Poser is concerned. If you were to make a RAID 0 setup like Jim described, then I suspect performance would increase by enough for you to blow me and most other machines (PC or Mac) right out of the water. (only problem is, there's only room for two HDD's in the box... and I don't much feel like stuffing another 80GB drive in the one open slot. Then again, I can always toss a spare 200GB ATA 150 drive onto FireWire and call it good :) ) I think from now on I'll just make sure the bucket size is bigger (and I intend to get more RAM while I'm at it. I have 1280 MB of RAM total, or 1.25GB.) bdougal - I only got the beachball when I jacked it up to 512. I ran the renders in this order: 256, 128, 64, 32. I then went back to 512 just for giggles. One thing I'm curious about though, is how much of a performance increase would PC users get if they jacked their bucket sizes up to the larger sizes. /P
PC: I have increased my bucket size from 32 to 128 last few days and am getting a full 20% gain on render time. What an idiot i did not try that before.
Mac: I have a super clean G5 Dual 1.8GHz with 2.5G RAM but just the standard 80 gig drive plus one 250G SATA. Will be installing Poser next few days to gain new rendering station and do time trials.
For serious animation workstations...we should all remember that SCSI is still in the picture for either OSX or Win...you just need to throw down the bucks and you can acquire controler cards and a dual drive SCSI subsystem, external, and you can RAID 0 on that. This is very common in the audio world, where high-end PCs and Macs are used for direct-to-HD digital recording of the human voice (AKA singers!).
One interesting way to keep the price down would be to not go for large drives, because you are focused on fast access during render, mostly. Once rendered, final files can be pushed off to a large storage drive. However, the smaller SCSI drives may not have the hardware/buffers/access/drivers as the larger; you might need to buy big drives anyway to get top performance.
I must say I am a little suprised that HD access seems to be so big an issue. Is it really?
And if so, is it access to Poser and OS resources not loaded into RAM that are critical, or the is it the actual write to the file.
Here's why I bring that up. Last night while sleeping I rendered a 10-second animation. I rendered out to separate image files, 300 frames. The individual frames are large .tif files of 1.4MB apiece, 720x405 at 144DPI. This render required about 5.5 hours. The folder at the end was 350MB in size [ended up with beautiful 17MB Quicktime, Sorenson compression]. Now, during 5 hours, really, how much intensity was focused on writing a 'mere' 350MB to disk, and how much on pure processing between the CPU and RAM. At 128K per write, it is only twelve or so burst writes to disk per frame.
I float this not because I have the answer...I am hoping people with more technical knowlege will respond so I/we can gain perspective on the impact of disk access time on such renders. I tend to think it is much more a question of CPU/RAM power and sympatico.
::::: Opera :::::
Message edited on: 12/22/2004 10:27
Message edited on: 12/22/2004 10:30
I'm thinking that the drive access speed has to do with lots of factors here.
The following is all assumption based on observation:
- In the preview window, Poser grabs a texture image, but then rinses it through a quick quality reduction before slapping it on the mesh, so as to keep the UI responsive. For instance, say you have a 4000x4000 body texture. Poser would grab that image, but only scan enough of it to get the equivalent of a dirty 512x512 image scale, then applies it according to UV mapping. This explains why you see lots of seams and blurry details in the preview window, but not in the final render. When the render begins, Poser has to re-load each texture from the disk drive at full resolution and re-apply them to the mesh.
Same story for materials, where the preview run may look a bit dirty due to loose low-decimal calculations and reduced resolution image maps behind 'em.
-
I think the mesh gets loaded @ full resolution (it would have to, at least for grouping and other purposes), but during render, it re-reads the base mesh point-for-point, and applies whatever deformation and morphs are present at full resolution (whereas morphs and etc. may be applied to the preview window as a rough estimation before the render.) There may also be a partial bit of smoothing that occurs as well. This means going back and re-reading a lot of mesh and morph info from the disk before calculating.
-
No matter how much RAM you've got, Poser is prolly going to reach into the virtual memory pile during render - a lot. I think it's because physical RAM is more "expensive" than virtual RAM when it comes to storing non-critical and intermediate calculation results, whereas you can write that stuff to virtual RAM and it can be "forgotten" about until needed and retrieved later. This also provides backwards/legacy compatibility for machines that don't have a lot of physical RAM installed (and allows CL to fudge the stated minimum and "preferred" system requirements downwards by a lot more than would otherwise be credible.)
Otherwise, there may be a couple of other small things (for example if there were any Python scripts involved to modify the render itself, that and the Python runtime environment would have to be brought up), but those three biggies up there are my best wagers.
/P
Message edited on: 12/22/2004 11:28
Message edited on: 12/22/2004 11:30
ok, so you ARE saying the HDAccess impact on render times is resource-fetching, not with writing the actual output file.
Given that....i wonder if Poser is smart enough to load more into RAM if it sees a lot of RAM, or does it make assumptions, and above a certain point starts swapping to virtual REGARDLESS and causing HD access. [SIDE NOTE: the new G5s can map out up to 8GIG of RAM! Many PC motherboards can go to 4GB. In an extreme situation, would Poser, I wonder, even see that RAM and use it to load full textures, etc.]
So, if one has a lot of RAM, I guess the first approach to avoid disk access is strategy/settings to force Poser to load as much as possible into memory. Are there any?
Next...what about putting Poser.exe and the runtime folder (with the textures, obviously) on a RAM disk?
::::: Opera :::::
Message edited on: 12/22/2004 11:57
I tried a 256 bucket, I forget the time but it was slower than 128. It actually finished faster, but then it just sat there for awhile chewing its cud before it showed the render. ;-) That is with 2GB, I suspect Macs might make better use of their RAM, if the cross-over point is higher. Incidently, from what I read at Toms' Hardware and other places, SATA drives aren't actually currently faster than old type ATA drives, they just have a faster potential. (The cables are neater, though.) However, I'd guess that SCSI 160 drives ARE actually faster, I always plan on putting SCSI drives in my NEXT compter, but I never actually do, because of the price difference. Drive speeds are possably not that important in this test, but they are in real-world use, my Poser 5 loads in about 13 seconds, for instance (I've got a near-stock runtime, most of my stuff lives in Poser 4, that probably has a lot to do with it). With the big files we mostly use, you gotta have a fast drive(s)!
"That is with 2GB, I suspect Macs might make better use of their RAM, if the cross-over point is higher." It prolly has more to do with the way *nix uses memory than with the hardware... Win32 usually doesn't pile on the RAM until it sees a need to, so it takes additional time to initialize and allocate the stuff. In *nix OTOH, as much RAM as possible is already paged and allocated into a pool beforehand, with a little bit left over for emergencies. The RAM is split between "Userland" and Kernel. If a proggie needs more RAM, the OS checks other process demands, then hands over as much Userland-allocated RAM as needed (it'll grab the pages back as soon as periodic system scans show that given pages aren't being used any longer by the proggie.) I haven't tested it with the SATA setup, but I do recall that I used to get some rather fantastic boosts in speed on the PC through FireWire over ATA-100 IDE (prolly because the removable drive has a faster ATA speed as well...) "Drive speeds are possably not that important in this test..." Sorta... on the Mac side of the house, the one big reasons that the PowerMac G5's are getting fairly close results in spite of differences in bus speeds and CPU speeds (and even the amount of RAM) may well have to do with the SATA bus being more or less the same speed for all of us, causing a somewhat consistent bottleneck of sorts. "Next...what about putting Poser.exe and the runtime folder (with the textures, obviously) on a RAM disk?" Shouldn't be hard to do - you could even script it on the Mac (build & init the RAM disk, copy the Poser binary and essential items there, create symbolic links to the Runtime, launch the binary, etc...) but you'd still have to hit up the hard rive for the textures and mesh (unless you have a mentally obscene amount of RAM to stuff your entire Runtime into... my Runtime directory holds 10GB as it is now.) Your best bet would be to kick the CL guys in the teeth once or twice and have them implement a manual memory allocation command or setting, much like a lot of games do now. With this, you can allocate as much RAM as you can spare for the program's exclusive use (example: Quake 3's /seta com_HunkMegs nnn ("nnn"= # of MB's you want to allocate) command.) /P
I forgot to get back to this thread with my G5 time: G5 Dual 1.8Ghz 2.5Gig RAM SATA250 (poser and pz on that drive, OSX Jaguar latest patch on separate HD) Bucket at default of 32: 318 seconds Bucket kicked up to 300: 199 seconds Bucket kicked up to 512: 198 seconds My times are pretty consistent with penguinisto (above) obviously, when it comes time for me to get serious, I will test bucket settings between 32 and 300. Also, I tried pushing the bucket to 800, but Poser did not know what to do with that. It just 'ended' the render and gave me a black blank image. ::::: Opera :::::
Privacy Notice
This site uses cookies to deliver the best experience. Our own cookies make user accounts and other features possible. Third-party cookies are used to display relevant ads and to analyze how Renderosity is used. By using our site, you acknowledge that you have read and understood our Terms of Service, including our Cookie Policy and our Privacy Policy.
(from the freebie thing Jim Burton posted: ) Total of 3 minutes 45 seconds from "render" to completion. Other proggies running: * Safari Web Browser System setup: Macintosh Dual G5 1.8GHz 1.25GB DDR2 PC 3200 RAM GeForce 5200 FX Ultra w/ two monitors. OSX 10.3.7 with optimizations (basically I ditched as many excess processes as was safe.) HTH a bit... PS: Since I had imported my Runtimes from archive (PC Linux/cxoffice emulation for use in DAZ|Studio), GroundDefault.pict got lost in the shuffle. /P