ProE on Windows XP 64 Professional

Bertil

I don't think so for the following reasons: a.. PTC has only ever had two or three implementation of Pro/e for 64 bit machines and those were HP-UX, Sun Solaris and XP Pro running on a limited number of Xeon machines, so if you don't have one of these choice workstations, you're probably SOL; b.. Pro/e is not a multi threaded app and seems incapable of taking advantage of multi-processor environments. It does benefit from the extended memory addressing of 64 bit, but that seems to be about it for advantages. So, you really need to be crunched for memory to take real advantage of 64 bit hardware/software combos; c.. 64 bit seems to suffer, speed wise, by the additional overhead and is not inherently faster than 32 bit processing (and runs 32 bit apps typically slower than a 32 bit machine), except for those tasks that can be done no other way; d.. 64 bit processing on Windows platforms is still in its infancy so the driver situation, the number of standard apps ported to 64 bit and connectivity issues still plague the 64 bit world and it lags in its adoption ~ another reason to recommend against it. David Janes

Bertil

I don't think so for the following reasons: a.. PTC has only ever had two or three implementation of Pro/e for 64 bit machines and those were HP-UX, Sun Solaris and XP Pro running on a limited number of Xeon machines, so if you don't have one of these choice workstations, you're probably SOL; b.. Pro/e is not a multi threaded app and seems incapable of taking advantage of multi-processor environments. It does benefit from the extended memory addressing of 64 bit, but that seems to be about it for advantages. So, you really need to be crunched for memory to take real advantage of 64 bit hardware/software combos; c.. 64 bit seems to suffer, speed wise, by the additional overhead and is not inherently faster than 32 bit processing (and runs 32 bit apps typically slower than a 32 bit machine), except for those tasks that can be done no other way; d.. 64 bit processing on Windows platforms is still in its infancy so the driver situation, the number of standard apps ported to 64 bit and connectivity issues still plague the 64 bit world and it lags in its adoption ~ another reason to recommend against it. David Janes

Bertil

I don't think so for the following reasons: a.. PTC has only ever had two or three implementation of Pro/e for 64 bit machines and those were HP-UX, Sun Solaris and XP Pro running on a limited number of Xeon machines, so if you don't have one of these choice workstations, you're probably SOL; b.. Pro/e is not a multi threaded app and seems incapable of taking advantage of multi-processor environments. It does benefit from the extended memory addressing of 64 bit, but that seems to be about it for advantages. So, you really need to be crunched for memory to take real advantage of 64 bit hardware/software combos; c.. 64 bit seems to suffer, speed wise, by the additional overhead and is not inherently faster than 32 bit processing (and runs 32 bit apps typically slower than a 32 bit machine), except for those tasks that can be done no other way; d.. 64 bit processing on Windows platforms is still in its infancy so the driver situation, the number of standard apps ported to 64 bit and connectivity issues still plague the 64 bit world and it lags in its adoption ~ another reason to recommend against it. David Janes

I guess what's missing from this discussion is some basic information: what are your memory needs, Bertil? Why are you considering going 64 bit?

David Janes

Bertil

I don't think so for the following reasons: a.. PTC has only ever had two or three implementation of Pro/e for 64 bit machines and those were HP-UX, Sun Solaris and XP Pro running on a limited number of Xeon machines, so if you don't have one of these choice workstations, you're probably SOL; b.. Pro/e is not a multi threaded app and seems incapable of taking advantage of multi-processor environments. It does benefit from the extended memory addressing of 64 bit, but that seems to be about it for advantages. So, you really need to be crunched for memory to take real advantage of 64 bit hardware/software combos; c.. 64 bit seems to suffer, speed wise, by the additional overhead and is not inherently faster than 32 bit processing (and runs 32 bit apps typically slower than a 32 bit machine), except for those tasks that can be done no other way; d.. 64 bit processing on Windows platforms is still in its infancy so the driver situation, the number of standard apps ported to 64 bit and connectivity issues still plague the 64 bit world and it lags in its adoption ~ another reason to recommend against it. David Janes

I guess what's missing from this discussion is some basic information: what are your memory needs, Bertil? Why are you considering going 64 bit?

David Janes

going 64 bit?

David Janes Ben's comments show that a 64 bit system is a good way of eliminating the memory restrictions built into 32 bit systems. But also consider setting the 3 gig switch in the XP boot.ini file. It extends useable memory. The Microsoft website has intructions for how to do this. You may also find the XP Help on "bootcfg" useful. Or Google this NG for 3 gig switch as this topic has come up before, but not recently.

David Janes

I second that. I used the 3 gig switch for over a year and it worked very well.

memory restrictions built into 32 bit systems. But also consider setting the 3 gig switch in the XP boot.ini file. It extends useable memory. The Microsoft website has intructions for how to do this. You may also find the XP Help on "bootcfg" useful. Or Google this NG for 3 gig switch as this topic has come up before, but not recently.

I second that. I used the 3 gig switch for over a year and it worked very well.

I've had good experience with it, too. As is Bertil, I was bumping into the memory ceiling, everything slowing down, freezing, crashing. Then IT installed the maximum 4 gigs of RAM, thinking this would cure the problem. It helped a little, but not enough until they set the /3G switch. It can have its down side as it reassigns a gig of system memory to user memory, but all the memory problems, slowness and crashing went away.

That said, it's the cheap and dirty way of extending the life of a system. And, if it doesn't work, if you're still hitting the ceiling, you are buying the 64 bit system. So, if it works, great, but recognize that it could be a temporary fix if your memory demands keep growing. Since memory has always come at a premium on the big, expensive workstations, Pro/e built in a lot of memory management tools that help greatly with the memory restrictions. I'm thinking of Simp Reps and shrinkwrapped assemblies for space claim objects and even the use of surface models which tend to be much lighter weight that hundreds of features. IOW, balancing the brute force method of bigger, faster hardware with some sophisticated techniques. The latter is where I have to most room to grow, the fewest people to convince, the most initiative and often, the biggest payoff.

David Janes

messagenews: snipped-for-privacy@q77g2000hsh.googlegroups.com...

memory restrictions built into 32 bit systems. But also consider setting the 3 gig switch in the XP boot.ini file. It extends useable memory. The Microsoft website has intructions for how to do this. You may also find the XP Help on "bootcfg" useful. Or Google this NG for 3 gig switch as this topic has come up before, but not recently.

memory ceiling, everything slowing down, freezing, crashing. Then IT installed the maximum 4 gigs of RAM, thinking this would cure the problem. It helped a little, but not enough until they set the /3G switch. It can have its down side as it reassigns a gig of system memory to user memory, but all the memory problems, slowness and crashing went away.

And, if it doesn't work, if you're still hitting the ceiling, you are buying the

64 bit system. So, if it works, great, but recognize that it could be a temporary fix if your memory demands keep growing. Since memory has always come at a premium on the big, expensive workstations, Pro/e built in a lot of memory management tools that help greatly with the memory restrictions. I'm thinking of Simp Reps and shrinkwrapped assemblies for space claim objects and even the use of surface models which tend to be much lighter weight that hundreds of features. IOW, balancing the brute force method of bigger, faster hardware with some sophisticated techniques. The latter is where I have to most room to grow, the fewest people to convince, the most initiative and often, the biggest payoff.

I ran ProE2001 (and later WF 3.0) on Windows XP (32 bit), Dual 2.3? GHz CPU, with 4 GB of ram. I used the /3GB switch with no problems, but still ocassionally hit the 3 GB memory limit when opening large assemblies, or working with 3D scan data (STL). Some computers in our facility had stability problems with the 3GB option.

We started purchasing some computers with Windows XP x64 about 2 years ago. The first computers had stability problems, seemingly related to video drivers, and only one printer in the office had 64 bit drivers available. Overtime the configuration was tweaked, new video and print drivers were released, and stability is much improved.

Now I'm running WF 3.0 on Windows XP x64, 64-bit, Dual 3 GHz Xeon (dual core), 16 GB of RAM. The CPU's are somewhat faster than the older machine the performance is improved. Stability is awesome. I no longer have problems with too little memory. I really make use of the extra memory and CPU when running CFD or FEA analysis, ProE . Most 32 bit software installs and runs fine on XP x64, but some software does not work at all, and 64 bit drivers still aren't available for some of our printers. For now, the workaround is to keep a 32 bit computer to run a couple of programs. Overall I'm much happier with the 64 bit machine than the 32 bit, but it really depends on what you're working on.

Dave

- snipped-for-privacy@q77g2000hsh.googlegroups.com...

ing the memory restrictions built into 32 bit systems. But also consider set= ting the 3 gig switch in the XP boot.ini file. It extends useable memory. Th= e Microsoft website has intructions for how to do this. You may also find th= e XP Help on "bootcfg" useful. Or Google this NG for 3 gig switch as this to= pic has come up before, but not recently.

the memory ceiling, everything slowing down, freezing, crashing. Then IT ins= talled the maximum 4 gigs of RAM, thinking this would cure the problem. It h= elped a little, but not enough until they set the /3G switch. It can have it= s down side as it reassigns a gig of system memory to user memory, but all t= he memory problems, slowness and crashing went away.

m. And, if it doesn't work, if you're still hitting the ceiling, you are buy= ing the 64 bit system. So, if it works, great, but recognize that it could b= e a temporary fix if your memory demands keep growing. Since memory has alwa= ys come at a premium on the big, expensive workstations, Pro/e built in a lo= t of memory management tools that help greatly with the memory restrictions.= I'm thinking of Simp Reps and shrinkwrapped assemblies for space claim obje= cts and even the use of surface models which tend to be much lighter weight = that hundreds of features. IOW, balancing the brute force method of bigger, = faster hardware with some sophisticated techniques. The latter is where I ha= ve to most room to grow, the fewest people to convince, the most initiative = and often, the biggest payoff.

Will 64 bit machines put carets in everyone's groups postings? So I can understand who said what?

messagenews: snipped-for-privacy@q77g2000hsh.googlegroups.com...

Thanks, that was very helpful, informative post.

David Janes

messagenews: snipped-for-privacy@q77g2000hsh.googlegroups.com...

Will 64 bit machines put carets in everyone's groups postings? So I can understand who said what?

______________________________

Sorry, my bad (I think). I had OE set to reply in HTML. Replying to that in

7-bit texter format strips the MIME/html code but doesn't deal with the result very well. However, it's yet another question as to what readers will run on 64 bit machines. Many, I suspect, are from 16 bit days and, if some 32 bit software doesn't run on 64 bit systems, the prognosis for 16 apps is pretty shaky.

David Janes

Yep, because there will be two carets instead of one. (1 64 bit caret =

2 32 bit carets) :)

Dave

Yuk yuk, Dave

I worked at a place that used 64 bit machines. They had many large models, but I didn't work in them so I can't speak to how well a 64 bit mahcine addresses large model issues.

I can say that the speed of the 64 bit machine was not any faster than a 32 bit machine with models that worked on a 32 bit machine.

I also was very frustrated that many programs did not run on a 64 bit machine that run on a 32 bit machine and finding drivers for hardware was difficult, if not impossible. I ran into this with a scanner that was a few years old.

i also had problems with WF3 and the analysis feature. i could not select features to measure the distance between them. The 64 bit version of wildfire 3 and the 32 bit versions that had the same build number (I'm guessing) are different code. There were bugs in the 64 bit version that were not there in the 32 bit viersion.

To get around some of the compatibility issues by loading vmware on the 64bit machine and built a 32bit guest machine on it. I was able to run the scanner with the 32 bit drivers on the virtual machine along with all my 32 bit versions of software that did not run on the

64bit machine.

If you need more memory for larger models, then I guess you have very few choices but to go to a 64 bit machine and OS. Just might want to keep a 32bit machine on your desk, or at least load a virtual machine on the 64 bit machine if you have software and hardware that will not run on a 64 bit machine.

There's my 2 cents.