SketchUp using all cores off the processor!!!
-
The quick answer is NO.
Hopefully future versions of SU will be able, but at moment only the primary core is used.
-
Hello there,
Could exist a way to make SU use all the power of a Dual core?
For exemple, I have a Core 2 Duo E4500 and for all tasks that need to be calculated by the SU, it uses just one of the cores ( 50% of the potencial of the processor ) ... I know persons that have a Quad-Core and the SU just uses one core ( 25% of the potencial of the processor ).
Anyway, my principals question are:Does anyone know how to improve SU ? Is there a way to make the program recognize all the cores of a processor ?
Thanks,
Sorry about the English...
-
@catapimba said:
Is there a way to make the program recognize all the cores of a processor ?
Hi Catapimba,
No, unfortunately the current versions of SU cannot handle multiple cores. SU may still run faster on multiple core computers as all the other tasks can run on one and SU on the other core thus allocating more power to SU but of course this is not what you (and many others - well, everybody) wishes.
Also, please, ask the same question only in one forum/place. See, now as I've merged your topics and Pete's answer above, it came out to be posted before yours.
But we all know he's a witty dude and apparently knows the answer before you ask so there's no problem actually.
-
Hi Solo, I hope I am wrong, but don't think that SU will ever be multi-core in the near future. I don't know what programming language, or version it is written in, but I am guessing (because of the jumbled menus situation) that SU is the product of an old compiler from the late 1990s. It is probably not a simple matter to recode for multi-core, or multi-tasking.
Even Podium V2 (sorry Casa for expanding the topic) may be a huge effort to come out with, if it moves away from "Kerky". Will the software's (I am speaking of both) be able to retain the attributes that endear them to us, when rewritten in another more powerful (but with different features and libs.) language? In the old days, when languages were not object oriented, people would write converters that took away most of the work, but I don't think that is the case anymore.
Even single core systems are multi-threading, and windows is a multi-tasking operating system, so the possibility to segment any program, and run portions separately may have existed for some time. I wounder if SU was compiled to take advantage of those features? Btw, if it is, and duo-core does not multi-thread, then very little may be gained. There is a ton of other stuff on new machines that speed up the system, especially the various busses (is that the correct spelling), ram speed, and cache attributes.
Anyway, just talking story, with limited comprehension....
-
Hello there,
This is a serious thing... In a PC world that all the newer processors have at least Dual Core, a program that does not evolve together the hardwares, by the time, it will be useless keep on that program...
In my opinion SU must have to offer support to processors with more than one Core. What you think ?
Thanks everybody!
(sorry about the English again...)
-
@catapimba said:
Hello there,
This is a serious thing... In a PC world that all the newer processors have at least Dual Core, a program that does not evolve together the hardwares, by the time, it will be useless keep on that program...
In my opinion SU must have to offer support to processors with more than one Core. What you think ?
Thanks everybody!
(sorry about the English again...)
Not everything can be made into utilising dual processors.
This discussion has been going in a number of threads here on this forum. -
@honoluludesktop said:
I am guessing (because of the jumbled menus situation) that SU is the product of an old compiler from the late 1990s.
Fortunately that is pretty much impossible since there is a very small chance of such old compilers still being runnable on modern machines. Particularly on Macs, for example, due to the change from CodeWorrier to XcruciatingCode to support the intel Macs.
Something like the jumbled menus is probably more likely to be a library thing but even there it won't be 1990s vintage. It'll be a simple bug somewhere; something in a library that isn't as resilient to abuse as it could be combined with some tiny mistake that results in a null pointer where there ought to be a string pointe, for example. Happens all the time. It might not even be a fault in the SU code itself but in a routine that SU is the only commonly seen user for.
-
Hi tim, Have no idea what you are talking about, but you seem to have the inside track to SU. Not that it matters, but what is it written in? My guess was based on similar behavior I have with a solid modeler written for Win95. I switched to SU because support for that program ended. Btw, it (Trispectives) still run on current hardware, and WinXP; in addition, I continue to support some old programs by coding with a pre 2000 compiler.
-
I am having a déja vue feeling with this thread, although I share the concern.
Bottom line is: Sketchup is slow on a medium to high polycount and needs to get faster. The way they do it doesn't matter....
-
@kwistenbiebel said:
The way they do it doesn't matter....
Fully agree. I don't think it's right of us to make assumptions on how they make it faster. We don't know the architecture of Sketchup.
-
C++ would have been my guess. I have not kept up with the development of programming languages, so how are older libraries used by newer compilers? Can they be? Don't really understand OO, and when I am forced to program, I use Visual Basic. The system hides the OO process, and lets me think of the program structure in a conventional (procedure like) way. Guess I am one of the bad guys:-)
Btw, Didn't I read elsewhere here that is may not the high polycount that is the problem for SU, but the way textures are handled?
-
When I was referring to the architecture of SU I didn't mean the programming language they used, but how they structured their code and inner working.
@honoluludesktop said:
Btw, Didn't I read elsewhere here that is may not the high polycount that is the problem for SU, but the way textures are handled?
Textures does slow it down, but even with plain default materials SU will bog down with high polycount.
It's most likely a compound of causes for it.
-
So this older program I have uses this command called +fullproc. It's supposed to make the program use all cores or threads. I wonder...
-
@krisidious said:
So this older program I have uses this command called +fullproc. It's supposed to make the program use all cores or threads. I wonder...
I doubt it. Programming to use multiple threads or cores effectively requires techniques to split up the workload into pieces that can proceed in parallel and to synchronize the results afterward. This is far from easy or automatic, and is not even possible for some kinds of tasks.
-
Ok so bottom line, no multithread support in the next year or so ?
It's astonishing that even with a Core i7 3.9GHZ 4C/8T, PCIE SSD , 32GB of RAM and GTX 780, I have to wait 5 hours to clean up a 110 MB high details file because my CPU usage is 15% at max while rendering the scene at very high details takes 4 hours.
Also with complex models, I get a lot of hiccups and sluggish performance and it's definitely not my Nvidia as GPU-ID reports 10-20% GPU usage while sketchup is freezing or not responding most of the time with 15% CPU load ( the maximum it can use ).
I'd swear by sketchup if it were multithreading.
-
@kokoriko17 said:
Ok so bottom line, no multithread support in the next year or so ?
It's astonishing that even with a Core i7 3.9GHZ 4C/8T, PCIE SSD , 32GB of RAM and GTX 780, I have to wait 5 hours to clean up a 110 MB high details file because my CPU usage is 15% at max while rendering the scene at very high details takes 4 hours.
Also with complex models, I get a lot of hiccups and sluggish performance and it's definitely not my Nvidia as GPU-ID reports 10-20% GPU usage while sketchup is freezing or not responding most of the time with 15% CPU load ( the maximum it can use ).
I'd swear by sketchup if it were multithreading.
What process are you doing that you wait 5 hours? CleanUp plugin or ..?
What? So to be clear: You hit a scene and wait 4 hours to see it on the screen. Or is this for some sort of output like pdf? Until it gets faster, break up your files. If it's details, why put them all in one file?
Hiccups. Yeah the autosave for large files is a pain. As someone noted regular save is relatively fast, so why is autosave slow?
-
@pbacot said:
@kokoriko17 said:
Ok so bottom line, no multithread support in the next year or so ?
It's astonishing that even with a Core i7 3.9GHZ 4C/8T, PCIE SSD , 32GB of RAM and GTX 780, I have to wait 5 hours to clean up a 110 MB high details file because my CPU usage is 15% at max while rendering the scene at very high details takes 4 hours.
Also with complex models, I get a lot of hiccups and sluggish performance and it's definitely not my Nvidia as GPU-ID reports 10-20% GPU usage while sketchup is freezing or not responding most of the time with 15% CPU load ( the maximum it can use ).
I'd swear by sketchup if it were multithreading.
What process are you doing that you wait 5 hours? CleanUp plugin or ..?
What? So to be clear: You hit a scene and wait 4 hours to see it on the screen. Or is this for some sort of output like pdf? Until it gets faster, break up your files. If it's details, why put them all in one file?
Hiccups. Yeah the autosave for large files is a pain. As someone noted regular save is relatively fast, so why is autosave slow?
Hello and thanks for your reply; Yes the cleanup plugin takes too much time. Not that I am trying to compare sketchup to Autodesk products but Autosave usually doesn't lag me that much as I'm on a PCIe SSD ( 800+ MBps read/write ) I hit save as and it takes 2 seconds to save a 150MB sketchup file.
It's not only about the cleanup. For instance if I want to import and obj file using Simlab plugins sometime it takes 20-30 mins depending on the file size because only one thread is active out of 8.
I understand that OBJ files can be complex but after cleanup they shrink significantly.
Here's an example of a scene I'm rendering with sketchup ( needs 14 hours to finish ) :
Before cleanup file size was around 350MB then it went down to 74MB but it took literally 20 hours to finish the cleanup.
-
Looks like that's going to be a nice render!
Not that this is going to save you tons of time, but I only use CleanUp as I work, only on select parts of the model, nothing too big.
-
@kokoriko17 said:
2 seconds
That's too long!
Frame your model nicelly and save. Then turn off thumbnail generation on "Model Info".
-
@jql said:
@kokoriko17 said:
2 seconds
That's too long!
Frame your model nicelly and save. Then turn off thumbnail generation on "Model Info".
I understand that but if you need your render to look nice you need to import some complex models ( flowers, vase, figurines etc.. ) and these really hit sketchup hard. Check the remaining time for just merging faces :
Advertisement