Multi-Core CPUs & SolidWorks?

don't expect too much : CAD has no clear multithreadad structure. Think about the features dependency tree : theres is little you can do in parallel. Read parellizing some long to rebuild features like shells should be possible...
So with dual cores, you can read your mails while your CAD rebuilds... With quad cores, you might have some FEA running for hours while you're designing something else.

Read However, parellizing some long to rebuild features like shells should AND...with Microsoft trying to upset the OpenGL display system with its own "Java Killer" methods of trying to establish its OWN PROPRIETARY graphics display system, we seem to be entering another possible arena for slowdowns in SolidWorks.
I REALLY REALLY DETEST MONOPOLIES!
Are we going to get UNIX support before MicroSoft squishes us all?
Bo

Then why, in the may issues of Desktop Engineering, do dual Xeon systems blow everything away on the SPECapc Solidworks 2005 tests?
It makes it look like this 'don't bother with dual processors' stuff is not accurate.

RaceBikesOrWork wrote in news:1179139255.845232.295030 @w5g2000hsg.googlegroups.com:
The explanation is in the linked article. The solid modeling kernel and a few other key components do use multithreading where possible. So, multiple Xeon processors will have some advantage over single Xeon. The issue is whether it's worth the extra cost.

For certain types of models, I think dual core does have a huge positive impact. I haven't taken the time yet to research this fully, but on several models, I have seen both processors pegged at 100%, not for the entire rebuild, but maybe for 60-40% of the rebuild. My guess is that these are multibody models or surface models which are normally multibody. Assemblies and drawings should also benefit from dual threading. The test is over a year old now I think, but I pitted my dual core AMD X2 4800+ against a single core AMD FX57, and sometimes, but not on every model, the 4800+ came out on top. The FX57 was at the time the fastest single core available.

Slightly OT but ...
If one was to run SWX on a dual core (or twin CPU) PC it would be possible to start 2 sessions of SWX and force 1 session to run on core (or processor) A and the second on core (or processor) B?
Kev

It is possible, but I've never actually done it. IIRC the process is to find the sldworks.exe process in the task manager, right click on it and find "set processor affinity". It shouldn't be necessary though, because the OS will automatically make sure that two separate high-load threads run on separate cores. I'm not sure if Windows optimally manages multi-socket multi-core systems (there would be some memory bandwidth and latency issues) but for a single dual-core CPU you shouldn't need to set anything.

See my postings to the SPECapc thread that was current as of a day or two ago. SPECapc DOES NOT measure CPU performance, it measures graphics performance. If you want to see CPU performance, take a long to rebuild part and run it on difference machines. Or run Ship in a Bottle or STAR2.1. Did the Xeon's have some big expensive graphics card in them also?
Multicore machines can greatly speed up SW in theory. Consider that in an assembly any part that does not have in context features can be rebuilt simultaneously with any other similar part. The solution of mates is, I believe, a process that can be parallelized. But it will take the vendors that SW licenses from to change to get this to work. SW is at the mercy of it's vendors and long is that list.
Consider also that in theory parts can be sped up when the feature tree has many branches starting high up because each branch is independent.
In fact, multicore machines do not make more than a few percent difference with anything but drawings and PhotoWorks.
TOP

Theoretically, yes.
You would have to start both sessions of SWX. Then go into the Windows Task Manager and find the processes for each session. You can set the affinity of each process to a different core/chip/processor.
--Scott
, alphawave wrote:

You probably don't want or need to set affinity. The OS should divvy up the clock cycles just like it does when a single SW process is running. Since SW is not likely to be running full speed simultaneously on both CPUs you will give the OS a chance to find the best solution.
If you do set affinity then when those times arise that SW can utilize both CPUs it won't and will therefore run a few percent slower.
TOP

Read However, parellizing some long to rebuild features like shells should The thing I don't get is why the CAD industry doesn't jettison Open GL and go with Direct X. It's a virtual certainty there is more work and $$$ going into the developement of Direct X than Open GL.

1. OpenGL is open, direct X is not. 2. OpenGL works on any OS 3. There is a lot invested in the hardware 4. Work and devlopment doesn't always translate into performance and stability. 5. There is no perceived need. Can directX make drawings faster? Can it shorten rebuild times in drawings and large assemblies?

Here is an interesting link on the subject.

This is simply NOT TRUE. SPECapc results scale directly with CPU performance. If anything, the SPECapc for SolidWorks benchmark understates the importance of the graphics card.
For example, in benchmark testing conducted by CADCAMnet, the Quadro FX4500 outperforms the FX550 by only 5.7% (294 secs vs 312 secs.) Similar results have been reported by Desktop Engineering, MCADonline and other publications.
SPEC ViewPerf is another matter entirely. Viewperfs are synthetic benchmarks that are highly skewed to the graphics card. In my experience, they bear little resemblance to real-world results.

That's obvious. How does that matter?
Does Solidworks? Neither does any other CAD program.
Which will all be obsolete three years after purchase (in other words "invested in hardware" is not a compelling reason).
True but then when you have more people working the problem you're likely to get it right sooner.
Neither Direct X or Open GL are going to do anything to speed up rebuild times.

Yup, a proprietary graphics standard will allow a monopoly to dictate what platform CAD runs on. Right now there is a choice. Several OS support serious CAD. Unix - CATIA, UG, Pro/E, and perhaps some lesser known Windows XP - The above plus mid range modelers and AutoCAD Windows NT and 2k - Ditto XP but only older versions. MaxOS - SolidWorks, and others (don't know if they use OGL or something else) Linux - Pro/E and others. I invest in high end graphics cards with a much longer time horizon since at least as far as SW is concerned it only takes a CPU and motherboard upgrade to keep up at minimum cost.
If it ain't broke, why fix it? What in the world is wrong with OpenGL as far as CAD is concerned? I have yet to see a post on the NG complaining about graphics issues other than driver problems.
If it is MicroSoft throwing people and money on the problem don't bank on it. They haven't gotten the OS right yet and it has been 14 or 15 years since New Technology (NT) was going to save the world from Unix and MAC.
SW got it right when there were very few people working on the problem. The bigger they grow the more problems there are. Getting it right doesn't always scale with the number of people working on it.
TOP
If it ain't broke don't fix it. SW is moving away from letting the graphics card do all the work anyway.

Top of the morning to you all, and I have for all...ONE word...for user benefits...
It is the only thing that allows users to keep the damn suppliers on their toes. MS does NOT promote choice on their OS. It is the Redmond highway or noway they want promoted.
Microsoft became complacent in the late 90s once they became a super- majority supplier and could virtually dictate terms to everyone. Now they are trying to muscle in on audio, video, graphics, replacing Java, .Net. I think MS is spread to thin, trying to "be all, end all".
Frankly, I can't see the benefit of Microsoft's OS in today's web world. I can see the value in various programs I use on the OS, like SolidWorks, but the OS is a bitch if you take it online, and sort of OK if you keep it off the net. That is not an OS I want to write home about.
If the CAD guys start seeing better ways to run their products on other OSs, I think we will see more viable options appear. Mac & Linux use in some organizations and colleges is on a major up spike, and it is not hard to see why, just in reduced maintenance time.
IT guys are seeing the Mac as a boon. Run Mac OS, BSD, Solaris, Windows, DOS, Linux, and all from one box with several running at the same time if needed.
Where is the "run anywhere" mantra when users want it?
Bo