Until we have full multi-core implementation on Revit, it is essentially looking at one core at a time (except for certain uses, such as Rendering). Mark Cronin has tested whether Hyper Threading helps standard Revit – and his benchmarks indicate that it does not… the number to look at below is 318 (no HT) vs 335 (with HT).
He “averaged the results from the workstation, and the scores can be seen below: 
They clearly show that there is at least a marginal improvement in the model creation portion of the testing, and a substantial performance reduction in the rendering section with Hyper-Threading disabled.”
via
Hyper-Threading for Revit? | betterREVIT
How far has multi-core implementation come in Revit? Gordon Price on RFO:
File and view open are both multi-threaded, as are exporting of DWGs and images. Pretty sure printing is multi-threaded now too. And I am sure that updating a curtain wall is, just not sure yet if that is a function of curtain walls specifically, or if updating any family in a project is multi-threaded. Pretty sure it is not everything, as I just tested changing a wall thickness and it pegged my dual core VM at 50%. Edits to doors hit 49-50% for just a second. I suspect curtain walls got the optimized code because 1: it was easier and 2: really complex curtain walls kill performance
I recall that the revit.ini used to have a setting for multi-core wall join cleanup. Steve mentions it in quoting a Revit technical note:
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.
via
Revit OpEd: Multi Core/Processors – Tech Note
So the revit.ini used to have ParallelWallJoins and ParallelPrintProcessing switches. I’m not sure if these are still implemented in Revit 2013 (my .ini was at “C:UsersLukeAppDataRoamingAutodeskRevitAutodesk Revit 2013Revit.ini” but didn’t include any lines for these multi-core switches … However, it might still be possible to add them.)
