Speed of 64-bit Pro/E and Pro/M?

Well it's well established that 64 bit platform opens the door for making larger models. What isn't consistent is how the peformance
changes - the benchmarks I've seen show apps getting faster, getting slower, staying the same.
For those of you who have crossed the divide, has the performance improved or slowed, all other things held equal? Is memory usage changed?
Dave
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

I recently came across a PTC FAQ document that states the 64-bit version can be 5-20% slower than the 32-bit equivalent solution. Whether that's true in all cases leaves plenty of room for comment.
Dave
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Well it's well established that 64 bit platform opens the door for<BR>&gt; making larger models.&nbsp; What isn't consistent is how the peformance<BR>&gt; changes - the benchmarks I've seen show apps getting faster, getting<BR>&gt; slower, staying the same.<BR>&gt;<BR>&gt; For those of you who have crossed the divide, has the performance<BR>&gt; improved or slowed, all other things held equal?&nbsp; Is memory usage<BR>&gt; changed?<BR>&gt;<BR>&gt; Dave<BR><BR>I recently came across a PTC FAQ document that states the 64-bit<BR>version can be 5-20% slower than the 32-bit equivalent solution.<BR>Whether that's true in all cases leaves plenty of room for comment.<BR><BR>Dave<BR></DIV></BLOCKQUOTE> <DIV>I think you stated the most cogent and convincing argument in your first post. It's pretty black and white. I can't run it (assembly, analysis, Mechanica, Mechanisms, rendering, any highly memory/storage intensive function) in a 32 bit environment but I can (without errors, freezing, crashing) with 64 bit hardware, software and OS. If you're calculating advantage on a finer accuracy scale than this, I think PTC is correct: it weighs in favor of 32 bit architecture (and from everything I've seen, as well). But, perhaps, marginally in many cases. The rest of the argument is how do you compare systems? Eventually, by price, you won't be able to avoid 64 bit machines because they've become so much more prevalent; OSes you can get in any architecture, programs, as well. So it depends on those elusive bench marks which are a) few and far between when it comes to realistic Pro/e use and b) never compare at the margin of utility (where 32 bit is under stress). So, if you never have an assembly or analysis that runs over (by a Task Manager Process display of xtop.exe activity) about half of the 32 bit rated capacity, hey, no worries. If you're on or past the margin, get the 64 bit architecture because the demands will get worse, only worse. And your scale of comparison will be pass/fail, not minute percentage differences.</DIV> <DIV>&nbsp;</DIV> <DIV>David Janes</DIV></BODY></HTML>
------=
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
David Janes wrote:

It's pretty black and white. I can't run it (assembly, analysis, Mechanica, Mechanisms, rendering, any highly memory/storage intensive function) in a 32 bit environment but I can (without errors, freezing, crashing) with 64 bit hardware, software and OS. If you're calculating advantage on a finer accuracy scale than this, I think PTC is correct: it weighs in favor of 32 bit architecture (and from everything I've seen, as well). But, perhaps, marginally in many cases. The rest of the argument is how do you compare systems? Eventually, by price, you won't be able to avoid 64 bit machines because they've become so much more prevalent; OSes you can get in any architecture, programs, as well. So it depends on those elusive bench marks which are a) few and far between when it comes to realistic Pro/e use and b) never compare at the margin of utility (where 32 bit is under stress). So, if you never hav e an assembly or analysis that runs over (by a Task Manager Process display of xtop.exe activity) about half of the 32 bit rated capacity, hey, no worries. If you're on or past the margin, get the 64 bit architecture because the demands will get worse, only worse. And your scale of comparison will be pass/fail, not minute percentage differences.

It is not a black/white issue, since we don't run the same exact analysis all day every day. Experienced FEA users know there is almost always more simple and less resource-intensive set of assumptions.
If Mechanica turns out to run roughly the same speed in 64 bit platform, then it's a matter of cost and other issues whether to run on 64-bit. You gain the ability to run larger analyses, but if there is an overall performance penalty, then from a user point of view the tradeoff is between larger model limits vs. performance on smaller analyses.
So I ask again, if anyone has compared Pro/M in 32- and 64-bit platforms for raw performance.
Dave
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:<BR>&gt;&nbsp;&nbsp; &gt; Well it's well established that 64 bit platform opens the door for<BR>&gt;&nbsp;&nbsp; &gt; making larger models.&nbsp; What isn't consistent is how the peformance<BR>&gt;&nbsp;&nbsp; &gt; changes - the benchmarks I've seen show apps getting faster, getting<BR>&gt;&nbsp;&nbsp; &gt; slower, staying the same.<BR>&gt;&nbsp;&nbsp; &gt;<BR>&gt;&nbsp;&nbsp; &gt; For those of you who have crossed the divide, has the performance<BR>&gt;&nbsp;&nbsp; &gt; improved or slowed, all other things held equal?&nbsp; Is memory usage<BR>&gt;&nbsp;&nbsp; &gt; changed?<BR>&gt;&nbsp;&nbsp; &gt;<BR>&gt;&nbsp;&nbsp; &gt; Dave<BR>&gt; <BR>&gt;&nbsp;&nbsp; I recently came across a PTC FAQ document that states the 64-bit<BR>&gt;&nbsp;&nbsp; version can be 5-20% slower than the 32-bit equivalent solution.<BR>&gt;&nbsp;&nbsp; Whether that's true in all cases leaves plenty of room for comment.<BR>&gt; <BR>&gt;&nbsp;&nbsp; Dave<BR>&gt; <BR>&gt; I think you stated the most cogent and convincing argument in your first post. It's pretty black and white. I can't run it (assembly, analysis, Mechanica, Mechanisms, rendering, any highly memory/storage intensive function) in a 32 bit environment but I can (without errors, freezing, crashing) with 64 bit hardware, software and OS. If you're calculating advantage on a finer accuracy scale than this, I think PTC is correct: it weighs in favor of 32 bit architecture (and from everything I've seen, as well). But, perhaps, marginally in many cases. The rest of the argument is how do you compare systems? Eventually, by price, you won't be able to avoid 64 bit machines because they've become so much more prevalent; OSes you can get in any architecture, programs, as well. So it depends on those elusive bench marks which are a) few and far between when it comes to realistic Pro/e use and b) never compare at the margin of utility (where 32 bit is under stress). So, if you never hav<BR>e an assembly or analysis that runs over (by a Task Manager Process display of xtop.exe activity) about half of the 32 bit rated capacity, hey, no worries. If you're on or past the margin, get the 64 bit architecture because the demands will get worse, only worse. And your scale of comparison will be pass/fail, not minute percentage differences.<BR>&gt; <BR>&gt; David Janes<BR><BR>It is not a black/white issue, since we don't run the same exact <BR>analysis all day every day.&nbsp; Experienced FEA users know there is almost <BR>always more simple and less resource-intensive set of assumptions.<BR><BR>If Mechanica turns out to run roughly the same speed in 64 bit platform, <BR>then it's a matter of cost and other issues whether to run on 64-bit. <BR>You gain the ability to run larger analyses, but if there is an overall <BR>performance penalty, then from a user point of view the tradeoff is <BR>between larger model limits vs. performance on smaller analyses.<BR><BR>So I ask again, if anyone has compared Pro/M in 32- and 64-bit platforms <BR>for raw performance.<BR><BR>Dave</BLOCKQUOTE> <DIV>I'd suggest you check here for the broadest, most general experience:</DIV> <DIV><A href="http://proesite.com /">http://proesite.com /</A>&nbsp;and check the benchmarks for 32 and 64 bit machines. Hopefully, this represents 32 bit machines running 32 bit apps and 64 bit machines running 64 bit apps and not 64 bit machines/OSes running 32 bit apps. These can be very difficult, very complicated analyses, requiring testing professionals to get involved with their scientifially set up testing labs (it's all about the numbers). And the numbers can be all about the test set up (witness the number of different results from the same machine.) But, in general, note that the results are more than twice the time for the 64 bit machines.</DIV> <DIV>&nbsp;</DIV> <DIV>David Janes</DIV></BODY></HTML>
------=
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
w/4GB running Win XP64.
The 370 bogged down and ran out of speed part way through the analysis. It did finish, but the CPU was running at 100%. The 390 plowed right through it in 64% of the 370 time. The 670 plowed through it in 67% of the 370 time.
Your numbers may vary, depending on actual machine specs.
--
Ben



Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
At my last company we were hitting the memory brick wall on 32 bit. As soon as we went from a 4GB 32 bit PC to a 12GB 64 bit PC some analysis were reduced from 24 hours to 3 hours. Bit it did crash a bit more often.
Does anyone know what the benefits of Vista might be? 32 bit & 64 bit?
Ant
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ant wrote:

I'm downloading evaluation copy of Solaris, gonna give it a try in some heavy promechanica run. Konrad
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ant wrote:

Based on what I know of Vista, it does not change anything w.r.t. memory size, etc compared to XP Pro 32 and 64 bit. Except that Vista uses more resources for itself, all other things held equal.
Dave
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
my last company we were hitting the memory brick wall on 32 bit.<BR>As soon as we went from a 4GB 32 bit PC to a 12GB 64 bit PC some<BR>analysis were reduced from 24 hours to 3 hours.&nbsp; Bit it did crash a<BR>bit more often.<BR><BR>Does anyone know what the benefits of Vista might be?&nbsp; 32 bit &amp; 64<BR>bit?<BR><BR>Ant<BR></BLOCKQUOTE> <DIV>That's a very good question and I don't know the answer. But, from all I've heard, Vista is simply XP Plus, so it more or less depends on what you found XP to be and what you thought of its limitations. One thing I've not seen is a list of enhancements over XP or XP limitations that got surpassed with Vista. IOW, I've not seen one single advantage to upgrading.</DIV> <DIV>&nbsp;</DIV> <DIV>David Janes</DIV></BODY></HTML>
------=
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Someone told me that you can access usb stick memory when using vista to prevent it from swapping to the HDD as much. I don't know if this applies to Vista 32 bit though.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
and ran out of speed part way through the analysis. It <BR>did finish, but the CPU was running at 100%.<BR>The 390 plowed right through it in 64% of the 370 time.<BR>The 670 plowed through it in 67% of the 370 time.<BR><BR>Your numbers may vary, depending on actual machine specs.<BR><BR>-- <BR>Ben <BR><BR></BLOCKQUOTE> <DIV>The numbers are helpful, Ben, thanks for the insight. And because I think the numbers can, at times, be helpful, I presented the somewhat bigger picture you can get from Corten's Proesite.com. But I'm always baffled by how to evaluate the results. Yours were surprising. I would have expected the numbers for the 390, with its several advantages, (2x memory, dual core processor, 50% faster FSB and RAM) to be much better than a mere 67% of the bogged down machine. The doubled RAM alone should have given it an enormous advantage, but, with a dual core processor that didn't even exist when the 370 was released, the 390's times should have been less than half those of the 370 (my guestimate from other reviews). But the most surprising thing is the results of the of the 670 (assuming no dual core processor) with no apparent advantage over the 390, other than 64 bit architecture, and it's&nbsp;50%&nbsp;faster! for no apparent reason!!! that really is surprising. Any theories of why? Possibly that, for reliable results, (i.e., where interpretation can be better than guesswork), this type of testing ought to be left to testing professionals!?! It seems like, when those professionals do that kind of test, they set up a 32 bit Dell 670 system along side a 64 bit Dell 670 system (no hardware/software difference save the architecture) and run the same test on each. Those results might say something about the advantages (again, under what conditions and levels of stress to the system) of using a particular architecture. But I don't need a 3 machine faceoff to tell me&nbsp;I want&nbsp;a 64 bit machine if I'm regularly exceeding memory limits and freezing/crashing the analysis!! So, the issue, in my estimation, comes back to what I raised in my original post: get the right tool for the job. If you're a tin or silver smith, you don't need the rock crushing 6 pound sledge, you need the half ounce ball peen. It's a question of scale ~ your problems vs your resources: if they are evenly matched, you'll quickly and easily exceed them. Then you need to acquire more resources. 4 gigs is the addressable limit on 32 bit OSes; when you need 6, 8, 16, you need a 64 bit system. Also true&nbsp;if you know you are outgrowing your present system because of constantly greater demands on resources. So, it's demands vs resources PLUS tendencies.</DIV> <DIV>&nbsp;</DIV> <DIV>Anyway, thanks for the faceoff. It was interesting and thought provoking. Doubtless you learned some things&nbsp;as well.</DIV> <DIV>&nbsp;</DIV> <DIV>David Janes</DIV></BODY></HTML>
------=
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Thanks Ben.
Today I set up RAID 1 on my wife's server and that has liberated a couple of hard drives. So this weekend I'll install XP Pro 64 bit on one of them and Pro/E, Pro/M 64 bit also.
This way I can do a test with nearly all other things held equal. The system will only have 2GB of RAM, but should be plenty sufficient to get a raw speed comparison for modestly sized models.
Dave
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
XP64.<BR>&gt;<BR>&gt; The 370 bogged down and ran out of speed part way through the analysis. It<BR>&gt; did finish, but the CPU was running at 100%.<BR>&gt; The 390 plowed right through it in 64% of the 370 time.<BR>&gt; The 670 plowed through it in 67% of the 370 time.<BR>&gt;<BR>&gt; Your numbers may vary, depending on actual machine specs.<BR>&gt;<BR>&gt; --<BR>&gt; Ben<BR><BR>Thanks Ben.<BR><BR>Today I set up RAID 1 on my wife's server and that has liberated a<BR>couple of hard drives.&nbsp; So this weekend I'll install XP Pro 64 bit on<BR>one of them and Pro/E, Pro/M 64 bit also.<BR><BR>This way I can do a test with nearly all other things held equal.&nbsp; The<BR>system will only have 2GB of RAM, but should be plenty sufficient to<BR>get a raw speed comparison for modestly sized models.<BR><BR>Dave<BR></BLOCKQUOTE> <DIV>The one thing that I've never seen measured is a standalone license of Pro/e vs a networked one. Incomprehensible, considering how heavily networked Pro/e is and how MUCH this can influence performance. And HD speed is also hardly ever quantified. But I have experienced huge delays when Pro/e decides to start disk swapping. Good luck on your analysis. Submit to proesite for comparison value, especially to compare a few of your own configs to the average. Again, what it means, for troubleshooting purposes, I'm not sure.</DIV> <DIV>&nbsp;</DIV> <DIV>David Janes</DIV></BODY></HTML>
------=
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
David Janes wrote:

I've just put 2 discs to raid0. Files and windows' swap is on it. Runs way faster, but I couldn't measure any numbers. I feel that putting more discs to that raid would get it even faster, but the difference in my case wouldn't be that big. I think that setting another disc/raid so I could put system swap on one and pro/m temp files on another would be better. Try WindowsStart-Programs-AdministativeTools-Performance. By default it displays disc queue in green. If you have long moments of 100% disc queue and simultaneously 0% processor load- you need a faster disc or raid. Maybe next week I'll find enough time to run pro/m on solaris- I can't sleep not being sure whether it manages memory/disc better than win. Konrad
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

vs a networked one. Incomprehensible, considering how heavily networked Pro/e is and how MUCH this can influence performance.
Interesting question. However, my understanding is that the license server traffic is somewhere between tiny and miniscule. So I don't see how that could affect performance.

As with anything, RAM is faster than HDD swapping. Faster hard drives almost always cost more than adding more RAM, and are substantially lower bang-for-the-buck. If disk swapping is slowing you down, put in RAM until the swapping stops.

especially to compare a few of your own configs to the average. Again, what it means, for troubleshooting purposes, I'm not sure.
My intent to compare Mechanica runtimes isn't supported bye the OCUS benchmark, but I'll try to run that too if I find time. Is it true that the 32- and 64- bit versions are indeed identical scripts?
I'm a little consumed right now with configuring a new SBS2003 arrangement for my spouse's company. This 32- vs. 64- comparison is not on a pressing schedule.
Dave

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@yahooooooo.com wrote:

Pro/m makes a lot of temporary files. For my analyzes it can be hundreds of gigabytes. How much RAM can I put into a motherboard? In my opinion, as long as disc operation doesn't slow down the processor- it's the processor speed that has the biggest impact on overall productivity. Sure, the less RAM, the less memory you can give the solver- and the more often a temp file is being dumped to disc. But the worst thing you can do is to assign too much memory to solver, because you end up with system's paging mechanism and that clogs the computer totally. After many long battles, I still cannot find good rule of thumb to determine what is the optimum amount of memory assigned to the solver- it depends not only on RAM, but also on the job to be done. Does anybody have any good advice on it? Konrad
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
KA wrote:

Good point. Some models are large in footprint, and generate huge temp files, models need a lot of RAM and CPU time but don't create large temp files. I totally agree - if you're seeing gigs upon gigs being written to disk then a RAID0 setup is worthwhile.

PTC once told us to set it for 40% of the system RAM. It seems to work ok for us, although the parameter hasn't seem to make much difference either way.
Dave
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
David Geesaman wrote:

With 4 gigs of RAM I set it to 1024MB and quite quickly Task Manager says that allocated memory is over 4 gigabytes. Konrad
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ben Loosli wrote:

Can you give any numbers about the study? How many nodes/edges/parts/contacts, SPI/MPI? Max eq. order? Regular or iterative solver? Standalone or integrated pro/m? Konrad
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.