Does SW support 64 bit processing

Short answer: No, not yet.

Long answer: For SWX to support 64 bit computing, it would first need a 64 bit OS. MS has not released its 64 bit Windows OS yet. Secondly, SWX would then need to release a 64 bit edition itself. This all takes some time. That said, I would assume SWX is working on a 64 bit version at some level, even though I have not heard of any 64 bit SWX rumors.

Thus, for 64 bit SWX, we first need to wait until MS releases their 64 bit OS. Then we will need to wait for SWX to release their own 64 bit version.

In the mean time: You can upgrade by purchasing an Athlon 64 (or Opteron) system and increasing your RAM (1.5-2.0 Gig minimum IMO). The Athlon 64 is a 64 bit processor, but it also performs very well with 32 bit applications. Thus, you are gaining performance now, while you are also ready when the switch to 64 bit is here.

Also, with regards to SWX performance in general, there are many tips and tricks that can have a large impact on performance. Do a search and I am sure can come up with many tips. Here are a few of my own:

1.) Make sure the Use software OpenGL is not enabled 2.) Make sure verification on rebuild is checked OFF 3.) Use low quality transparency 4.) Use lightweight parts 5.) Use large assembly mode 6.) Use simplified configuration with unnecessary components suppressed 7.) Be judicious with your use of incontext features. These can dramatically increase rebuild time. 8.) Uncheck Save Edrawing data

I'd expect that keeping entity counts as low as possible might also help. People always like to get fancy and do things like modeling threads .... added information that is rarely actually needed to control intent or make the parts but lets them make pretty pictures and brag about their model sizes.

Keep disks defragmented. Best way may be to copy the files to another disk or backup media, delete them from the current (clean OS installed) disk and copy them back (verify before doing delete). I suspect that that method keeps files in common directories close together and that normal MS "defrag" does not .... thus the MS method does not reduce disk seeks times as much as it might.

Add scratch space on the disk before applications software (SW as an example) or data files ... this *should* put it near the OD of the disk which may be faster to read & write, depending.

Others no doubt know more (I hope).

i think this only works for a *nix OS. I don't think (could be wrong) that just moving the files back necessarily defrags them.

Tho as an added step, rather than just deleting them, reformat the partition. (you DO have all the SW files on a separate partition, right?)

not that linux filesystems fragment all that much, but that is the method for "defragging" a linux filesystem.

never heard of that one.

-nick e.

Paul,

This sounds right from what I've read, but the sad news I've read,.. apps which are converted/compiled to the 64 bit OS are not faster, in fact slower and the gains are only with access and sharing of the larger registers or more ram access.

That is, if/when SW is compiled for windoze 64, it's ain't going to be faster but slower overall. Although, larger data sets will benefit relative to the current 32 bit bottle necks and ram limits.

Something to keep in mind when sales people start selling 64 bit hype.

..

kellnerp wrote:

Correct. And for the larger registers, remember they will help only when manipulating integer numbers larger than 2^32 (~4'000'000'000) or bitsets. CADs use double precision floating numbers that already are 64 bits, and already manipulated with 96 bits registers in 32 bits CPUs. So there is nothing to expect from there, which leaves us with the ram size benefit.

We'll see... but I believe the challenge is more at Parasolid and perhaps D-Cubed to support new CPU architectures, especially parallelism (HyperThreading and its successors...)

In short, CAD is an app where 2x32 > 64.

But could that not be done as single precision 64 bit math thus reducing cycles per operation on a 64 bit CPU?

And most CAD/CAM work is float intensive ... about the only integer-type data would be entity pointers and text strings.

I suspect that it does. They are copied as sequential files one by one and in an order ... fragged files can, I think, just be blocks all over the disk, each pointing to the next in the sequence and files in a common directory about anyplace that they fit on the disk and it's not required that they be near each other.

The primary partition is probably fastest to access ... others are probably farther away and seeking from partition to partition ... but perhaps the parts and scratch (that can be on UNIX IIRC) could be on different disks, allowing a decrease in IO waits.

Perhaps someone has a background utility program that tries to move files that are acessed the most to the OD of the disk while also defragmenting everything else and keeping files in a directory nearby. Or follows user-defined rules. Be nice to move all the unused OS files to slow access ..

Old ComputerVision trick on the CGOS platform ... load the executables on the outside of the disk and the parts next & docs & text on the inside. A lot more bits per rev pass the heads on the outside .... and the seek time from cylinder to adjacent cylinder is less. Don't even know if it can be done these days on PCs but I suspcct that the disks are filled from the outside in anyway .. hence the suggested order to install things on the disk in. Perhaps installing the minimal OS first, then the applications software (SW) then any other software ..

Still hoping others here know more ....

IDE for OS. SCSI for data?

Thin client setup? All OS files on separate computer.

Linux Live CD even. (like MandrakeMove, Knoppix, etc)

--nick e.

I just asked this question to a regional technical manager at SolidWorks in the same regard because we are going to start a PC swap program here where I work. I had asked if it would be beneficial before 2004 is over that SolidWorks would support a 64 bit OS and PC. The comment I received back is classic SolidWorks.

"I cannot comment on that yet."

At least the word "yet" was used in that statement. My guess is that you will hear about it at SolidWorks World. Much of what is needed is also controlled by how ready the Parasolid kernel is for 64 bit.

I do hope to hear something from SW World to give some direction that I should take in PC recommendations.

Ken

All we really know is that the SW logo was visible on stage at the Opteron's launch last spring.