In the Revit Tech Note document Autodesk has the following information:
Although the Revit platform is not fully optimized for multi-threading, multiple-core processors reduce cycle use by other applications running concurrently. Some reports show as much as a 20% increase in Revit platform performance in a multi-core or multiple processor environment.
In Revit 2010, multi-threaded methods for printing and wall join cleanup have been made available. Multi-threaded hidden line removal for printing has been enabled by default.
Due to the operating system overhead of maintaining multiple threads, multiprocessing of wall join cleanups can experience a minor degradation when only 2 CPU cores are present, but up to a 27% performance increase when 4 hyper-threaded CPU cores are present. Because 2 CPU core systems remain the most common configuration of Revit systems as reported by CIP data, multiprocessing of this features is OFF by default.
To enable multiprocessing for wall join cleanup, add the following entries to the Revit.ini file:
[PerformanceOptimizations]
ParallelWallJoins=ON
To disable multiprocessing for wall join cleanup, you may omit any entries in the
[PerformanceOptimizations] section of the Revit.ini file, or explicitly set the state of either one or both multiprocessing optimizations:
[PerformanceOptimizations]
ParallelWallJoins=OFF
ParallelPrintProcessing=OFF
The Revit platform's rendering function is optimized to use up to four processors. The Revit platform will share processing time with one of these four rendering processors, so there is no exclusive gain for the Revit platform in making more than four processors available. Additional processors may be desired if other computationally intensive applications need to run while the Revit platform is rendering.
Also, if you use the 3.5 GB switch feature for Windows 32 bit operating systems Revit is already a Large Address aware application so no additional work is required other than enabling the switch.
2 comments:
Simon wanted to post the following but couldn't for some reason so I've done so for him:
"There are a lot of misconceptions about the /3GB switch. Using this
switch can sometimes be counter-productive.
Mark Russinovich wrote
some articles about how Windows handles memory. Visit this site:
http://blogs.technet.com/markrussinovich/archive/2009/07/08/3261309.as
px
Look for "Pushing the Limits of Windows: Physical Memory" and
"Pushing the Limits of Windows: Virtual Memory".
If performance is critical, you are better off switching to 64 bit windows and a machine with at least 8 GB RAM..."
I agree with Simon, the 3.5 GB switch is a short term solution. The information in my post is also heavily biased toward helping Revit at the possible expense of other applications the user may need.
Anyone tested the multi-threaded print? Is this in standard print or just batch print plugin or what? I tested a Multi-page print in Revit printing to PDF and it only seemed to use one core (25% or my Quad core CPU)...any thoughts?
Post a Comment