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
However, parellizing some long to rebuild features like shells should
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?
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
5. There is no perceived need. Can directX make drawings faster? Can
it shorten rebuild times in drawings and large assemblies?
On May 19, 9:01 am, firstname.lastname@example.org wrote:
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
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
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.
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
<- - -CHOICE- - ->
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
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
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?
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?
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.
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.
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
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.
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
In fact, multicore machines do not make more than a few percent
difference with anything but drawings and PhotoWorks.
<SPECapc DOES NOT measure CPU performance, it measures
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.
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.