Making Good on the Promise of 64 Bits
Latest News
December 4, 2001
By David Cohn
I’ve spent a fair amount of time this spring reviewing new computers equipped with the latest dual- and quad-core CPUs. You would think that with all this horsepower, engineers have entered the promised land. Guess again.
Multiple CPUs and multicore processors offer all sorts of potential advantages, and engineers might certainly reap the benefits, but many of those benefits are still hard to find. The reason: Intel and AMD have moved to multiple cores more to solve their own problems than ours.
For years, the way to get more performance out of a CPU was to increase its clock speed. But faster chips use more power and generate more heat. The solution: place multiple processor cores inside the CPU to get more done at the same time without upping clock speed, power requirements, or heat. But in reality, multicore processors can’t deliver such performance unless the applications being run are multithreaded; that is, unless those applications are designed to split computational loads across multiple cores.
Some applications — primarily computationally intensive applications like FEA, CFD, and rendering — are by nature multithreaded and exhibit significant performance improvement when run on multicore processors. That’s no surprise.
Analysis software has also long been designed to split its calculations across multiple CPUs, and many vendors have offered analysis as both a product and a service so you can offload the computation to the vendor’s compute farm. FEA solvers show a nearly linear relationship between the number of processors and execution speed.
So now we can accomplish the same thing in our own offices, right? Maybe. Some vendors charge extra for that privilege, levying per-socket or per-core premiums to run their software on multicore systems. Policies vary not only between companies but even among products from the same company.
While parallel processing brings clear benefits to analysis applications, its benefits are more fleeting for MCAD applications. Most MCAD applications are not significantly multithreaded and actually run a bit slower on new quad-core systems than earlier dual-core systems due to the new systems’ slightly slower clock speeds. Nor is that likely to change soon. Some bits inside an application may become multithreaded — rebuilding a model after adding a fillet — but other functions are linear in nature and simply don’t lend themselves to parallel processing.
But here, 64-bit computing may provide significant benefits. A 32-bit operating system is constrained to 4GB of memory, limiting model size. Move to a 64-bit operating system and the amount of memory you can install in the computer soars. But few MCAD applications are currently optimized for 64 bits. That will certainly change over time.
Science fiction writer William Gibson wrote, “The future has arrived; it’s just not evenly distributed.” Better computer technologies are available; they’re just not all being applied yet. I’m betting on both multicore and 64-bit, but I’m not holding my breath.
David Cohn has been a contributing editor to DE for more than 10 years. You can send e-mail to him at [email protected], go to dscohn.com, or send a message to [email protected].
Subscribe to our FREE magazine,
FREE email newsletters or both!Latest News
About the Author
David CohnDavid Cohn is a consultant and technical writer based in Bellingham, WA, and has been benchmarking PCs since 1984. He is a Contributing Editor to Digital Engineering, the former senior content manager at 4D Technologies, and the author of more than a dozen books. Email at [email protected] or visit his website at www.dscohn.com.
Follow DE