Hi folks, I just built a new computer, based on a 3.2 gig P4 Prescott with 1 meg L2 cache and 2 gigs of PC3200 ram (Geil Golden Dragon) on a dual channel DFI lan Party Pro MB. I decided to perform a rendering test, using Vue 4 v4.20-02 (build 265846), to see what kind of performance I'd get over my previous workstation, based on an Athlon XP 2600 (266 FSB) with 1 gig of standard PC133 ram on an MSI K7T Turbo 2 MB. I used the WAITING ROOM project included with Vue as a rendering test. I made a 1600x1200 render using FINAL settings for the reference. To my surprise, there was only a 3.5 minute rendering time difference between these two machines! (1:20:23 vs. 1:24:00) I'm at a loss as to why this could be. The only possibility I suspect may be the graphics card. The Athlon system has a GeForce FX 5200 with 256 megs of ram, and the P4 system temporarily has a Matrox G400 with 32 megs of ram (while I await delivery of an ATI Fire GL T2 card). Is the "USE FULL HARDWARE ACCELERATION" under the USE OpenGL function the reason for this? The manual doesn't specifically state this for renders. The FX 5200 controls don't show any controls for activating hardware acelleration either. Both systems had this on when this test was performed. If this is the case, I think I would've just bought a newer card than build a whole new system! :-D Tahnks for any info on this.

Try disabling hyperthreading on the P4 machine. There was a post about this earlier. Apparently Vue 4 regular doesn't like hyperthreading (it actually slows down rendering) but Vue 4 Pro works well with it. The graphics card has nothing to do with rendering, only displaying the viewports.

Thanks for your reply. I thought about that later. I have subsequently perofrmed some Photoshop tests, and although there were some performace improvements, I've been similarly disappointed by what I'm seeing. As far as I know, Photoshop should work with hyperthreading. I think Pentiums may be overrated. So far I'm not impressed by what I'm seeing.

nothing wrong with that p4 its a nice cpu alot better then your athlonxp, but the best cpu out there as of today is by far the amd 64 so that would have been a wiser purchase for you, would have given you alot more performance for the same amount of $ your p4 cost you.

Well, that definitely stinks, although I don't have a clue as to how to make things better... :)

Same advice as nahie - you should try disabling hyperthreading. The CPU, motherboard speed and RAM speed are the critical factors (in that exact order) in rendering performance for Vue, and for most other 3D rendering programs as well. Actually, I just am building out an AMD 64-bit FX53 machine with a top-of-the-line ASUS motherboard, myself. As far as I know from all the technical specs I've researched, there won't end up being a truely significant performance difference between this chipset and the current more conventional AMD 64's now out or the high end P4 cpus. So, don't feel like you did something wrong with the P4 purchase. Some of us tech professionals prefer the AMD 64/FX53 because its a "cleaner," more tightly designed chip, but don't be misled by the hype. At the moment, there is no really good PCI Express motherboard out for the AMD 64/FX series, as was intended. (The MSI board currently available for this chip is somewhat quirky, as I've learned the hard way. So, for reasons of stability, one must mate this chip up with a more conventional PSI motherboard.) And the actual performance differences as shown on lab-grade MAX and Lightwave benchmarks are superior, but just by a small bit in real work terms. In December, for anyone else curious, the next set of AMD 64/FS series is due out, and this time there will be more appropriate PCI Express motherboards and PCI Express video cards available. So, unless you're a bleeding edge techie who has other reasons for needing an FX53, save your money and wait another 6 months. I bought these pieces for MAX, Truespace and Vue, but I'm not expecting miracles in the work-a-day world. So, again, YOUR choice of cpu is reasonable, and that's quite a good motherboard you've acquired. Never heard of your RAM manufacturer before, but its good to learn of other companies. So, feel good about what you've got, and thanks for the post.

that is odd, My mac just did it in just under an hour (1.8 G5 with 1 gig ram) Not that I'm any pro at this or anything, but what is your mother board? Is it "matched" to the processor/memory etc? I'm no PC person but i'd think that the P4 at 3.2 should beat my mac! some system thingy not set right? there is an article in 3D World mag that's all about setting up a PC top speed 3D (issue 54, has shrek 2 cover) there are a lot of tips that I even applied to my mac.. maybe take a look at that?

Sorry, make that " ....in December, expect the next "AMD/FX" series, probably will be AMD 64/FX57 and FX59, then.

Hey, that's a good point, thomllama! There really are a good set of "tips" for streamlining your renders in that issue. Maybe we should re-print those tips here for everyone else.

That would be very helpful as I had held off on that particular issue due to the $15 price tag (in the US) and not having any really good extras on the cd. Thanks in advance if anybody manages to post the tips for speeding things up in the forum!

Well, I shut hyperthreading off, and render times increased by 20 minutes! What's going on here? I think the problem may be with Vue. The only other program that I've tested so far on the new machine is Photoshop, and everything was indeed faster there, with the exception of two processes (who's complications I believe were graphics card related). As I mentioned in my first message, I'm using Vue 4 v4.20-02, build 265846. Are there any newer updates for Vue? Perhaps Vue doesn't know how to effectively communicate with the newer 875P chipset and/or Prescott architecture. No matter how "off" the settings could be on the system (and I don't think anything is amiss), there's no way in hell that a machine with a 3.2 gig chip and 1 meg L2 cache running on an 800 FSB, using 2 gigs of 400 FSB dual channel ram is going to slug along as slow as a system running on a 2.1 gig chip with a 256 meg L2 cache and a 266 meg FSB being fed from 1 gig of 133 meg ram! During this week, I will perform some additional rendering tests with Blender, Maya, and combustion to see how the system fares overall. I hope the problem is indeed with Vue, otherwise I'm going to really regret building this P4 system! Something in the back of my mind kept telling me to build another Athlon system, and I now wonder why I didn't.

You've stumbled onto the dirty little secret of hyperthreading; looked at one way, it just allows exectution of another program thread, which sounds really cool. Looked at another way, it mimics -some- aspects of a dual core system...but only some. The software that HT speeds up has been specifically optimized to utilize it; with the other 99% of the code out there, it is very much a hit and miss affair. And with apps like Vue, that is MP aware (but not optimized to know what hyperthreading is), you get into a situation where part of the code is saying 'Multiple Processors Found', and the rest of the code saying 'NOT!'. The time you lose is the app making calls, getting no response, defaulting back to single processor single thread execute mode, then hitting another call that trips the same event loop again. And again. etc... HT is a nice little hardware trick...but its usefulness is strictly limited by having a OS that knows how to interface with it, and a app that knows what the hell it is in the first place. Outside of that, it tends to be more a drag on systems than a help. How's that Prescott behave thermally?

Have you tried going to the E-on web site? They try really hard to help trouble shoot. and you'll get a lot of other people there who may have suggestions. They'll also know if multi-threading is good or not and how to set it up. just take a couple days to get responce, you know... different parts of the world and all :)

i have vue 4.2 w/ mover how would i turn off hyperthreading? and what does it do?

Basically, what 'hyperthreading' boils down to is allowing the CPU to utilize extra hardware to run a second program thread, instead of the single main thread that most do. In its own way, it is very much like MMX; something that knows what it is can exploit it for benefit. Something that doesn't either ignores it, or some program call rouses it enough to get in the way. For the very few programs out there that are optimized for HT, it speeds them up considerably (most of those programs tend to be things like video editing suites. Some of the big 3D apps have the optimizations, as well). For older programs, it can be a liability. Disabling hyperthreading is easy; on startup of your system, hit the delete key to go into the BIOS. Look around in the more advanced areas; there should be a line that says 'Hyperthreading' and to the right should be a 'YES'. Arrow down until the cursor bar is over this line, then hit page down on the keyboard; this should change it to 'NO'. If it does, then press F10, when it asks if you want to save the changes say Yes, and let the system reboot. You just turned HT off.

Hi, don't know too much about computers but I have built a couple of computers myself. Have you tried flashing the bios - I'm not sure if this would help but it maybe worth a go. A magazine called 'Custom PC' has an article on flashing your bios (issue 12) - it may help.

You've stumbled onto the dirty little secret of hyperthreading...<< Well, I guess you're damnned if you do and damnned if you don't. It's terribly disappointing not to see any significant increase in performance in Vue with this new machine. Last time when I upgraded to the XP 2600, I was coming in from a 1.4 gig T-Bird Althlon, and I experienced a 45% increase in renderng speed! All I did was change the chip, no less. Here is a whole new system, I was hoping for even better now, and it's horrible that this app is just choking on this architecture. I knew I should have built another Athlon system. Not that Vue is my primary 3D app, but it's always a handy thing to have around when you need to whip up some quick scenes. I was just hope to whip 'em up faster. :-) Oh well. I did see a new upgrade at the E-ON site (version 4.22). I've downloaded it, and although I doubt it'll really make any difference, it doesn't hurt to try it. >>How's that Prescott behave thermally?<< It's a cooker alright, although the Intel-supplied fan appears to be up to snuff. Considering it's the size of a house, I suppose it's par for the course. :-) I was hesitent to leave the heat transfer tape on and use some silicone grease, but I figured if Intel feels comfortable with it, I'll just let it do it's thing. I'm not overclocking it, and you'd definitely need serious cooling if you're considering that. There's an article about this over at Tom's Hardware abuth this very topic, using the DFI Lan Party board no less, over here: http://www6.tomshardware.com/cpu/20040517/index.html

It wouldn't help in all likelihood, and flashing the BIOS is something that needs to be approached carefully. If you fail, unless you have one of the boards with a second BIOS chip as a failsafe, you will have killed your system until you get a replacement BIOS chip. And usually, unless you have a good connection, it turns out to be cheaper to just replace the motherboard entirely (you have to have a bootable, working BIOS to be able to flash a BIOS. If it won't boot, you can not flash it to repair it).

Funny this thread topic came up as I had just ordered a P4 3.0 prescott system and it arrived today. I have two older athlon machines, a 2100+ with 1 gig 133 ram and a 2400+ with 768 meg DDR 266 ram. The new P4 3.0ghz system has 1 gig DDR 400 ram. I loaded Vue Pro (I only have Pro, not regular) onto the machines to test. I didn't run the test on the 2100+ because I was working on something else, but I use it for network rendering. I was rendering the "Amazon" sample scene found on the first disc of the Vue Pro 3 disc set. I updated all Vue installations to the latest beta before trying this. I also tried rendering on the P4 machine with hyperthreading on and off. Here are the results (rendering 640x480, broadcast quality) AMD 2400+: 24'25" P4 Hyperthreading: 22'35" P4 No Hyperthreading: 30'42" So obviously Vue Pro uses hyperthreading. But the alarming thing is how close the AMD 2400+ and P4 HT are in render times! This is absurd! The AMD machine is at least 2 years old, maybe older! And it barely loses out to a brand new P4 3.0 ghz processor!?!!? This really sucks. I had a hard time deciding between the P4 3.0ghz prescott and the AMD XP 3200+. I chose the P4 because on most benchmarks you can find on the internet, the P4 wins soundly (at least over the AMD XP 3200+). Now I wish I had gone with the 3200+. I went with the P4 because of the hyperthreading (which e-on specifically states Vue Pro supports, and obviously it does) and the SSE2 and SSE3 instructions, but it seems that it doesn't make a bit of difference vs. AMD processors. The AMD system would have been $20 cheaper too... So then I set the machines up to network render. Luckily it does seem that the P4 is doing a little better here. It's hard to tell but it seems it's rendering faster on my network with my homemade scenes (not vue demo scenes). Maybe the Amazon scene is a bad test scene, I'm not sure. I guess I'll have to do some more tests but right now it doesn't look good for my new P4...

Here are the results (rendering 640x480, broadcast quality...<< OK, step back a bit and look at what you have. Now look at my figures again for the 1600x1200 "Waiting Room" scene with the "final" render setting: XP 2600 - 1:24:00 P4 Hyper - 1:20:23 P4 Hyper off - 1:42:27 What's wrong with this picture? OK, so let's accept the fact that Vue makes use of hyperthreading. Um, so what? The Athlon has no such feature, 'know what I'm sayin'? Look how absolutely MISERABLE a render time we're getting from Vue with the P4 acting as a "single chip", just like the Athlon. Also, as I mentioned earlier, my Athlon system, like yours, is also a relatively dated machine. The Athlon system is a machine with a 2.1 gig chip with a 256 meg L2 cache and a 266 meg FSB being fed from 1 gig of 133 meg ram, while the P4 system is a brand spanking new machine with a 3.2 gig chip with 1 meg L2 cache running on an 800 FSB, using 2 gigs of 400 FSB dual channel ram. Do the math. There's something SERIOUSLY wrong here, both with Vue, and apparently as you've now comfirmed, with Vue Pro as well. I finally got my Fire GL T2 card installed today, so I will now perform some tests with Maya and combustion, and possibly Blender if I have sometime. As I also mentioned earlier, other than Vue, I've only tested Photoshop with the new machine, and it's responding as it should when running off a monster like this. So I guess it's time to have a word with E-ON about this, no?

Actually, neither Vue nor VuePro are HT aware. But they -are- MP aware....which gets into the issue I mentioned about the app making calls for a second processor when there isn't one. It isn't an issue with Vue; hyperthreading was =designed= to appear to give the appearance of a second processor for just about free, when it isn't. Remember the applictation depends on the OS to tell it what resources it has, and there have been a =lot= of sites that posted screencaps that showed both Win2k and WinXP as mis-identifying an HT enabled P4 as a dual processor. Adobe products (at least the latest versions) have all been written to properly use HT; the reason why video people tend to swear by P4's. Turn HT off, and the AMD chips performance either surpasses, or gets awfully close, to the P4 clocking in some cases almost 30% faster (keep in mind that the AMD numbering system doesn't reflect actual clock speed; a 1800+ actually clocks in at 1.53 ghz by the system clock. My Athlon 64 3000+ is actually only clocking at just over 2 ghz. Remember the Athlon series isn't a clone of the P4; AMD snagged a couple of the movers behind the DEC Alpha chip when HP went stupid; Athlons of any stripe have a radically different structure to the registers and the pipeline structure). The big modelling packages that run on X86-32 hardware have the HT optimizations inserted as of the last (or next to last) build. From what I've read, it would be harder to make Vue and VuePro HT aware than it would be to recompile them for iAMD-64....and since AMD is getting ready to drop honest to God dual cores in one package sometime in the 3rd quarter this year...with rumored backwards compatibility with some existing boards...

That still wouldn't explain the massive difference between the rendering times. Those old Athlons aren't THAT good. Just look at the busses. That's 133 megs versus 400 (or 800 if you look at from the dual channel mode). Even if the Athlons were that good, the buss would hold it back. The fact that the Vue render times on the P4 without HT on is so miserable has to do with Vue not optimized for the architecture. I shut HT off again and ran the Photoshop tests again and the P4 machine still smokes the Athlon. All roads lead back to Vue. I don't doubt however, that Vue will run better on an Athlon if I had built, say, an XP 3200 system (or even an Athlon 64). I probably would've recieved another 50% or better increase in performance. But that's because it's an architecture that Vue recognizes. There's something about the P4 and/or the 875 chipset that's freaking Vue out.

Attached Link: http://www.e-onsoftware.com/Products/vue4pro/index.php?Page=11

*Optimized for G5 & P4 HT

I'm not sure but I think "Optimized for P4 HT" means optimized for Pentium IV hyperthreading... ;)

Now whether that is the truth or not, and what exactly "optimized" means...

I still don't know why I get such poor render times on my P4. The ram is even dual-channel tested on a 800 mhz bus, and I think it has the intel 875/g chipset (I'll have to check for sure tomorrow). I'm wondering if it has something to do with the prescott core. I remember Tom's Hardware reviewed the prescott when it first came out, and it actually did worse in some tests than the previous P4 core, the northwood. But it was only in one or two tests, and in other tests, it did better than northwood, and those tests are at the same clock speed for both prescott and northwood. Anyone have a 3.06 ghz northwood they can render the Amazon scene with at broadcast quality, 640x480 and post the times?

amd 1400 -> amd 2600 and a speed increase of 45%
amd 2600 -> int 3200 and you wonder why you don't get a similar improvement using software that is 99.999999% cpu dependent?
amd 2600 equals int 2600 in most cases and as many amd cpu works well with graphics software, so your big step to 3200 wasn't as big as you thought, despite all the Intel hype. rule of thumb -> don't replace you cpu unless you double the speed.

Attached Link: http://www6.tomshardware.com/cpu/20040201/prescott-18.html

I don't know how reliable tom's hardware is, but in my experience, they have fairly even reviews. The 3dsmax scores for the AMD chips looks a little off though. the 2700+ faster than a 3000+??? Maybe the cache is different on those models. I dunno...anyone find any other benchmarks? Edit: Maybe vue is more like lightwave or mathmatica on those toms hardware benchmarks...the AMD chips do much better on those software tests...

Message edited on: 08/17/2004 01:38

"rule of thumb -> don't replace you cpu unless you double the speed." Yeah I'd been following that rule for years but I wanted to add another machine to the render farm anyway. Looks like I chose poorly but at least it is another machine chugging along on those long vue renders...

hmm maybe we should all do a render test and compare results? we did something like that over in the carrara forum ( more for fun than anything) can help to decide system performance and hardware purchases for later, (not just CPU but ram, drives, motherboards etc.) something not to simple, don't get long enough renders to get a good report. but not to detailed cause then you end up locking your machine for hours, something around an hour for the mid machine... make a new post?

Message edited on: 08/17/2004 05:34

You know, I'm not sure that some of the readers here are fully understanding what Dale B is saying. Its as if his comments are being ignorned, or the significance of what he's saying is not sinking in. My apologies Dale, but would you mind if I tried putting this out again? As Dale B pointed out, if Vue (or any 3d program) is designed to be aware of and written to take advantage of two cpu’s (multiple processing or "MP" as Dale uses), it will detect the hyper-threading as the existence of two cpu’s. Then, it will execute the program code written and compiled for dual cpu’s. However, here’s approximately what happens when it tries to use this code. The program code divides the data (rendering line data, in this case) to be processed into two streams of instruction sets – one for each supposed cpu. It then queues up the instruction sets for the two supposed cpu’s. Now it starts to process those instruction sets. CPU #1 – the only actual cpu in the machine, processes its first instruction set, and then waits for the results from the second cpu. At each pass, the program code, if properly written - and Vue does seem to be properly written, will discover that there is no “result” from “the second instruction set,” so it then will send the second instruction set into the only actual cpu. Then it will mate up the two results in the cpu cache, and then, depending on the size of the cpu cache, be forced to pass them on to the RAM cache. Then it starts the process again. The net effect of this “whoops, there's really nothing coming from the second cpu” set of processes is that the whole overall process will be much slower than expected. If the cpu cache is just an ordinary size, as in most of the Intel chips, the cache will be fully occupied with the mating up of the results of the two instruction sets and the process of passing this result out to RAM. This is partly why the Intel chips that have a 1MB cpu cache are discernably slower than the chips that have the 1.5 MB cache. And AMD, of course has the advantage here because they researched out and were able to implement a 2MB cpu cache at least a year and half ago. (Why your AMD Athlon XP's are fast and hold their own relative to the new P4's.) The net effect is that an Intel hyper-threading cpu is having to work at least twice and maybe 3 times for each CPU instruction set, whereas if hyper-threading were not detected as multiple cpu’s by the program, the program would be working only once for each instruction set. But, for all of us with multiple CPU’s, we certainly don’t want the e-on software re-writing the high-end 3D programs to assume and use only a single cpu. I don't agree that it is a reasonable conclusion that "the problem points back to e-on software'. Especially not when you consider when the main architecture of the program was written versus when these new cpu's were developed and released. In fact, how much sense would it have made for e-on to decide to re-write the Vue program, knowing what its programmers have known about how this 'hyper-threading" really works - that it's kind of a sham? And, there is a moral to this story in here somewhere - or maybe two morals.(sp?) One moral is that those of us determined to play out on the bleeding edge of the technology have a responsibility to have a basic understanding of how the technology works. Not overly technical - just basic. We can't just go around reading the benchmarks. I dearly love CPU Mag (Computer Power User) and eagerly wait for it each month, but I can't limit my knowledge to that level of superficiality. The second moral, following the heels of the first one, is to try to have a realistic understanding and expectation for how a complicated, robust piece of software like Vue is going to be able to react to that various "coping strategies" of the main companies caught up in the chip wars. Try to think about which are the most intelligent decisions e-on software could make in these circumstances. The AMD guys made a heavy and profound investment in their chip architecture 2 years ago now. And from this has flowed a strong but simple and clean line of chips. Intel is a big company and cannot restructure overnight when caught up short. So they have to cope someway, and buy time through a series of incremental changes that advantage only the light end purchasers. Let me tell you, Microsoft Office does just great on hyper-threading. What should E-on software and the other big 3D program companies do in these circumstances? And, if you think this situation is difficult, I urge you to take a look at what's been shaping up between Intel and AMD for the next significant round of chip wars. Talk about wierdness!

My apologies for the sermon.

Forester, that is not necessarily true. As I said I also use 3dsmax. Max is optimized for single processor, dual-processor AND Intel SSE, SSE2 and HT instruction sets. 3dsmax does not suffer from the same problems as vue and P4 hyperthreading, yet it also works as expected on dual-processor machines. Not all software sees HT as dual-processors. Poorly written software, maybe, but not all software. Maybe I should do some 3dsmax benchmarks on my machines, to compare the results to my vue results. This would prove 3dsmax is indeed seeing the HT correctly and vue is not. Your arguement may make sense for regular vue, but Vue Pro specifically states on their Vue Pro product website: *Multi-processor rendering support for unlimited number of processors. *Optimized for G5 & P4 HT. You're saing it's not E-On's fault that hyperthreading sucks on their software, yet right there ON THEIR PRODUCT PAGE they claim to suppport HT technology. You're probably right though. Vue didn't bother to update Vue Pro to correctly use HT and instead figured "well, hyperthreading just makes the software think it is two CPU's...we already have dual-processing code, let's just slap a 'HT certfied' sticker on it and be done with it." I call this deceptive product labeling, but that isn't a first for e-on...ie the "pro" moniker of Vue Pro...what a joke...this app is anything but "pro." About the CPU cache, the older Athlons have a !256k! cache, not 2 mb. My P4 prescott has a 1 mb cache, 4x the cache on my AMD chip...so I'm not sure where you got that bit of info. Maybe you're thinking of the operton processors?

Was talking about the original problem, nahie, which I understood to be Vue 4.20.02 for Radelat. I did read and understand your post on Vue Pro. We all appreciate your digging out the info for Vue Pro, and for posting the comparative render results. I think the point I was trying to expand on - maybe explain further is that Vue 4, like many programs, does seem to see the HT chip as multiple processors. Well, perhaps the real point I was trying to make is that this doesn't mean that Vue 4 is "poorly written." It just means that the program was written before the HT chips came out, and that e-on has chosen to not write new code for Vue 4 to specifically distinguish and handle the HT chips. At least to this point. Whether you regard this decision as a sign of totally crapy software or I regard it as a decision that is extremely difficult for a company to make that is caught in the chip wars most certainly is a matter of personal opinion. I respect yours. (Oh, and I believe the Athlon XPs, which is what Radelat referred to, have a cache bigger than 256K. In fact, that's one of their two their main distinguishing features.)

Am not trying to generate a flame war here, nahie. I did apologize for contaminating with a sermon my main point - which is to explain in plain language what happens when a program confuses HT with the presence of multiple CPU's. It seems to me that a basic knowledge of how these things work would help people to make good investment decisions when upgrading their systems. It is very hard news to spend more than a grand only to find out that your new investment doesn't work well with one of your programs. Its then easy to decide that the software company stinks. The more constructive things here are to do as we started out. Radelat is to be thanked for posting the information he found. Others that help explain or that contribute by posting comparative render data that we all can use to help in making our own decisions are to be thanked. We need more of this, and we all benefit by it.

You're right of course. I was just trying to point out that none of us really know what is going on here. I don't think any of us here are software/hardware engineers, and even if we were, none of us worked on either the P4 processor or Vue software, so we don't know what is causing the problem, and we probably never can. All we can hope is to figure out what cpu works well with Vue. So far, I'd have to say my P4 prescott 3.0 ghz sucks...or more specifically that it sucks rendering vue scenes.

I only pointed out the cache issue because your information is incorrect and I don't think that misinformation about the cache will help us figure out what is going on here. I have an AMD XP 2400+ and it has 256 k cache. The 2600+ to 3200+ models have 512. I know this because I was evaluating all these factors when I was trying to figure out exactly what system to buy for the best vue rendering. I probably spent 3-4 hours going over this and in the end, I still made a poor decision it looks like. So yeah, I'm pissed at e-on/vue, intel and also at myself. Well maybe not pissed. In the end, the machine renders well and vue runs fine on it. So what can I complain about. I only spent $700 on the machine anyway...so even if it is slower than I expected it isn't too bad.

On the other hand, I love vue. It really isn't crappy software. But is has a ton of bugs, many more than I've EVER dealt with using any commercial software in my entire life, 10 yrs + using computers professionally. It is extremely frustrating dealing with all vue's bugs (I've probably notified vue tech support of 10+ very serious bugs and they fix some, let others slide...). I guess you could say I love to hate Vue Pro. Venting on the forums is the only way to let the frustration with Vue out...their tech support just says "we'll look into it." Most of the time nothing ever becomes of it.

I think the other poster was right...we should set up some benchmarks or something. But then there are a lot of weird factors that can influence render times...motherboard, memory speed, etc. In the end, maybe it is too much work for too little gain. I think the real moral of this thread should be...don't buy a P4 prescott if you want some kick-@$$ render times! Stick with AMD Athlon XPs! ;) EDIT: please post here if you want to do benchmarks and we can start a new thread, but if no one is interested, maybe we should forget it.

Message edited on: 08/17/2004 15:14

Thanks nahie. I really like the idea of starting another thread with posted render times and machine specs - for a specified pic on the Vue distribution disk. We can take either of these that were mentioned. Nahie, perhaps you'd like to start that thread. Perhaps re-post your data, and the other pieces that were posted here as well. I won't have my AMD FX53 put together until the weekend - have a programming problem to solve first - but then I'll post my contribution, as well as contributions for two more machines. How about requiring just the CPU, motherboard make and model, bus speed (FSB) stats if people have them, and make, model and amount of RAM? Writes to disk figure in here somewhere, too. So perhaps we should know if people are using standard IDE, Serial ATA or SCSI. Or, if this is too much to post, and people want to volunteer to nahie or myself, we could take any volunteered data, compile it, and then post the results in a separate thread in about 2 weeks. ??????????????

OK .. I may have read this wrong but... Forester stated basicly that the HT system isn't seeing a second processor so it's waiting,.. the point of HyperThreading is to make one processer act as 2. the HT aware software shouldn't slow down with HT on, but speed up, if it's working right, which I'm guessing it isn't with VUE. Now i'm no engineer,and i'm actually a Mac user mostly, but my understanding of hyperthreading is that the Processor often times stops whil it thinks about "what it has to do" during this time 80% of the power of said unit isn't being used. HT takes the machine and splits it into two units, 1. finger pointer/worker and 2.just worker Now while the finger pointing unit is thinking about what needs to be done next, asigns the work, and then does it's part, the worker only part is always working,it gets it's assignment from the finger pointer (who assigns plenty to keep it working constantly) though not as fast as actually having 2 processers, still better than the one sitting, planning work, but no actual work being done. did that make since? as to the benchmarks? I'd love to, capare macs against PC's, and get idea's on what PC setup's work the best!

I think the more info the better!! ( but it might flood some people) but hey if you know/have the info.. spread the news is my thoughts.

Attached Link: http://www.renderosity.com/messages.ez?Form.ShowMessage=1480121

I based my P4 buying decision on the following:

Bench Score/processor clock or speed rating. Using this method, the AMD XP processors (the 2600+ models) get a score of .401 bench units per speed unit. The P4 got .463 bench units per speed unit. So my reasoning was the P4 could do more work in Vue per speed rating. So I figured, with a P4 ghz rating matched with an AMD speed rating, the P4 would do more work. The fastest AMD XP is 3200+ so I figured a P4 at 3.0 ghz would get just as good if not better scores, and they were priced about the same.

What I forgot to take into account is that a dual processor system gets less than 2x the performace of a single processor. So in theory, a single AMD processor would get a much higher bench unit per speed unit score than the dual system divided by 2. That is where I messed up. Oh well. I'm going to render that scene they tested on that thread and see what speeds I get, then I'll post that here. EDIT: Scratch that, I don't have the scene they're using on my Vue Pro CD's and they're using Vue regular anyway, not pro, so I don't know if my benchmarks would help.

Message edited on: 08/17/2004 16:31

Good nahie! I've got both Vue4 and Vue Pro, and I'd sure be interested in having info for both - as I'm sure would a lot of others. If you wouldn't mind using the same scen nahie (or anybody else), I'll post it for download tonight. (Right now have got to run. Sudden storms and my husband just had to set a plane down in some wierd place. Colorado mountain weather is almost as much fun as that on the eastern seaboard this summer!)

thomllama; "OK .. I may have read this wrong but... Forester stated basicly that the HT system isn't seeing a second processor so it's waiting,.. the point of HyperThreading is to make one processer act as 2. the HT aware software shouldn't slow down with HT on, but speed up, if it's working right, which I'm guessing it isn't with VUE" And =there= is the fallacy that Intel has perpetrated with careful marketing jargon. Hyperthreading does no such thing; what it does is permit a second programming thread to run in addition to the main thread. There are parts of the P4 core that were added for this, creating sections of a second pipeline. Other parts of that 'second pipe' are actually the native parts of the first pipe that are indeed sitting idle while waiting for memory or HDD access, or some I/O function to complete. It -sounds- like you get two cores for the price of one...or in other words, something for nothing. You don't. You still only have -one- northbridge. One pool of main memory. One L1 cache. One L2 cache. One southbridge to handle drive access. The two pipelines have to share those resources, and the HT pipe is slave to the main pipe. But the way HT is built, it can be misidentified as dual processors on an OS that is not HT aware. Calls can be made that start a second thread in a P4, but when the main thread demands come in, the second thread is suspended and data shunted into the caches (which gives you your delays, particularly if that second thread is critical in some way. That cached data is protected, so the -efective- size of the caches that the main pipe uses varies, which also can introduce slowdown). In a true SMP system this would never happen; each chip would have its own dedicated northbridge and RAM, and the only real contention would be for southbridge drive access (general I/O requests having so much latency in them as a matter of nature they're essentially irrelevant); each chip would chug along with it's thread, using its system RAM to store the results until it's polling request for common drive access was acknowledged. As nahie pointed out, VuePro is HT aware; Vue4 is only MP aware (second note to self: proofread before hitting the send button). IMHO, the Athlon 64 is the best chip for Vue, pro or otherwise at the moment, for one reason. The memory controller is part of the CPU, and clocks at the chips speed. The frontside bus is still 800mhz at the moment (DDR 400), but the loss in the latency caused by having to step down the CPU requests to match the motherboard signal speed, then talk to the controller, then feed the data back at that lower speed, is impressive. www.theinquirer.net/?article=17906 This gives a rundown on what's coming in the chip wars, so far as true dual core chips. Note what is said about memory access.

ok.. i'm corrected :) you know WAY more than me on the subject.. that was just my impression from what I read... I'll just stay with my macs... :)

Hey forester it would be great if you can post that scene they were using. Don't forget to include texture maps if the scene needs them. My only concern is that scene won't be compatible with Vue Pro and/or will render slower than a scene built natively with Vue Pro. Guess we'll have to test it to find out... It would also be interesting to see how the same scene renders in Vue and Vue Pro...

nahie, could you start a new thread. I just posted a modified version of the WaitingRoom scene at the following address. I had to modify the scene because Eran used two pieces of vegetation that must be purchased separately fron E-on. So, now it is all standard vegs. http://www.expandingwave.com/waitingroom Remember, the scene needs to be 1600 x 1200 to be comparable. The more people we can invite to participate in this, the better and more useful. Thanks.

OK, but if you shut off HT, then it isn't an issue, right? When HT is shut off on my machine, Vue is WORSE than not only with it on, but also worse than the Athlon, a significantly older machine. This fact simply cannot be ignored. Additionally, I have now performed tests so far using Photoshop and combustion with and without HT and the the P4 system is smoking the Athlon, as it should. Although I haven't had a chance to test Maya yet, I'm not going to be surprised if it too renders significantly faster on the P4, with or without HT. There is no doubt in my mind that all roads lead back to Vue. Now, in all honesty, I SHOULD have built a new Athlon system. That would've taken care of the problem. :-) However, for some video and compositing processes the P4 has proven itself to be at an advantage, and that was my primary reason for going this route. What I've discovered here is simply that undfortunately Vue is not well coded for the P4 and/or the 875 chipset. Fortunately for my relationship with Vue, I still have two more machines that I will be upgrading. Although one is already slated for another P4, I will see to it that the existing XP 2600 system is updated to either and XP 3200 or some Athlon 64 variant. :-) Nonetheless, this issue needs to be brought up with E-ON, as there is obviously a SERIOUS problem with Vue and present-day P4 systems, and this apparently applies to Vue Pro as well.

It -should- be reported to E-on. It would probably be fairer, though, to say the VueVuePro is not optimized for the =Prescott=, rather than the generic P4 label (as the Prescott core has significant changes from previous P4 cores). And Ghu only knows what is in the chipset that was changed. It could be the code E-on used. It could also be the architectural changes in the core. Or the cache addressing. Or something about the electrical characteristics of the LGA-775 packaging. A bug in the northbridge (excuse me, an 'errata'). Or one of literally a thousand other things, or combination of things. I get pendantic at times on the issue of computers and software issues, for one simple reason. There's a meme that both Intel and Microsoft have been pushing for quite a few years; the general purpose computer as 'appliance'. It's not, and never will be. It is an intricate, cranky, infinitely flexible tool. And like any complex item, the trouble quite often is off to one side and three steps away from what it 'obviously' is. There haven't been howls of outrage from users of the P4 -previous- to the Prescott stepping; that in itself seems to indicate that it has something to do with the hardware (You might want to check those Geil memory sticks, though; I tried the brand twice, and had fits both times. Either the quality of the chips was variable, or the manufacture of the actual DIMM was. Color me Kingston Valueram). But it could still be a previously unknown bug in Vue that found the Water of Life due to one of those hardware changes. So many issues I've helped friends out with that -looked- like (a) turned out to be (x+4-w//y?) instead. There's so much synergy going on under the hood that its a miracle the things even work at times....

Radelat; On that AMD box? Check out the Athlon 64-3000+. It has half the cache of the 3200+, and falls within 2% of the faster chips' performance(as well as half the price). Socket 754 is going to be around for awhile, as AMD is migrating the Athlon to it, as well. But the 64-3000 is the cheapest in price, and I've been pleasantly surprised with how well behaved the native 32 bit mode is. Now if MS would get its thumb out and stop waiting on Intel to release XP-64, we could see some real performance changes....

forester, thanks for the scene. It opens and renders great in Vue Pro. I'm just unsure what settings should be used to render though. The previous benchmark used render:preview, render:final (at 800x450) and render:final to disk. Should we try render:final quality and render:broadcast at 1600x1200? Seems a little high to me but it is rendering fairly fast on my AMD XP 2100+ (says it will take 20-30 mins). Lets get a final spec before starting a new thread. Maybe to keep things simple, we should just say, render to screen, 1600x1200 at final quality? Any thoughts anyone? BTW Dale B, with my P4 prescott I'm using Corsair RAM and it seems fine to me. I have 2x512 sticks, and haven't had a problem with it yet. But my machine also uses the Intel 875 chipset...

I would definately recommend final render quality as I tried it out yesterday on my p4 hp xw4100 at superior quality and it took 12 hours to render, don't think we need to wait that long to see variations in render times.

Yeah, the Athlon 64-3000+ is one I've loked at. I also considered an FX, but it's still a bit too pricey. I don't have any probems using the "older" XP-3200 either, as I think it's still a strong contender. Certainly a lot cheaper at this point as well. As for problems with the Vue and the P4, I was referring to the Precott when I said "present-day P4s". I suppose I should've been clearer on that. I plan to use the earlier Northwood chip on the next system. I'll be very curious to see how Vue runs on that core. One annoying aspect of the prescott is the fan noise. It's a loud fan that's needed to cool down that reactor. Personaly I don't recommend a Prescott to anyone who's considering a P4 system for this reason alone. Still, no doubt Vue has a serious problem with Prescott and/or the 875 chipset, as I will now add Maya to list of programs that I've tested on the Prescott that smoked the old Athlon. There is absolutely no doubt in my mind that it's a problem with Vue. Unfortunately I think E-ON's reply on this issue will be the typical "we'll fix it in the next version" routine that most software publishers use. Now,as long as that next version is given to us who complain for FREE, I won't have a problem with that. :-)