Multi-Core CPUs & SolidWorks?

Is there any news out there on what is coming down the line with
SolidWorks which may speed up our work with these CPUs?

Thanks - Bo

 

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 http://www.evanyares.com/the-cad-industry/2006/6/20/multithreading-and-cad.html
However, 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.

 

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.

 

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

 

If one was to run SWX on a dual core (or twin CPU) PC it would be

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

 

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

 

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.

http://en.wikipedia.org/wiki/Comparison_of_Direct3D_and_OpenGL

 

<SPECapc DOES NOT measure CPU performance, it measures
graphics performance.>

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.

 

Care to post links or dates and author's names. I always take with a
grain of salt magazine benchmarks unless I can repeat them.

TOP

PS Do the results on the SPECapc website scale with CPU speed?

 

When I was playing with overclocking a few years ago, I found that the
benchmark scaled almost linearly with clock speed for the CPU portion of
the test. Graphics was relatively unaffected. I think this was SPECapc SW
2003.

 

It's been quite a while since we have run any SW Benchmarks and I can't find
the results, but as I recall, both CPU and Graphics results scaled fairly
well with the processor speed. I/O was less sensitive to CPU speed, but
still affected appreciably. We weren't overclocking, we were comparing
different processors, so that could have skewed our results.

Jerry Steiger
Tripod Data Systems
"take the garbage out, dear"

 

For SW2005 it appears that the CPU score doesn't influences the
graphics score as can be seen for the many machines that use the
FX3500 graphics card.
CPU Graphics
2.41 3
2.44 2.84
2.35 2.7
2.4 2.79
2.17 2.8

What I was refering to was a test I did a few years back in which a
box with a mediocre CPU aced a box with a fast CPU solely because of
the graphics card in the slower box.

Let's look at a simplified version of how SPEC scores:

CPU I/O Graphics Overall Geometric Average
1 1 5 1.71

5 1 1 1.71

5 1 5 2.92

Now which box would you rather be on? I would pick the second. The
third would probably not be that much faster in the real world than
the second, but would certainly blow away the first in any real work.

These are not arithmetic averages. They are geometric averages. SPEC
states that they weight them, but they don't say how. Looking at
their results the graphics can certainly pull up a score noticeably.

Examples taken from:
http://www.spec.org/gpc/apc.data/specapc_sw2005_summary.html

TOP

 

It's been quite a while since we have run any SW Benchmarks and I

I suppose it's possible that different graphics subsystems depend
differently on CPU power. Some graphics cards may be limited by the CPU
while others may not (depending on driver architecture, on-board memory,
etc.). This would explain why some individual testers see one trend, while
other testers see another trend.

Perhaps we should not be making blanket statements about CPU and graphics
performance being linked or not, except for specific systems being tested.

 

Dale,

You are exactly right that the system has a lot to do with it. This
includes the operating system. For example some testers may shut down
the networking and every other service that is not necessary including
things like USB ports and other IO ports. Different machines have
different chipsets, different memory and memory settings and different
BIOS. Some testers may run each test on a fresh image. In the real
world though, these things won't be true.

Then in the test, does it really cover the operations that you do?
What about testing error conditions as in an assembly with multiple
bad mates or failed feature? What about multi config performance?
These are some of the things that can really hang up work. My opinion
about real world type testing is to have in-house models that are
known to cause trouble and benchmark them on any candidate hardware or
software releases and service packs.

TOP

PS Some time ago Sporky let us download a whole library of parts. Just
doing a SW conversion on that lot would make a wonderful benchmark.