Multithreading CPU for exports and modifiers
I would like to see a joint effort from all users to support this petition/suggestion, which is about improving the speed of bledner.
As far as I can see, the greatest potential and prosperity would be if the application of modifiers took advantage of the multithreading of the processor, because when working on a dense mesh such as. 3D scans, photogrammetry and other voluminous meshes blender is totally out of date, not upgraded and uses only 15% of the total CPU power - so why to inveigle in an expensive processor like R9 7950x or I9-13900KS if their potential is blocked by blender anyway (maybe not in all tasks because I saw that some part of modifiers uses it). And if this were allowed to be used then Blender would get a massive boost in adrenaline and speed. Mainly depends on those modifiers that really grind everything for a long time like 3D scan has 7mln triangles, we are talking about modifiers like (add or delete them):
- Subdivision
- Decimate
- Smooth
- Smooth Corrective
- Smooth Laplacian
- Multires
- Array (although here it uses 30%, why can't it use more?)
- Triangulate
- and probably more would be given to handle it
Also it would be great if exporting also used the potential of our processors or at least the most popular ones:
- FBX
- OBJ
- GLB/GLTF
- STL
You could also use multithreading for the simplest shift + D or alt + D copying, because also with a dense grid progam gets breathless
! The proposal everyone is waiting for: increase speed, by using mutlithreading !
I think that if blender was a program using the full potential of the processor it would be one of the faster ones and surely all users would be delighted which would also increase the interest in blender, because nobody uses dual-threaded processors anymore, only 12-16 and more :)
It would also help avoid various freezes in the thought that the program has crashed
Many people need it, and yet the blender remains in the 19th century, because half of the functions do not use today's computing power.
I ask all interested parties to paw up and bump this topic to the top, because with such an improvement, everyone will feel why they spent so much money on their powerful central unit
Screen taken while the multires modifier was running - And where is my 90% power ?
This is not due to a bottleneck because the results are close to each other
5 Comments
First rule of performance is to know what the bottleneck is. You’re assuming that the cpu is the bottleneck, but what happens if this wasn’t the case. Many development time is spent on adding multithreading to exports, that eventually only gives you some percentages of benefits, as the real bottleneck isn’t multithreading, but IO access.
Have you looked with a profiler (not system info) what the real bottleneck are? Can just be that the exporters/importers you have been tested with are implemented in python and the data transfer between C and python is the overhead.
So yes we could improve the performance, but you should not point out that multithreading is the solution without proof that it can fix it. The solution should be given by the people standing with the feed in the mud.
Also check the improvements done recently on many importers, none of them use multithreading as it doesn’t solve the bottleneck.
I doubt that a computer for a lot of money should start its throat elsewhere (of course it certainly matters with weaker components) but with higher single-threading, the processor is a more blocker than the M.2 / SSD / RTX 4000 or DDR4 3600Mhz disk ...
Even by improving the RAM, we won't do anything else because it's impossible to do faster than SSD, and if it is only a few %.
You talked about exporters - ok
But during the modifiers on the PC only the CPU works at max 15% or sometimes supports the GPU.
So I wouldn't want this topic to get off the beaten path again and I've been pushed off because a lot of software uses the potential of the CPU and GPU and with blender it's not that powerful... Take the Zremesher with zbrush for example... it uses around 40% and what a performance leap
You’re still talking about symptoms, every performance engineer will tell you that you need to focus on which bottlenecks will show you those symptoms. Without doing some in-depth analyse that proves your point, this task will not make it. Best to have a scenario and ask developers or performance engineers what the main bottleneck is. It might surprise you and consider other solutions/topics.
When using modifiers most are already multithreaded. I think that the best way forward would be to create a file which is slow and ask developers from the core/performance module (that includes me) what the bottleneck is for that file/ operation.
Low cpu utilisation is a consequence of the bottleneck that needs to be researched.
Yes, devs really working for make modifiers (most geometry nodes) more parallel