Quad Core slower than Dual Core?

[rbaz]

We just purchased a couple of new workstations with dual Quadcore 2.66ghz processors (X5355). We have the first one set up and are testing it with some network jobs that we are rendering with MAX 8 and V_Ray 1.47 (Yeah, I know we're behind. We are waiting for a good break in animation production to make the switch to MAX 9 and V-Ray 1.5).

We noticed that the last machine we purchased, which is identical except that it has dual Dualcore 3ghz processors (5160), is actually rendering faster on most jobs than the Quadcore. When I look at the task manager, all 8 cores on the new machine are working during rendering but sometimes are hovering around the 14-20% cpu usage range instead of pegging at 100% like I would expect. There have been a couple of jobs where it is the opposite and it is about 80% faster than the Dual core but those are rare.

I have seen benchmarks on these 2 different chips that have shown these Quadcores to be about 50-60% faster than the Duals in MAX but that was either with the scanline or Mental Ray, don't recall. Is there an issue with V-Ray and Quadcore chips? If so, is it just with 1.47 and has it been improved with 1.5? Does it have to do with the subject matter being rendered? Or is it the chips themselves? ... or possibly sunspots? ... or the way I'm holding my tongue? ... or ...?

Anyway, I appreciate any info on the subject.

Thanks,

Richard

[re:FORM]

How much memory do you have in that machine? If the dual cores have 4Gb, then they can address 2Gb per core.... if the quad core has 4Gb, then its only 1Gb.... which could result in HD paging.

[RErender]

I've seen the same thing. We're still on 1.47 also and Max 8 (going to max 9 and RC4 soon though). We recently rented a few 2x Quadcores, for a while our scenes were rendering about 50 % faster than our 2x Dual Cores too. Then I started noticing that they were rendering slower than the the dual cores. Sine they were rentals and were leaving about a week after we noticed the issue we didn't spend any time troubleshooting it.

Some of the things I thought might be the reason are, bus saturation ( just not enough memory bandwidth, perhaps set off by many proxies, a lot of bitmaps or?), maybe they were overheating? Xeon will step down if too hot ( I never took a look at the task manager but if they were at 14% like yours than heat does not seem like the issue) or perhaps it was a network issue were they just couldn't pull resources fast enough to keep all the cores busy.

The latest RC's are faster than 1.47 but I doubt they would fix what you are seeing on your quads. About all you can do is keep track of what is different between the scenes that render fast and the ones that render slow and go from there. I am interested to hear more.

edit: Just read re:FORM's post sounds like another possibility, I'm not sure how much ram our rent-a-quads had, I'll find out on Monday.

[re:FORM]

Hey, if you dont mind me asking or going off topic, but what sort of price were you paying for the rentaquads?

[RErender]

Not sure how much, I'll see if I can find that out too on Monday.

[rbaz]

Both the Duos andthe Quads have 4 Gigs of RAM. Maybe that has something to do withit. The scenes that rendered faster were smaller scenes as I recall so that would make sense. We'll have to do some more specific testing this week.

I was hoping to move to 64bit Vista/MAX so we could bump up the RAM but the Vista thing makes me really nervous at this early stage.

How much memory do you have in that machine? If the dual cores have 4Gb, then they can address 2Gb per core.... if the quad core has 4Gb, then its only 1Gb.... which could result in HD paging.

[vlado]

You should upgrade to a newer release of V-Ray; the 1.47 version is not quite as well threaded as newer versions (e.g. there are some places where threads would stop and wait for each other when this was not really necessary). For recent builds we have tried to reduce this as much as possible.

Best regards,
Vlado

[rbaz]

Thanks for that info Vlado. Between upgrading and eventually moving to 64bit/more memory, I assume we should take full advantage of the quad chips. BTW, what is your take on XP64 vs. Vista 64 if we were to want to go 64 bit?

Thanks,

RB

You should upgrade to a newer release of V-Ray; the 1.47 version is not quite as well threaded as newer versions (e.g. there are some places where threads would stop and wait for each other when this was not really necessary). For recent builds we have tried to reduce this as much as possible.

Best regards,
Vlado

[vlado]

One problem with winXP 64-bit is that hardware drivers might be difficult to find; most hardware vendors seem to be focusing on supporting Vista 64-bit only, skipping WinXP 64-bit.

Other than that, things are the same as with the 32-bit versions - e.g. Vista takes a lot of resources for UI things, while XP is more modest in its memory requirements as far as the OS itsef is concerned.

Best regards,
Vlado

[rbaz]

Yes, Microsoft is very good at adding more bloat with each release.

So, are you running V-Ray on 64bit Vista and finding it to be a solid "ready for prime time" platform? We have standardized on Dell hardware with Nvidia Cards. I'm assuming that would help on the driver end. I have heard that Vista64 will not run legacy 32 bit drivers if they are not signed by Microsoft but as long as we can find drivers and avoid the Aero interface which looks cool but must take even more resources, would we be looking at a worthwhile jump to Vista64?

We are generally running MAX, AutoCAD, Photoshop and other Adobe apps, Combustion and sometimes things like Piranesi.

Opinions?

One problem with winXP 64-bit is that hardware drivers might be difficult to find; most hardware vendors seem to be focusing on supporting Vista 64-bit only, skipping WinXP 64-bit.

Other than that, things are the same as with the 32-bit versions - e.g. Vista takes a lot of resources for UI things, while XP is more modest in its memory requirements as far as the OS itsef is concerned.

Best regards,
Vlado

[gilpo]

I was about to post a topic like this.

We just bought 2, Dual Xeon 5335 systems and both render consistantly slower than our Dual Opteron 270's. We're averaging 2-4 minutes slower on the Xeons on a 15-minute-per-frame render. Both types of systems have 4gb of ram and are running WinXP 64, Max 9 and VRay 1.5 RC4. To rule out a memory issue, we put 8gb in one of the Xeons and it didn't affect render times.

What's interesting, is that when running the benchmark scene, both the Xeons and Opterons render in-line with what they should -- 1:30 for the Xeons, 3:30 for the Opterons.

In case this helps troubleshoot, our scene has about 20,000 objects. Around 16,000 of those objects are instanced vray proxies from about 60 unique meshes. The total poly count for the proxies is in the neighborhood of 800 million polys. During rendering, once the proxies are loaded, all 8 cores on the Xeons stay at 100% for the duration of the frame. All 8 buckets complete within 15 seconds of each other. Network utilization never spikes above 50% on our proxy and texture server. We are on a gigabit switched network. We're using dynamic memory set on 2gigs.

If anyone has any ideas, it would be appreciated, as we just spent $1000 more per system and got slower rendering systems.

Thanks in advance!

[vlado]

gilpo, it might take some tinkering with the scene to figure out what is causing the slowdown. Since the benchmark scene renders as expected, the problem might be in some specific component of the scene - e.g. textures or proxies or displacement. You can probably quickly try a few things:

(*) Without GI, and with a simple grey material;
(*) With textures disabled;
(*) Without proxies.

Best regards,
Vlado

[meanadam]

Finally.....
I was asking about this months ago.

Assuming gilpo is correct with the 8gb test - and there is NO ram per core issue, I am guessing this has to do more with Hardware and windows than anything. But still - how do the extra cores run the process without using more ram?!

Can we talk a min about cache, bus speed, ram clock, and page files?

We are sticking with qx6700s here, but we have the same cache. We recently went back to the 3gb switch (32bit still) where I read that the pagefile should be set to the same size as the physical memory. Not sure what difference this has made, but seems logical to me. I am guessing you guys are getting Ram bottlenecks somewhere. Do you monitor your ram throughput with ramclock or some such diagnostic? Has anybody overclocked the ram yet? Are you running 800 at 667? Maybe the bus is TOO fast?

[rbaz]

I have been unable to get or determine a definitive answer or solution for this issue so we are shipping our Quad-cores back and replacing them with Dual Dual-cores (5160s) which we have had great luck with. My opinion, and it is only that, is that this is similar to the 1st generation of Dual-cores from Intel which were basically 2 single cores slapped on a hunk of silicon, which underperformed and ran very hot. The next generation "true dual-cores", the 5100 series were way faster and ran much cooler. I think Intel has rushed these to market to try and beat AMD to the punch. They seem to work very well fro certain applications such as databases, etc. but when working with large files and heavy IO between cores, they fall down due to the inefficient architecture. My 2 cents.

Either way, I don't have time to R&D Intels chips. We have production to get done.

Cheers,

RB

[SnipeyX]

Well, we just got our first of three dual quad machines installed today, and are experiencing nearly identical rendertimes to our dual processor (single core) machines.

Though a coworker has a dual quad that we occaisionally utilize for rendering at night, at there are scenes where it blazes the older machines.

When we get done with our tight deadlines over these next couple weeks I'll do some tests with the scenes to see if I can find out why this is.