Trimble & Sketchup 64 bit
-
Once upon a time Layout supported multi-core, but due to problems this was dropped and I don't believe it was ever fixed/reinstated... this to me is absurd because Layout is very much a render engine.
I wonder how long the user base will accept the "it's too hard"/"we don't have the resources" excuses... I mean really, after observing the situation for the last several versions, I think that if all the time and energy put into making excuses for why we can't have/shouldn't want these things was instead routed into coding work we would have a vastly superior product... instead we got alot of lip service.
Google is gone, time for talk is done -- it's results we need now... and not more "kinda fixed" solutions like the toolbars joke.
Best,
Jason. -
@jason_maranto said:
Once upon a time Layout supported multi-core, but due to problems this was dropped and I don't believe it was ever fixed/reinstated... this to me is absurd because Layout is very much a render engine.
Layout wasn't getting much love fro Google. Things are changing under Trimble.
-
@thomthom said:
Layout wasn't getting much love fro Google. Things are changing under Trimble.
I consider that to be most excellent news
Best,
Jason. -
@jason_maranto said:
I wonder how long the user base will accept the "it's too hard"/"we don't have the resources" excuses...
Actually, what you're getting from us is a clear discussion of the technological reality of 64-bit computing. Unfortunately, that reality does not match your expectation of the benefit that 64-bit computing should bring.
This is a topic that appears to defy rational discussion. That said, I will continue to argue rationally for real and appropriate performance improvements in SketchUp
john
. -
I think you are making a very large assumption about my lack of understanding -- I sometimes find your stances on technical issues to be condescending towards the general user base as well... I get the distinct impression that you think we are all incapable of using powerful/complex tools and need your great wisdom and insight to guide all of us idiots into 3D nirvana.
I know exactly what 64-bit will give me and it has everything to do with my render engine.
Direct SketchUp performance is an afterthought to me in this discussion... because my render engine cost me more than twice what SketchUp Pro did, so my first concern is getting the most out of that purchase.
If Sketchup can't or won't deliver to the level of a basic industry standard, it's not that difficult to find a replacement that will, after all virtually every other professional 3D package supports 64-bit without issue.
I enjoy using SketchUp, but I also need a professional tool -- and right now Layout is the best thing SketchUp Pro has going for it.
Alternately, you could simply go with truth in marketing and remove the "Pro" from the name -- and then I would have little to complain about.
Best,
Jason. -
@sketch3d.de said:
...Core i7-3740QM
if he wants to build a notebook... yes.
@sketch3d.de said:
This is just not true, most apps available are still 32-bit because they simply do not benefit from accessing more than 2GB RAM
interesting... and this is the reason why sketchup is now large adress aware... right?!?
yes, my microsoft word never needs more than 2GB...
sorry, but this is the most stupid statement in this whole thread... yes, there will always be apps that don't benefit from more processing power or more RAM because they don't need it. And even sketchup will not benefit from more speed if you're modeling only a cube! But i can tell you, that working on a 200MB+ model in sketchup is not really funny... (i'm not speaking about high res textures, but geometry! textures are already all the lowest low res dummys) 2-3 min auto saving time is really a joke for 200MB... the only thing you can do is to disable the autosave.
And you will wish for 64bit if you have to split the geometry into parts to be able to export it to the renderer or if you have to restart sketchup after every single export, because sketchup doesn't fully clear the memory after export and you run out of memory on every second or third export... (it's better now than before but still there)
And it IS just true! because this is the way processing power will evolve in the next years... the future is parallel. Single core performance improvements got more and more limited in the last years (sandy to ivy was ~5% and Haswell will get ~10% - great!) and if you want more speed you have to use the other 7, 11, 15, 23 or 31 idling threads of your system!
And if it may be hard to implement multicore support for single modeling operations, i really don't get it why it isn't already used at least for rendering animations, background saving or running ruby scripts in a second process.
If i render an animation i have to split the sequence in 5 or 6 parts and start the rendering on 6 different sketchup instances. Is it really that complicated to do this automatically from one instance?!?
-
@samyell said:
Taking advantage of 64bit, multi core machines is the direction that everything seems to be moving in ..... except Sketchup.
This is just not true, most apps available are still 32-bit because they simply do not benefit from accessing more than 2GB RAM. I do not know even one recent 3D modeler which uses multiple cores for modeling_purposes. Dassault/Spatial has announced some multi-threading for the faceter of their ACIS r23 NURBS modeling kernel.
A fast desktop system which will fulfill all of our needs would be:
• CPU : 3rd generation intel Core i7 'Ivy Bridge' Quad-Core = Core i7-3770K
• GPU : mid-range nVidia GeForce GTX = GTX 650 Ti
• RAM : 8GB
• SSD : Samsung 830/840 for OS and main apps[update]
corrected CPU/link
[/update]hth,
Norbert -
@numerobis said:
@sketch3d.de said:
This is just not true, most apps available are still 32-bit because they simply do not benefit from accessing more than 2GB RAM
interesting... and this is the reason why sketchup is now large adress aware... right?!?
Because we (the users) asked for it as a quick-fix for the render engines that ran inside SketchUp. I asked for it as I was running out of memory while rendering in V-Ray with some models. Setting the LARGE_ADDRESS_AWARE flag was a "quick-fix" that solved a problem I had with V-Ray for SketchUp - not SketchUp itself. I've yet to see anyone run out of memory with plain SketchUp tools.
@numerobis said:
And even sketchup will not benefit from more speed if you're modeling only a cube! But i can tell you, that working on a 200MB+ model in sketchup is not really funny... (i'm not speaking about high res textures, but geometry! textures are already all the lowest low res dummys) 2-3 min auto saving time is really a joke for 200MB... the only thing you can do is to disable the autosave.
Nobody is saying that SketchUp doesn't benefit from being faster. Just that 64bit isn't a speed performance solution.
@numerobis said:
because sketchup doesn't fully clear the memory after export and you run out of memory on every second or third export... (it's better now than before but still there)
Then surely the correct thing to ask for is for SketchUp to release its memory, clean up after its operations, fixing what you describe as a bug? (Though I've never seen this behaviour.)
@numerobis said:
And if it may be hard to implement multicore support for single modeling operations, i really don't get it why it isn't already used at least for rendering animations, background saving or running ruby scripts in a second process.
If Ruby runs in a separate process you are separating it from the SketchUp core which its need to communicate with.@numerobis said:
If i render an animation i have to split the sequence in 5 or 6 parts and start the rendering on 6 different sketchup instances. Is it really that complicated to do this automatically from one instance?!?
"Rendering animation" - as in exporting from SketchUp? (or using a render engine?)
Exporting animation is a process where I'd think multi-core processing could be possible. Though, I'm note sure how the pipeline works, but it sound plausible.However - all of this stems what to what I've been trying to get across: Tell the devlopers what is slow - them let them solve how to best achieve that.
-
-
@numerobis said:
@thomthom said:
...64bit isn't a speed performance solution.
yes, sure...
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?
-
@numerobis said:
interesting... and this is the reason why sketchup is now large adress aware... right?!?
why do you cite me distorting? 'samyell' claimed that just 'everything' is 64-bit which I simply denied, nothing else.
That there is a need for a 64-bit version of SU for several users with very big models is obvious and surely more feasible than implementing multi-threaded modeling operations... which all of the 'big boys' did not get working for their much more expensive, full-blown CAD modelers until yet.
@numerobis said:
...and if you want more speed you have to use the other 7, 11, 15, 23 or 31 idling threads of your system!
sorry, but this is the most stupid statement in this whole thread... just because the hardware does develop in this direction multi threaded modeling operations are not simply a compulsive consequence but need also be doable in the sense of mathematics, i.e. many if not all modeling operations are based on several calculations each dependent on the result of the calculation before and therefore are serial by nature.
@numerobis said:
Is it really that complicated to do this automatically from one instance?!?
I was talking of modeling operations only and have already proposed to use multiple threads for doing e.g. file operations parallel to the modeling thread at the offic. Google group long ago (see links above).
thanks,
Norbert
[update]
grammar, still
[/update] -
I though we all established long ago that SketchUp isn't really so much a complete package but rather a platform... if that's true than it would be a pretty sorry platform that doesn't support 64-bit. SketchUp was pretty cool 5 years ago -- but alot of time with no significant developments has allowed its competitors to pass it by.
I'm not asking SketchUp to be anything more than it really is, a platform for better software and plugins that use Sketchup as a host shell.
However, I think it's pretty clear that it won't happen, there's no way one of the dev team (and such a prominent one) would stick their neck out publicly so soon after the transition without a clear idea of will happen on the subject. They would simply be setting themselves up for public embarrassment later when they have to hype the 64-bit feature as a good thing.
Best,
Jason. -
@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
. -
Advertisement