Trimble & Sketchup 64 bit
-
@thomthom said:
Do I detect sarcasm? If so - can you show to anything that says otherwise? That doubling the size of the data types magically improves processing time?
no sarcasm. I know that switching from 32bit to 64bit will normally not increase speed (and maybe even be slower)
-
@thomthom said:
Tell the devlopers what is slow
Layout!! For me its just not up to scratch, actually not a patch on other drafting tools - but it could be!! Ive left numerous posts on this forum but have heard nothing about any ways to improve LO performance or any proposed developmental changes to make LO run better. For me this is the biggest let down and really takes away a lot of the other advantages that working with SU brings. Therefore....
@thomthom said:
Layout wasn't getting much love fro Google. Things are changing under Trimble.
This is great news! Feel like its been due for a long time.
I do get some sluggishness and crashes in SU and some bug splats so my reason for joining this thread was to try to figure out how to speed SU **AND **LO up and to see whether 64bit might be the answer. I also wanted to express my frustration at how difficult I have found it to find consensus on how to improve the performance of my current set up (without having to buy a new PC).
Granted there may be a mismatch in (users) perceived benefits of 64bit to SU (especially given that other heavy weight pro modelling apps have not managed to take advantage of it yet). So given that 64bit may not add any improvements in speeed, there still seems to be a fair amount of frustration for 'general users' on the performance of SU and LO with their farily new, fairly well spec'd machines.
@nickelessryan said:
I recently had my work machine upgraded to support the 64 bit version of AutoCAD 2013. So now I'm running a Dell Precision T1600 with Intel Xeon E31245 @3.3GHz with 8GB RAM. VAST improvements in system performance with aCAD and all other programs.
Except Sketchup.
This is the clincher for me. I know newer doesn't always mean better, but people NEED to buy new machines or upgrade their existing ones to keep up with advances and improvements in OTHER software and it seems that sometimes when they do this SU is left wanting. Some clarity on what will improve performance is all that I am trying to get - but perhaps a new thread is the best place for that. Im kind of out of my depth on the 64bit discussion but from my layman's understanding, 64bit is not the issue and will not deliver any advantage in the short term - I just need to find out what will... But I think for me, thats for another thread...
Thanks
-
@samyell said:
I know newer doesn't always mean better, but people NEED to buy new machines or upgrade their existing ones to keep up with advances and improvements in OTHER software and it seems that sometimes when they do this SU is left wanting.
I doubt that ACAD takes advantage of multiple CPU cores (besides rendering/tesselation) as well as I doubt that SU doesn't take any advantage of a faster CPU.
But it's also true, that there seems to be a problem in SU with the user interface sometimes stalling whereas the hardware pretends to 'idle' at the same time. This behaviour surely needs to be analyzed by development (if not allready done) and reduced as far as possible resp. the interactive user interface of SU allows.
@samyell said:
Some clarity on what will improve performance is all that I am trying to get...
there is no 'magic' configuration which will unveil the full performance of SU if only configured, raw CPU power (with one kernel) helps surely most = highly-clocked Xeon or Core i7.
Norbert
-
I tend to agree with Thomthom - I don't know of any major CAD or graphics app that uses multiple cores for its basic functionality - so I don't see that multi-core is any sort of answer, and a different argument than changing to a 64bit environment. However, the 64bit environment is Night and Day for the major apps. For example, my experience going from 32bit versions of ACAD and PS to 64bit versions was an enormous change in responsiveness and usability.
Andy
-
@andybot said:
...I don't know of any major CAD or graphics app that uses multiple cores for its basic functionality - so I don't see that multi-core is any sort of answer...
From the Graphisoft page (http://www.archicadwiki.com/Multiprocessing)
@unknownuser said:
Is ArchiCAD multi-threaded?
Until ArchiCAD 12, ArchiCAD was not multi-threaded as a whole. Now ArchiCAD takes advantage of multiple cores / processors in various computationally intensive areas such as:
Generation of Sections and Elevations,
3D generation, loading and saving,
Drawing updates,
Placing PDF files as drawing (visual feedback when positioning the drawing),
LightWorks rendering ,
File saving with data compressing option,
Managing Autosave.
And In addition, ArchiCAD takes better advantage of the graphics processor in your display adapter.How many cores can ArchiCAD use?
ArchiCAD can use as many cores as you have, but do not expect double speed with twice as much cores. Since breaking down tasks to threads and keeping threads in sync takes time, more cores do not always speed up processes. In general, the longer a process takes, the more multiprocessing helps. It is definitely worthwhile to have a dual-core machine, and if you are working on large projects, 4 cores are even better. In some cases 8 cores are faster than 4 cores, but you will not see a difference as big as going from two to four.When will ArchiCAD be fully multi-threaded?
The multithreading in ArchiCAD brings a dramatic increase in performance over previous versions, but ArchiCAD will not be a fully multi-threaded application at any time soon. This is partly because re-writing the ArchiCAD code to support multi-threading is a huge task, and there are areas where it would not cause a dramatic performance increase. Graphisoft continues to focus on those areas where multi-threading brings the most benefit to our users.Now you know one...
-
Well, the last paragraph pretty much says what I said - it's the core functionality that isn't multi-threaded, and that's what understand TT has been saying too. There are just some linear/ serial processes that can't be easily multi-threaded. Sure, if LO can get multi-threaded for some operations, that would be great.
-
For further comparison, here is Autodesk's answer to questions about multi-threadedness in Revit:
The following tools in Revit (all disciplines) take advantage of muliple processors and multiple core processors for calculations which increases the performance of the tool in Revit.
Vector printing
2D Vector Export such as DWG and DWF
Rendering (4 Core Limitation lifted in Revit 2011)
Wall Joins representation in plans and sections
Element Loading. Loading elements into memory is multi-threaded, reducing view open times when elements are displayed for the first time in the session.
Parallel computation of silhouette edges (outlines of a curved surfaces) in perspective 3D views. Engaged when opening views, changing view properties, and navigating the view and will be more noticeable as the number and complexity of curved surfaces increases.
Translation of high level graphical representation of model elements and annotations into display lists optimized for given videocard. Engaged when opening views, changing view properties and will be more noticeable as the number and complexity of model elements increases.
File Loading
Point Cloud Data OverlayWhat you should notice in both these lists (from Graphisoft and from Autodesk) is that it isn't core modeling operations which are multithreaded. Instead, it is "rendering" kinds of processes and other peripheral operations which can be accelerated in this way. Multithreading just isn't a technological panacea for CAD applications.
john
. -
-
What could be an interesting thread - and a useful one for the SketchUp team if spesific bottlenecks in SketchUp was described. Without the interference of speculating on how it'd be technically solved.
We had some items mentioned already here.
- Explode
- Save Operations
- Export (Particularly animation)
Building on that I would say that some of the bottlenecks for me is:
- Adding geometry to a context slows down in relationship to the amount of existing geometry. I guess this one really goes into the obvious - "more geometry! More!!" ...
-
@jbacus said:
For further comparison, here is Autodesk's answer to questions about multi-threadedness in Revit:
...
What you should notice in both these lists (from Graphisoft and from Autodesk) is that it isn't core modeling operations which are multithreaded. Instead, it is "rendering" kinds of processes and other peripheral operations which can be accelerated in this way. Multithreading just isn't a technological panacea for CAD applications.
john
.good, so there's some general consensus on multi-threading. What about the original question about going to a 64bit environment?
Andy
-
@andybot said:
good, so there's some general consensus on multi-threading. What about the original question about going to a 64bit environment?
http://productforums.google.com/forum/#!topic/sketchup/cqdbwirP_T8
-
@jbacus said:
... that it isn't core modeling operations which are multithreaded. Instead, it is "rendering" kinds of processes and other peripheral operations which can be accelerated in this way. Multithreading just isn't a technological panacea for CAD applications.
As i said before, even if it is not "core modeling operations" which are multithreaded, but "only" saving, exporting, exploding, etc. it would be a huge benefit in some cases... no need to have a multithreaded Line-tool.
-
@thomthom said:
http://productforums.google.com/forum/#!topic/sketchup/cqdbwirP_T8
That thread is interesting to me because it shows how much my opinions have changed in the 2+ years since I posted there. At that time I was very much in line with the 32-bit apologists, but if you read carefully you will see why:
-
I recognized there was a limited amount of development that the SketchUp team was capable of and I would rather they put their energy into other tools (UV unwrap tools to be specific).
-
At that time there was no rendering within SketchUps process by Maxwell, so everything that got rendered was outside of the SketchUp 32-bit limited process.
So why the complete change of attitude on my part in just 2 years?
-
The supposed excuse of "limited resources" for development imposed by Google has theoretically been eliminated -- if that is so then why not wish/ask for more.
-
It has become clear to me that my pet toolset (proper UV unwrap tools) will never be embraced by John -- If I have to live with such a limited modeling /texturing toolset inside SketchUp then I want it to be the most robust platform it can be.
-
The technology around SketchUp has changed dynamically in the meantime and SketchUp seems to be stuck in a rut -- at first I was prone to believe it was a limitation imposed on the team by Google, but with John's recent comments here it has become clear to me that it is actually him that is the roadblock.
How much have things changed for me in that time-frame? At that time none of my software (except Maxwell) took advantage of 64-bit -- now all of them do... and I see better performance from all of them because of it. Not only that but not a single one offered excuses as to why they wouldn't do it, they just did it, because it was the obvious way forward.
So I can only come to one of three conclusions, either:
-
SketchUp was made in such a way that the core is impossible to update to 64-bit, and all of this is simply a distraction from that fact (which seems to be the most likely possibility).
-
Trimble is not serious about SketchUp itself being a competitive "Pro" product, and they have handed down directives to focus the dev teams attentions elsewhere (like Google did, but with a different focus).
-
John Bacus is going to be the death of SketchUp, because he stubbornly refuses to get with the times (I doubt this, because he would be fired before long if this were true).
Best,
Jason. -
-
@unknownuser said:
- Trimble is not serious about SketchUp itself being a competitive "Pro" product
I wouldn't judge about that already now but would patiently look into the future. There hasn't yet been a "Trimble" release of SketchUp (at least no feature release), and we know that Trimble makes certain devices etc. and deals with different sorts of data than Google.
-
Oh, I was more or less content to "wait and see" -- however John has already announced via his posts (in this thread) that there will be no 64-bit SketchUp (Pro or otherwise). So there's no point in waiting to gripe, might as well express my displeasure now, so I'll be happy again by the time SketchUp 2013 (ugh) is released.
At this point, aside from some talk about Layout getting some much needed love, I've got nothing to look forward to -- since AEC specific tools mean squat to me.
Best,
Jason. -
How about improved API that helps third party developers create better products?
-
No doubt, but that just costs me more money since those features won't be built into SketchUp and most of the things I want/need are paid plugins...
That's not to knock the plugin/3rd party people -- those people (including you) are the only thing which make SketchUp usable to me... so anything that makes your life easier I'm all for
However, it would be nice to be thrown a bone or two by SketchUp proper for a change.
Best,
Jason. -
Eager eyes waiting for SketchUp 2013
No pressure...
-
i agree 100% with jason
-
Advertisement