Core 2 Extreme vs. Xeon Dual Core with Revit

[angelo]

We are looking for pure speed in Revit (we are working 50-150MB files using worksets and a central). Has anyone tried similar configurations with these two chips in Revit?

From what I've read elsewhere, the Core 2 Extreme might be a bit faster than the Xeon, but not as stable. Also, it appears there might be a premium on the Core 2 Extreme because it's so new (i.e. the fastest Core 2 on a Dell Precision 390 vs. the Xeon on the Dell Precision 490).

Revit is tough, because most of the benchmarks out there are for 3D rendering, which has almost no correlation for daily Revit production work.

Thanks for any input.

Angelo

[Wes Macaulay]

I think the sweet spot for Core 2 Duos is the E6700. The E6800 is more money than it's worth IMO. We haven't seen benchmarks pitting the E6700 against the fastest of the P4 EE processors, but my money is on the Core 2's

[iru69]

From what I've read elsewhere, the Core 2 Extreme might be a bit faster than the Xeon, but not as stable. Also, it appears there might be a premium on the Core 2 Extreme because it's so new (i.e. the fastest Core 2 on a Dell Precision 390 vs. the Xeon on the Dell Precision 490).

Just to clarify, since I've seen confusion on this subject before - the new "Woodcrest" Xeons (51xx series), like those used in the newest Precision 490s (and Mac Pros), are essentialy Xeon versions of the Core2. You're not going to see much difference in speed between similarly clocked Core2 and Xeon 51xx. The main reason to go with a Xeon over Core2 is if you want multiple processors (e.g. two dual-core cpus for a total of four cores). If you don't plan on going with two processors, there probably is not a great amount of benefit in going with the Precision 490 instead of the Precision 390.

I don't believe there's any measurable difference in stability between Xeon and Core2, but some would argue that some of the components in a Xeon systems are selected based on a higher level of standards than a typical Core2 system... which ultimately can result in a more stable and faster system.

I can't speak for the Xeon, but I primarily use a Precision 390 with the X6800 - it's been perfectly stable and very fast. I have to agree with Wes though that the E6700 (and Xeon 5150) is a better value. However, if you can spare the extra cash, go with the X6800 or the Xeon 5160.

[Bill McLees]

For those of us who are really cheap, the E6600 is the least expensive chip with the 4 Mb L2 cache. That may have a minimal effect on overall speed, but it's a reason to buy less than the most expensive chip. Regardless, our new machines are much faster than what they replaced.

On the other hand, buying more expensive hardware may well pay off when Revit 10 or 11 begins to take advantage of multiple cores or whatever. But for now, I'm betting with cheaper machines replaced more often.

[ron.sanpedro]

I think the sweet spot for Core 2 Duos is the E6700. The E6800 is more money than it's worth IMO. We haven't seen benchmarks pitting the E6700 against the fastest of the P4 EE processors, but my money is on the Core 2's

That is a bit of a sore spot in my opinion. Autodesk provides benchmarks for a task that is, at BEST less than 1% of our work, and something that the majority of Revit users will never do, and provides squat for benchmarks that actually relate to what we do all day, every day. My sense has always been that Revit can't really tell the difference between a $5000 computer and a $2000, but it would sure be nice to KNOW so that we can make better recommendations as to what hardware upgrades need to be made. We have a project with 100-150M files, and as many as 7 people working, and if we actually knew that a major hardware upgrade would help we would, but instead we have to guess because there just isn't any benchmarking. Lame, to say the least.
I hope that, along with a performance increase in R10, we finally see some mechanism for a solid, meaningful, benchmark. Something as simple as a standardized Journal file that can be times, perhaps tied into a Windows Script that actually does the timing. Then we can actually do some meaningful benchmarks and make informed decisions, rather than guessing and hoping.

Best,
Gordon

[Steven Campbell]

That is a bit of a sore spot in my opinion. Autodesk provides benchmarks for a task that is, at BEST less than 1% of our work

Gordon,
Let me clarify something here, Autodesk did not provide the benchmark in anyway shape or form. I provided it on my own, created on my own time. I created it because I saw a need plus I am a bit of a hardware nut. I hoped to extend it to more areas based on some of the feedback I received but due to professional and personal reason the time just was not there to do it.

Just for the record...
Steve

[ron.sanpedro]

Gordon,
Let me clarify something here, Autodesk did not provide the benchmark in anyway shape or form. I provided it on my own, created on my own time. I created it because I saw a need plus I am a bit of a hardware nut. I hoped to extend it to more areas based on some of the feedback I received but due to professional and personal reason the time just was not there to do it.

Just for the record...
Steve

Steve,
hopefully you didn't take my comment as a dig. My point is that I think Autodesk SHOULD provide a solid benchmark capability. I guess I did think that what was available was some sort of internal tool, not a user made tool. I think that makes the tool we do have all the more impressive, and the lack of tools from Autodesk all the more problematic.
On the topic of an expanded version, do you happen to have any solid documentation on the way the Journal file works? If I could get my head around that file I would certainly put some time in to helping to get some better tools. If you don't have something I may do a Support Request and see if Autodesk can provide something. I would assume the problem with a non-render benchmark is that it requires a ton of repetition to get a long enough sample time to be viable for comparison, whereas a Render benchmark just requires a complex enough model that the render takes a fair amount of time. I suspect a Windows Script that writes a very repetitive Journal is the answer. Something that draws a ton of walls and doors and such, then copies it all up a hundred levels, then copies that into 20 different towers, builds a bunch of views, turns on shadows in a bunch of them, makes an edit in a title block that is repeated a hundred times, etc. Sounds like a script is the only way to get a single Journal that is long enough to yield a meaningful result. Anyway, just thinking outloud now
And I will continue to hope that Autodesk produces something really solid that will work for all of us in the new release. And allow for Cadalyst or the like to do some meaningful hardware reviews.

best,
Gordon