Trimble & Sketchup 64 bit
-
@phillip said:
After reading this thread with great interest over the last week, the 64bit question seems quite emotive, perhaps because it in some way encapsulares the frustration which stems from uncertianty as to the direction Sketchup will take. A vague promise of an update sometime in 2013 does little to ease the dissonence.
Those more confident about a 32bit future seem quite defensive, moverover they also seem to be those closer to the development team, which in its own way can be taken as both reassuring and worrysome - i am sure the ambiguity is not lost on most. I get the distinct impression that for some this is a dicussion we are not meant to having.
Unlike some, I would place compatability and robustness above speed for Sketchup moving foward.
Apart from the discussion there are other indicators, the amount of advertising on here for render engines experesses the most obvious Sketchup functional shortfall, while the odd advertisement for Bonzai3d circles like a vulture awaiting either Sketchups demise or the fallout from all the uncertianty.
Perhaps a robust release of a Luxrender plugin and a plugin organizer as an interum update for both free and paid versions of Sketchup, together with a future roadmap for Sketchup would placate most, certainly me.
I was all in on your post till Bonzai3D, they haven't updated that producy at all in years!
-
Probably the deciding factor for SU going 64bit will probably be when Windows comes in only 64bit versions. There's been talk about for a while - some time back it was talked about Windows 8 being only 64bit - but it got postponed.
These 64bit (and multicore) discussions always goes astray - so I'll just repeat one thing: 64bit doesn't make thinks go faster! (It appear to be a common misconception)
And to reiterate Andreas; we're better off asking for the end result instead of getting blind on a guess to what technical solution might achieve that result. Just look at this thread - full of speculations and guesses. Brings us nowhere.
@sketch3d.de said:
Also, having x32 and x64 versions doubles the expenditure for maintaining and releasing
Aye - a pure 64bit release of SU might save development time for new projects - but at the expense of existing products. -
@phillip said:
Those more confident about a 32bit future seem quite defensive, moverover they also seem to be those closer to the development team, which in its own way can be taken as both reassuring and worrysome - i am sure the ambiguity is not lost on most. I get the distinct impression that for some this is a dicussion we are not meant to having.
It's just that for the most of it, the 64bit topic is brought up on the incorrect assumption that it will solve all of SketchUp's problems.
Concrete highlighting of the actual issue is better: Explode is way too slow. Better animation of scenes. More performance to build larger models. (This they (the team) have announced that they're always committed to - but it's an everlasting arms race.)
-
-
I'm also working on a 64bit windows 7 installations on several different computers with different hardware. In some instances I've experienced instability in sketchup that makes the software unusable. It will constantly crash for seemingly random reasons though most commonly when processing polygons such as when exploding a group or when running a plugin that creates polygons. It also tends to do massive amounts of lag when running autosave or when opening files of any size.
Through trial and error I've found that the issue is not directly Sketchup but something to do with multi-core processors on certain motherboards. It may be the bridge or threading technology integrated into the board that's at issue. I've only had this problem on boards using DDR3 PC1333 Ram and Intel processors but the ram and processors involved may or may not be a coincidence.
Generally I've solved this issue on my machines by going into the Windows Task manager, showing processes from all users, finding the sketchup process, right clicking on it and selecting "set affinity" and chosing a single core for processing. This effectively eliminates multi-core processing but Sketchup didn't multi-thread anyway. it means my system specs are over kill for sketchup but it makes sketchup at least usable in the environment. -
Hi dynath:
On the basis of your comment- and my interpretation of it, what would you say would be an effective permanent solution? You have just suggested 3 possible players in this scenario. Windows, Intel, and Sketchup.
You had to take the extra effort to isolate a work around, and I believe this sort of thing could(should) automatically resolve itself by one of the three entities mentioned. Or, all three could implement a resolution.
Thanks for your insights. -
There was similar issue with Painter 12 when it was released and I came up with the same solution (manually set affinity) -- eventually they released a patch that allowed the user to specify the number of cores used in the preferences.
This is something that should be trivial for SketchUp to do.
Best,
Jason. -
Phew - this is doing the rounds everywhere I look! Been on the look out for how to upgrade our current studio machines to maximize performance on our core apps and Sketchup seems to be a constant block to any possible improvements. We use SU, Max 13, Adobe Creative Suite 5. The GPUs Im looking at are EITHER best for use with Max, (Nvidia) OR SU (AMD). I should point out that this is just what I have found as there is no official line from Trimble / Google / Sketchup / Developers on GPUs. Multi core is better for Max (rendering) and all of the creative suite as is 64bit but SU prefers single core and 32 bit. Its impossible to bring these two into line and its very frustrating that such a fantastic product as SU should make it so difficult to move forward and take advantage of advances in new tech.
I get that currently 64bit may not be faster and that SU only takes advantage of a single core (as does Max when modelling) but it isn't practical to expect people to have to run one older single core 32bit set up for SU and a newer 64bit multicore setup for everything else. Taking advantage of 64bit, multi core machines is the direction that everything seems to be moving in ..... except Sketchup.Ive searched extensively for several weeks now looking for the best spec upgrades of new PC to enable our studio to work with SU and the other packages that are an essential part of my (and many others) working day / night / weekend and have so far come up with nothing. The requirements of SU seem to conflict with everything else!
For me , SU runs pretty well (some occasional crashes and stalls) but I know if I had an older 32bit single core machine it would be blazing! LO's performance quite frankly, is shocking when you hold it up to any other CAD drafting package and there is so little documentation to help me to make an informed choice on what to do to fix it!
The frustration for me is that ther seems to be a lot of speculation, missing or bad information regarding CPU and GPUs for SU and there is practically NOTHING for LO and as someone pointed out earlier there is no development path outlined anywhere so its impossible to know what direction SU will be going in and whether LO will see any (sadly lacking) development. Can't find anything to tell me if any of the upgrades Im hoping to make will have any effect on LO, and it now seems I will have to split my work between two machines to see any perofmance improvement.
The info in this page
http://support.google.com/sketchup/bin/answer.py?hl=en&answer=36208
is useful but there is no referene to-
single core 2+ GHz processor being better than multi - what speed multi is good as most other packages need 64bit multi to work efficiently?!?!
-
2+ GB RAM - I have 6GB ram - is it worth getting more?
-
3D class Video Card with 512+ MB of memory or higher. Please ensure that the video card driver supports OpenGL version 1.5 or higher and up to date - any other recommendations on this would be useful as upgrading GPUs for all our machines is a considerable cost, what works and what doesnt?!
I bit more information from Trimble to the interested and eager SU community at large would go a long way to keep people sweet and reassure them that SU will be moving in a positive direction.
-
-
@samyell said:
but it isn't practical to expect people to have to run one older single core 32bit set up for SU and a newer 64bit multicore setup for everything else.
But you don't need to have a separate setup for SU... 64bit multi-core runs SketchUp without problems. You get quad cores that are 3-4GHz these days for a decent price. No need to choose between a faster single core or multicore - because CPU's doesn't really run any faster than 3-4GHz anyway.
@samyell said:
Taking advantage of 64bit, multi core machines is the direction that everything seems to be moving in ..... except Sketchup.
As you mentioned, the other 3d packages that use multi-core use the multiple cores for rendering. SketchUp doesn't have a rendering engine like they do. The render plugins we plug into SketchUp makes use of it though - so the net result is the same.
-
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]
Advertisement