Thom.Alt

Max Speed Import: What's the config?

5 posts in this topic

Hi there.

 

We use VW2017 to add electrical engineering features to architect issued plans. In a rather big project we get multiple 500 MB - 1 GB plans from the architect that we have to import and save as VW documents to be able to work on them. This happens a few times a week and it surely adds up time before we can work with those plans. As of now we are using the biggest baddest iMacs and VW2017 for the planing and even they slightly buckle when importing those plans. Trying out different MacPro and Mac minis we determined, that during the import process it's the clockspeed and the usage of real CPU cores that truly makes the difference. For example a MacPro 2009, 4-Core 2.66 GHz XEON on 8 GB RAM, SATA2 SSD with 10.11.6 and VW2017 will have around 2min 30sec to import a 10 MB .ifc file. We tested it with the standart GT120 (512 MB VRAM) and a GTX760 4GB and there practically no difference between them. GPU seems to make no direct impact at that point. Also it shows only the real cores under pressure, so no hyperthreading during import.

 

So there are a few questions that need confirmation:

 

  • Is the observation correct, that it is the clockspeed and the physical cores that really count during import?
  • Can VW2017 actually use more than 4 Cores? How is it in WIndows 10 64bit?
  • Will 32 GB RAM bring a significant boost against 16 GB RAM?
  • Would a RAM disk containing the file to be converted bring a significant difference?

 

We threw round a few suggestions and thats what we would go, if the before mentioned points can be confirmed:

 

AMD Black Edition FX 9590 4.7 GHz 8-Core on a FX990 Chipset board, AMD RX480 (8GB VRAM), SSD, 16 GB RAM (or 32 if it really makes a difference)

 

In the end we are aiming for the setup that will allow us to max out on the import process (within reason of course).

Thanks for your input, your tips are really appreciated!

 

Best Regards

Thomas Alt

 

Share this post


Link to post
Share on other sites

You're talking about quite a few things here, I'll attempt break them down:

 

1) You will have very little success attempting to speed up the geometry calculations that occur during import with any hardware upgrades.

2) Rendering in Vectorworks is fully multicore, geometry/file operations/math are not.

3) Going from 16GB of RAM to 32GB will likely not show an increase in performance unless the files you are using are actively taking up all of your system RAM when left open and idling, which is uncommon.

4) The operating system (as long as it's supported) has very little, if any, effect on the speed of any aspect of Vectorworks.

5) Your graphics card will have no effect on file import, only in how long it takes to display the file in OpenGL or Top/Plan, which generally is just a few seconds even on mediocre cards after the geometry calculations are complete.

6) Upgrading to a RAM disk from an SSD might help file import but only VERY slightly and more likely than not wouldn't be noticeable, since the main bottleneck is CPU usage rather than disk read/write speed.

 

You aren't doing anything wrong at all, it's just that the underlying math and geometry calculations in Vectorworks have not yet been updated to take advantage of multicore processors. Doing this requires rebuilding systems from scratch, so it is only being done in one or two areas at a time as doing it all in one version wouldn't be possible. Hopefully this is the information you were looking for, if not please let me know and I can further clarify.

Share this post


Link to post
Share on other sites

I think the import is still single threaded.

So it counts the single core cpu speed (turbo mode)

 

GPU does not help beside OpenGL and View Graphics.

 

VW will use every core for RW Rendering and some small advantages in, for example HL rendering.

 

RAM will only help if you need more RAM than you currently have.

If you have enough (watch your taskmanager) only its speed will count.

 

RAM disk, don't think much. I think all work is done in RAM.

Share this post


Link to post
Share on other sites

Not entirely sure that import is so strictly single core. When we did an import test on a mac mini with a core i5 dual core, it shows that during the import (within the red bars) the two actual cores are under load, while the "virtual" cores are doing practically nothing.

 

Hence my hope with the FX9590 not only having a high clock speed, but having also 8 real cores to cope.

 

 

Bildschirmfoto 2017-02-15 um 11.23.13.jpg

Share this post


Link to post
Share on other sites

The problem with verifying what is and isn't multicore in Vectorworks, is during import and many other types of actions it bounces back and forth between single threaded actions and multithreaded actions rapidly. The functional math being performed at the very bottom end is all single core, but there are multicore/threaded processes that switch on and off to perform other operations in the meantime if the single thread importing items has finished a "chunk" that needs other work done on it by another process before the import is completed. You'll be able to see this more in the total CPU utilization % compared to the individual core utilization percentages.

 

Also, "Real" vs "Fake" (Physical vs Logical) cores is another complex discussion, but when implemented properly by a software's developer, it doesn't matter to a process thread if a core is "real" or not. By the way, if you have hyperthreading enabled that means you now have 8 logical cores, rather than 4 physical and 4 logical. Without hyperthreading, you'd just have 4 physical and no "fake"/logical cores.

 

For example, here's a fully multithreaded action, (Renderworks rendering in the indirect lighting phase) and you can see Cinerender using up 700% and change, effectively using 7 cores to their fullest and a bit of the remaining core which also has to handle the rest of the processes on my machine including Vectorworks which passes it information between the various render phases.

58a74ef63ec2e_ScreenShot2017-02-17at2_22_20PM.png.f33dfcb2cf86b7225b30def117b27e72.png

As you can see there are 8 cores on my CPU here, 4 physical cores hyperthreaded to 8 logical cores. Regardless of whether a core is "real" or not it is fully utilized when doing a rendering.

Now, for geometry/math operations, this changes a bit. Since it's a single threaded operation, take a look at this example where I duplicate an array of 20 complex mesh objects:

58a74fde1a7b8_ScreenShot2017-02-17at2_31_23PM.png.9cf8e90cd65d1f7d051548bcf0230a27.png

See how it's using 4 cores, but not all the way? And that Vectorworks process sits at 88%? (It hovered between 66% and 100% for this test but it was fluctuating and I missed it in the screenshot) that means that Vectorworks is only pushing a single thread to be processed, but the OS is deciding that single thread can be spread across 4 cores. The OS is in charge of which of those cores the operation is spread across, this can be seen in the differences in color in the CPU individual core monitor. You see a lot of red in the second screenshot but almost all green in the first. Red is CPU usage dictated by the OS. Green is CPU usage dictated by the application. So when you see the reg/green split like that, you aren't seeing Vectorworks performing a multithreaded process, you're seeing the operating system attempting to split up a single threaded process.

 

NOTE: I've been told when the OS does this, it's never allowed to use all the cores available, but the rules can be different on Mac vs Windows. I have not tested that personally however and don't know how true those claims are.

 

I am very much oversimplifying what the engineers have explained to me in great detail over the years, but this is the general gist of it.

 

Now, as a more practical answer, I have a number of different types of hardware available here for testing and if you can dropbox/google drive me one of these large files, I can absolutely test it on a few of them to see if a significant difference in import time appears. No matter how solid the theory involved may be; nothing beats a real world usage test.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now