This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C864FE.0CDA19F0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
We run 64bit Pro/E on a workstation and a server, 2 quadcore =
processsors, for those who need the extra memory. It does handle our =
largest models for those situations where needed. We design aircraft =
mods, so our files do tend to be quite large.
"Janes" <djanes@[EMAIL PROTECTED]
> wrote in message =
news:v5Ooj.20877$ov5.3216@[EMAIL PROTECTED]
"Bertil Rogmark" <bertil@[EMAIL PROTECTED]
> wrote in message =
news:%mLoj.3396$R_4.2427@[EMAIL PROTECTED]
Is it worthwile to go this way?
Bertil=20
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;=20
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;=20
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;=20
d.. 64 bit processing on Windows platforms is still in its infancy =
so the driver situation, the number of standard apps ****ted 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
------=_NextPart_000_000B_01C864FE.0CDA19F0
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 6.00.2900.3243" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>We run 64bit Pro/E on a workstation and =
a server, 2=20
quadcore processsors, for those who need the extra memory. It does =
handle our=20
largest models for those situations where needed. We design aircraft =
mods, so=20
our files do tend to be quite large.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Janes" <<A =
href=3D"mailto:djanes@[EMAIL PROTECTED]
">djanes@[EMAIL PROTECTED]
>> wrote=20
in message <A=20
=
href=3D"news:v5Ooj.20877$ov5.3216@[EMAIL PROTECTED]
">news:v5Ooj.20877$ov5.3216=
@[EMAIL PROTECTED]
>...</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Bertil Rogmark" <<A=20
href=3D"mailto:bertil@[EMAIL PROTECTED]
">bertil@[EMAIL PROTECTED]
>> wrote =
in message=20
<A=20
=
href=3D"news:%mLoj.3396$R_4.2427@[EMAIL PROTECTED]
">news:%mLoj.3396$R_4.242=
7@[EMAIL PROTECTED]
>...</DIV>Is=20
it worthwile to go this way?<BR><BR>Bertil <BR><BR></BLOCKQUOTE>
<DIV>I don't think so for the following reasons:</DIV>
<UL>
<LI>PTC has only ever had two or three implementation of =
Pro/e for=20
64 bit machines and those were HP-UX, Sun Solaris and XP Pro running =
on a=20
limited number of Xeon machines, so if you don't have one of =
these=20
choice workstations, you're probably SOL;=20
<LI>Pro/e is not a multi threaded app and seems incapable of taking=20
advantage of multi-processor environments. It does benefit from the =
extended=20
memory addressing of 64 bit, but that seems to be about it for =
advantages.=20
So, you really need to be crunched for memory to take real advantage =
of 64=20
bit hardware/software combos;=20
<LI>64 bit seems to suffer, speed wise, by the additional overhead =
and is=20
not inherently faster than 32 bit processing (and runs 32 bit apps =
typically=20
slower than a 32 bit machine), except for those tasks that can be =
done no=20
other way;=20
<LI>64 bit processing on Windows platforms is still in its infancy =
so the=20
driver situation, the number of standard apps ****ted to 64 bit and=20
connectivity issues still plague the 64 bit world and it lags in its =
adoption ~ another reason to recommend against it.</LI></UL>
<DIV>David Janes</DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000B_01C864FE.0CDA19F0--
|
