64 BIT Advantages?

I've read some of the threads here regarding 64 bit processors and OSs
and SillyWorks...

Here's the deal: Here at the company I work for we are regularly
running out of memory with SolidWorks. We have machines with 4GB
memory and 3GB switch and this definately helps in most cases, but in
dealing with top-level assys and fully-resolving them for PDM check-in
we're running into roadblocks of memory usage.

So, I realize that we're still waiting for XP64 to become available.
Has anyone been able to download and test SWX with 64bit hardware and
additional memory? If so, did it work?

Also, some clarification please on AMD 64 -- do these currently run
with WinXP 32 bit? If so, does this allow you to run with more that
4GB memory?

Thanks

 

Last question first. I am typing this on an AMD64 FX53 based system
with 2GB ram. It is running flawlessly in 32bit mode and it is fast.

As far as trying to run SW (a 32bit application) on the 64 bit version
of Windoze. Good Luck. SW is not compiled to run on 64 bit so what I
think you will get is a 64 bit OS trying to run a 32bit application in
some kind of compatibility mode. May the schwartz be with you (from
SpaceBalls, the Movie).

My guess is that you are making your assemblies too large. Obviously SW
is catching this error and trying to correct it. LOL

 

Ahhah, you guys....

Years ago we went thru the same thing from Win 3.1 (16bit ) to Win 95
(32-bit), right?

As many have said, it will run, it just won't run faster (maybe even a
bit slower) which sucks, but the memory thing is the real issue here.

Can you run more than 4GB on regular WinXP (32 bit) if you are using an
AMD64 cpu? Of so, has anyone been able to open something with this
hardware that you couldn't before?

Thanks,

Todd

 

Probably not. If the program doesn't know it can run in 64bit memory I
doubt you could expect it too. I think you are feeling the pain and I
am sorry but I am trying not to give you a false hope.

 

Actually there were real practical problems with 16 bit systems.
Integer math issues, among other things.
Count the entities in your part. What happened if you tried to
have one more than the maximum integer 16 bits could count to
((2**15)-1 IIRC)?

In many systems even "deleted" entities still counted
as they had once had an integer pointer in the database and each
new entity got an integer pointer one greater than the last used
integer.

Then there were 16 or 32 bit floating math "errors", rounding
& truncation issues, mush less apparent on 32/64 bit math systems.
Think repeated trig functions, as in rotation, each with errors that
compound ....

 

And 9,000 components just isn't a large number when fasteners are
included so that they can be included in the BOM.

 

With the advent of Smart Fasterners the component count grew by leaps
and bounds and performance was reduced to creaks and groans.

 

OK, put em in by hand. The effect on assembly performance is the same.
Same goes for patterened components. This kind a "little stuff" causes
the part count to grow quickly and performance to suffer commensurately.