TheKitchenAbode

Sorry about my persistence on this subject. When some users ran the Chandelier Stress Test they found that their camera view performance improved as they zoomed in on the Chandeliers. I believe I can now explain this behavior. The camera view function requires both the CPU and the GPU, when all the Chandeliers are within the camera view the CPU must process all of the displayed elements. However when you zoom in the CPU only processes the elements contained within the view and as such there are far less elements to process. Initially when the CPU has to process all of the elements the GPU sits waiting for them and as such the motion is jerky. As you zoom in and the CPU has to process fewer elements it will reach a point where the flow from the CPU to the GPU is sufficient enough that the GPU does not have to wait anymore. Motion is now smooth. The CPU is no longer the bottleneck in the process, they are now balanced. The next bottleneck will be when the CPU can flow data at a greater rate than the GPU can process, now the GPU is the limiting factor. From what I can tell the CPU processing side of this is single threaded, therefore it is important to choose a CPU that has the highest single thread performance if one wishes to get the most out of their GPU's.

Thanks Perry - In general that is definitely the rule. However, the type & combination will and can have a significant effect on how much of an improvement will actually be realized. If one is to configure the best possible system, regardless of budget large or small, then understanding the CPU & GPU interactions, single thread versus multi thread operations and how your software actually functions is crucial. You could easily be spending a significant number of $$$'s and end up going nowhere. For example, with that Chandelier Stress Test, my GPU is fairly low on the performance ranking scale, despite that fact I was achieving similar camera view performance as those with significantly greater GPU performing cards, they should have blown me out of the water . Why not? because those other cards are most likely being limited by the CPU due to it being part of the camera view function and the process being single threaded. Even my 620 integrated graphics HP Spectra 360 performs in camera view about the same as my main system, just takes a bit longer to build the 3D Model before the camera view displays.

Ok, I have completed my testing and evaluation concerning the impact of Surface count and performance. Do the number of surfaces impact on performance ? - Yes Is it just this simple surface count that determines it ? - No Then what is it? - It's whether or not the surfaces are singular or packed together in Architectural Blocks or Symbols. Individual objects/elements are the fastest to process. Surfaces contained within Architectural Blocks or Symbols are not directly accessible for processing, they must be unpacked in some manner first. From my what I can determine this takes 3-4 times the processing than if they were not in an Architectural Block or Symbol. This gets even worse when these are nested together, blocks within blocks. Does the surface property make a difference ? - I found no discernable difference in performance as it relates to the surface/material properties. Will a faster GPU help? - Yes and No Both the CPU and GPU are involved, the surfaces are processed by the CPU first before being sent to the GPU, this process appears to be single threaded. OK, but once the 3D view has been generated then my GPU will be able to go to work - No Even though the model is now in the GPU your CPU is still involved as you move within the model or make changes. Those surfaces still need to be processed or when changes are made the 3D model must be rebuilt. Is there any way to overcome/minimize this ? - Yes 1.) If possible use as few Architectural blocks and Symbols as possible. 2.) Use the Layer Set Display Options to turn off the display of unnecessary things. CA only processes the surfaces that are within the turned-on Layer Set Display Options. This is the most effective method I have found when dealing with sluggish performance, turn off those unneeded layers. Just an additional side note about those blocks & symbols, they also have a similar effect on many other CA functions such as copy, undo/redo, move and anything else that involves a model rebuild. Hope this helps.

Larry - There is no doubt that it's a challenge to find the so called perfect solution. Ray Tracing is a much more simple thing to address as there are only two parameters one needs to consider CPU GHz and the number of cores, the higher the better. When it comes to CA's normal operations it becomes more difficult as it is not a true multi thread application and it also relies on the GPU and Disk Access. Given the current Chips, there are not really any that are perfect in every aspect. You can see from test reports that many of the high core count processors are not the best at single thread operations and vice versa. From my testing, it is also clear that the camera views are not just a GPU task, they also involve your CPU and as such there can be a bottleneck as one waits for the other, this is most likely why you did not see an improvement when you upgraded your graphics card, it was being held back by your CPU, low GHz and single thread processing. Unless one builds two different machines it will always be a balancing act.

Here is a link to a very good review site for laptops/netbooks. I have found their reviews to be fair and unbiased. https://www.notebookcheck.net/Reviews.55.0.html

I think it only applies to the session you are working in. Once you close out, all is forgotten.

I recently went shopping for a similar system. Checked out the Surface Book you are looking at, seemed way over priced. I ended up getting an HP Spectra 360, got the 13" one as I wanted the better portability. Could not be happier, I opted for the I5 version as the I7 does not really provide any significant performance benefit but costs a fair bit more. My unit has the integrated Intel 620 graphics chip and it has no problem handling anything I can throw at it, Grandview plan no problem. They come on sale frequently so you can get a lot of bang for your dollar. Paid $1,500 CDN. Even came with the stylus, USB-C HDMI adaptor and protective sleeve. They have I7 versions and 15" ones. Beautifully crafted, sturdy, thin and exceptional battery life. You can't go wrong.

Larry - I got the numbers from CPU Boss. Minor differences will not be noticeable as these test are dedicated to access only one aspect under ideal conditions. CA states that it is optimized for multi threaded operations, that does not mean that all operations are multi threaded. Most software calls upon routines outside of itself to perform many functions. These are written by Microsoft and many others, they are baked into the OS, drivers, memory controllers etc. Many of these are likely single threaded for which CA has no control over. Ray Trace is a really good example of the performance that can be attained when a program can be written exclusively around multi threading. One thing to also keep in mind is that with dual processors some time will be consumed as the system tries to mange the flow between the two processors. If all the cores are built into a single processor then that process is eliminated. In general, a single processor with 12 cores should be faster than two 6 core processors if they both operate at the same GHz.

The single thread (core) speed of your I7 920 is 1,959 and your Xeon L5639 is 2,085. They are virtually the same and as such both machines are equal in performance when a function is only single threaded. Be careful when you are watching your CPU monitor not to misinterpret the fact that you may see activity on all cores even though the system is just performing a single threaded operation. I believe this is just an internal management thing where it distributes the single threaded operation over the cores versus just dedicating it to only one core.

Larry - I believe a lot of what you are experiencing is related the difference between single threaded versus multi threaded operations. Your Xeons excel at multi threaded operations but are not the best choice for single threaded operations. As Ray Tracing is written to take full advantage of multi threading your system excels in this. However a lot of regular software and the shared routines they call upon are often single threaded, this puts you at a disadvantage as many I7's significantly out perform Xeon's in this type of operation. If you review those CPU comparison reports you will see this very clearly in the single versus multi threading numbers. If I was making a recommendation on balanced CPU it would be to get the fastest single threaded capable processor with the most cores. Currently with Intel this means something like the I7 5960 or the I7 7700K. IF budget is of concern then the latter would be a great choice.

Agree, I also have had my doubts about how impactful the surface count is at least concerning moving within a 3D camera view. It may though have an impact when you get that Building Model notification prior to the 3D view coming up.

Another interesting fact is that a outside camera view of the Grandview plan reports 1,137,364 surfaces. It comes up fast and rotates smoothly. My Chandelier Stress test with only 664,160 surfaces does not run as smooth as the Grandview. Would appear that surface count may not be the only thing going on here.

For myself with camera settings such as Bloom, Shadows On and Ambient Occlusion there was a noticeable difference in how long it took to get my Rotate Cursor to function smoothly again after doing a zoom in or out, about a 3 sec delay. As has been reported by others, if I zoom in then things get faster, the less number of objects in the viewable window the smoother the rotate. This also resulted in a reduction in the lag I mentioned in my other statement. Another interesting observation was that my GPU Usage was significantly impacted by the zoom level. If all the chandeliers were visible my GPU usage during a rotate was very low around 16%. When I zoomed in and rotated my GPU usage was up at 60% or more.

Just ran the test with my resolution reduced to 800 X 600. Did not seem to have any noticeable effect compared to my native resolution of 1680 X 1050. Would seem to indicate that the GPU processes everything regardless of the resolution setting. This is definitely different than how a game is treated, the lower the resolution the higher the frame rate. Possibly this is related to how Open GL works.

Just got back in. Thank you to those who ran the Stress Test. Hopefully more users will participate so I will have enough results to establish some generalities. One thing that will definitely effect our results as compared to one another is the resolution of the monitor you are using. For mine, my primary monitor is 1680 X 1050 and my secondary monitor is 1440 X 900. For this test, those running at much higher resolutions will likely find their manageable chandelier level being impacted by all those extra pixels their GPU has to process. Keep in mind that doubling the pixel width & height will quadruple the number of pixels. Possibly someone running a higher resolution could drop their resolution and rerun the stress test to see what the impact really is. Thanks once again and keep those tests results coming in.

For my system configuration 70 chandeliers is reasonable. Could tolerate 100 but not for long. Make sure to close the camera view before deleting/adding chandeliers. If enough users report their Chandeliers I will compile and rank the configurations. Will assign, say form 1-10 Chandeliers. Will make a small Chandelier Icon and you can display these in your system configuration description at the bottom of your postings.

For those wishing to play around a bit I've attached a very simple plan, just a chandelier copied a multitude of times. There are 3.8 million surfaces in total. If you want to test with this, just keep deleting or adding fixtures until you find the acceptable level of performance limit for your configuration, report the number of fixtures your configuration can handle. Once you have found the limit for your particular system it is then fairly easy to evaluate the impact of other settings such as Blocking, Smoothing, Shadows, etc. Abode_ System Stress Test.plan

Maybe it was my wording. The lower the smoothing effect the faster the camera render. Too make the lines smooth (less jagged) during motion requires more computations and therefor more time. This slowdown will vary according to the capabilities of your graphic card in conjunction with the complexity of the model.

Yusuf - I have obtained similar results. Always use Hardware Smoothing versus Software. The lower the smoothing setting the faster things will be. I have not found that the colour makes any noticeable difference. However, Shadows "On" will. I have done more testing with Architectural Blocks and they definitely impact on the 3D Model Rebuild time. Gets even worse if you nest Blocks within Blocks. Suspect it has to unpack the blocks and then repack them.

Unlikely, many of the disk operations function in the background so your system would not hang. While in CA there is not a lot of drive access going on once your plan has loaded. Spikes on your CPU are normal and they in themselves do not necessarily indicate a problem. When Ray Tracing your CPU runs @ 100% until the Ray Trace is finished. It's just saying that the CPU is working @ it's maximum efficiency.

I've just noticed what appears to be a very strange behavior. With my CPU usage monitor running, if I just move my cursor within the active window in Chief my CPU throttles up to 4.2GHz, I'm not moving anything around, just moving the pointer over the window area. If I move my cursor over to any of the program menu regions my CPU frequency drops to about 1.6GHz. This also happens in a plan view and elevation. If I stop moving the cursor the CPU drops to 1.6 GHz. Also my CPU fan cranks up when moving the cursor. However, if say on the plan I zoom in and out with the scroll wheel my CPU throttles up a bit but even if it maxes out the cooling fan does not crank up. This also happens with my GPU load, moving over the active window jumps the load to about 60%, moving the cursor around on any other part of Chief or on my other screen the GPU usage is only about 20%.

I'm becoming suspicious that there may be a conflict with some other process when the 3D Model Rebuild is running. When I monitor things Chief goes into a "not responding mode", This usually indicates that something is requesting something from Chief and Chief is not responding to the request. It could be a shared resource that is working on something else and therefore Chief can't proceed until it has finished with it's other task.

Larry - Not sure that's the solution, especially concerning the 3D Model Rebuild. I just ran the Grandview Plan on my I5 HP spectra with integrated graphics. It ran about the same as on my Alienware system which is at least 3 times more powerful with twice the cores and double the GHz. The other indicator is that during this rebuild the CPU monitor does not show a huge spike so the CPU is certainly not being pushed very much, disk access is low and the GPU is low. It really seems that there is something else going on here.

Yep, just blocked and unblock a couple of times. When blocked the 3D Model Rebuild took a lot more time versus them all on their own.

This is interesting. For the above I had grouped the fixtures in an Architectural block. For interest I unblocked it and it now runs very fast. Would need a bit more playing with to confirm but on the surface, excuse the pun, Blocking elements may also impact on things.