Does adding cpu cores really make much difference if not rendering with them?

[Paul King]

I have a PC with an old 4 core 8 thread i7 4790K CPU, 32 GB RAM, M.2 drive SSD, and GTX980Ti GPUs.

I have been considering an upgrade to something that can handle more CPU threads, in the hope that ArchiCAD23/24 will become more responsive on complex hi poly count , multiple hotlinks etc projects.

I am a freelancer and generally have to work with projects as I find them - model structure and efficiency are often out of my hands, and I tend to have to follow whatever 'lowest common denominator' office standards are already in play when I am brought in.

I am also at the mercy of whatever imported structural and services IFC models are produced when attempting to coordinate (generally no fancy BIMcloud services on tap - just old fashioned manual IFC file exchanges via DropBox). Switching one or two of these on I find can bring any ArchiCAD session to its knees, particularly if the engineer responsible has not been very good with separating things into useful layers, meaning every bolt has to be shown when beams are switched on, and when everything appears on a single story etc.

Obviously am also impacted by whatever remote Bimserver and VPN folder structures setup I need to dial in to but appreciate more CPU cores won't help with this one.

Sometimes I need to have more than one such project open at the same time. As well as maybe a session or two for hotlinked modules being edited, the normal Email, PDF viewer and browser windows open (generally not too demanding in themselves)

Other than model efficiency, the only variable I do have much control over is my own hardware.

I don't use CPU rendering at all - all GPU based.

All things being equal, am I likely to notice much day to day benefit while wrangling large cumbersome models by switching to something with 10-12 CPU cores? Jumping between views, loading 3D geometry into GPU etc. Would more than 12 make a lot of difference? (where do diminishing returns kick in)

Any benefit at all in moving to a PCIe 4 bus, with all that data needing to be shunted between harddrive and GPU?

Any tips most welcome.

[Erwin Edel]

We use schedules a lot in house for BIM input and proof reading.

Things like: are element classifications correct?

These ussually take a minute or two to generate for the entire model and then when you change something, there will be another refresh update.

I've seen other people complain about these regeneration times, so was just wondering if you experienced any improvement there.

[Nader Belal]

Just my 2 cents,

I have observed that the less items viewed of a really long schedule, the faster it gets or the snappier it becomes

[Paul King]

Erwin wrote:
We use schedules a lot in house for BIM input and proof reading.

Things like: are element classifications correct?

These usually take a minute or two to generate for the entire model and then when you change something, there will be another refresh update.

I've seen other people complain about these regeneration times, so was just wondering if you experienced any improvement there.

For what it is worth, I have found setting up a 3D view with graphic overrides very fast for checking elements classifications are correct (or at least that a classification has been applied) - much faster than schedule.

I just tried regenerating an elements classification schedule we had set up here, and yes, it was definitely much faster with new box - I can't objectively benchmark, as no longer have old box available, but seems subjectively at least double the speed.

[Erwin Edel]

Thanks for the input.

The problem is that by using the syringe tool, it is possible to grab settings of an element and only change things like layer and composite, but not the proper element ID or classification. Thus we need a check between layer, composite and classification.

I think we'll be narrowing down the search to each 'chapter' of our classification system.

[Paul King]

Erwin wrote:


The problem is that by using the syringe tool, it is possible to grab settings of an element and only change things like layer and composite, but not the proper element ID or classification.

This sounds like it might be worth lodging with GS as a wish?

[Erwin Edel]

Nah, that's entirely on the user side.

We have a great template with many favourites setup to have classification be almost a non issue, but sometimes old habits creep up and you just grab some other element and tweak a few settings instead of going with the favourite.

[Paul King]

Philosophically though, ALL attributes should be transferrable via eyedropper, surely? Ideally with some user control over which attributes.

A template doesn't help you when you are exploring new and unfamilier territory it was not designed for, with a new set of requirements - so efficient alternative workflows via context sensitive tools I think is important

[Barry Kelly]

Erwin wrote:
The problem is that by using the syringe tool, it is possible to grab settings of an element and only change things like layer and composite, but not the proper element ID or classification.

Maybe I am missing something here, but element transfer can be set up so ID and Classification can be included or not.


Barry.

[Erwin Edel]

Sorry for derailing so much, but the thing we tend to do here is to use ALT to activate a tool by eyedropping an element and then adjusting 1 or 2 settings instead of all that are needed. Again, it's a work method problem, not a software problem