OT - Dualies / ECC

So I haven't seen anything discussed as of late. But do you guys get the feeling that our rampant hardware speed increase has slowed just a bit. It is amazing to me that we were buying 3.0 gig P4's at the beginning of the year and we are still buying them for next year. Without much of a option to go higher. I am wondering how things are looking for the future. My bet is on multiprocessors before we get to heavily into 64 bit stuff. Really would be nice if we could get Solidworks to let us know either way which way they are thinking.

But then Xeon is the only way to get dualies on the proc side. (unless you go AMD and I don't have the option right now) And most of them only come with ECC. I have a personal opinion that ECC is slower in general with the extra error checking it does, but probably negligible. Anyone out there done any testing on dual Xeon + ECC ram? Hoping to get a few opinions (I am thinking of buying 10 on the assumption that they are better as I can get them for about $500 more than single proc P4's) But then trying to do a bit of testing after the fact.......

Any opinions on the hardware side?

Speaking of that anyone trying out the PCI express over the AGP yet?

--Matt Feider

Reply to
Matt Feider
Loading thread data ...

I posted a while back on this. Based on some articles I have read regarding the future direction of CPU technology we, the SW users, are going to be in a bad situation in a year because the CPU builders are going to start making processors like little parallel processors (the same thing more or less as multiprocessing.) Even now Intel puts hyperthreading into Pentiums. There are several posts on this group about the deleterious effect of hyperthreading on performance. So far SW has said a resounding no to taking advantage of either 64 bit processing or multiprocessing. The lack of 64 bit is curious since SW used to be compiled for the 64 bit Alpha chip. The inability to use multiple processors is a bit easier to understand since certain key tasks in parametric modeling must be done in a linear, sequential fashion although even this is not entirely true. There are methods of accomplishing what SW now accomplishes without this restriction to a single processor. Previously on this group (about a month ago) someone made the comment that the hardware vendors are to blame for not keeping up with the software.

Vendors like Autodesk may have a leg up on SW in this regard because they write their own kernal and can more easily adapt to both 64bit and multiprocessing technology. My opinion is that certain old line software like Pro/E and UG perform better on large assemblies and models than the newer midrange software systems. I don't really have any hard facts on this however. SW has on average seemed to perform about 2-4% slower on each new release in the areas that matter to me. I have an old saw that if SW was getting faster like they say it is, we should be able to run a 2,000 part model on an 8088 system by now. That is of course ludicrous.

SW needs to speed up part modeling and regeneration by a factor of ten. This would be foundational to getting faster assemblies and drawings. SW needs to take the variablity out of rebuild times. SW needs to start supporting 64 bit and multiprocessing.

Finally back to your topic, I run ECC without problem or slowdown. ECC is good in that it helps minimze memory errors which can be at the bottom of some types of crashes. I still have crashes, but not as many as before I started using a system with ECC. It is too bad that you have to be limited to Intel because a system built on AMD 64 bit processors can be 50-100% faster and it has the potential to support 64 bit computing without buying new hardware.

Reply to
P.

I tend to agree very much, as it seems that chip technology has shifted just a bit away from the huge speed increases and more towards intelligent design. But then what is intelligent? For the masses it probably is multithreading or something to that effect.

This is exactly where I am at too. Windows XP 64 bit is out there, of course not released yet so there is really no good 64 bit OS support and I know that Solidworks is pretty tight lipped about it. I am getting to go to Solidworks world and plan to see what light they shed there. But then there are several other items missing for good 64 bit. Memory is still lagging in size to really take advantage of it, unless we start seeing motherboards come out with 8-10 DIMM slots on them. I haven't seen good motherboards yet for 64 bit workstation type quality that will really enhance the ram away from the limit of 2 gigs today. But then how much increase in this is really going to be effective?

I tend to agree as I have used Pro/E quite a bit 16 up to 2001i, thought I personally think again that this is more related to them doing their own kernels and more of their own code to optimize it to their operation. I have a tool from sysinternal.com that watches file accesses. It is really amazing how many times a file is open and closed and read from when just opened from solidworks. I really tend to think that some of the choices solidworks (or the kernel) has made with structured storage (and the microsoft way) has really limited speed and increased harddrive usage in space and time drastically. I am sure there are benefits but for me I think I might have made other choices.

Yeah I hear this about software but then I look at what we are asking it to do. Sketching may be faster but then they have included sketch relationships graphically now. I am sure sections of the code are faster (but then there has got to be an upper limit, you can only improve code so much). Then of course the other option is to start adding more function to it. Then the interplay between features starts really becoming a problem.

I agree though I have some additions that I would really like to see. Better file access and loading parts into memory would be key for me. I really wish they could use memory better both physical and on the disk in their file storage.

I really think their first option of using multiprocessing will be at the assembly level of regeneration of two independent parts at the same time.

Thanks, thought I enjoyed the above too. I think it would really help a lot if Solidworks would share a bit of its path forward.

I kind of have the same opinion, but we are standard on Dell and they don't really support AMD at all. Kind of sucks and we have thought about looking elsewhere but then there is a TCO to consider when doing that. I know that the error catching is supposed to be better, but I have not seen much of a difference with the one machine I have. With Dell though as soon as you go Xeon for duallies then you are forced into ECC. And funny enough also LINUX is loaded on the machine by default, which I would love but is hard to run SW on. Though I have been curious to try VMWare.

--Matt Feider

Reply to
Matt Feider

My associate has Dell and he is always complaining about speed. Technically our machines are the same hardware but for the MOBO and CPU. He is Intel

3.2GHz, I am AMD FX53.

Dell is really expensive when compared to incremental upgrades. To upgrade a Dell you have to get a new machine. To upgrade my machine requires a new processor and maybe a MOBO. But FUD will stop most IT departments from actually implementing this.

Actually there are some good Opteron MOBOS out there that hold a lot of memory and four CPUs.

I haven't used sysinternals, I used something from MSoft, but you are right, SW really thrashes the disk with file IO.

Reply to
P.

When did SolidWorks "So far SW has said a resounding no to taking advantage of either 64 bit processing or multiprocessing."????

I have never seen this before. I wouldnt jump to this conclusion...

Todd

Reply to
Todd

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.