Sketchup 64 bit?
-
@thomthom said:
What we can (and should do) is let them know what feels slow - then let them work out how to address it.
Right, so here's a utterly basic one -- when I work with large files it takes 10-20 minutes to save and open them (forget auto-save it would keep me from being able to actually use the program).
I would like the time to save and open my files to take seconds not minutes... oh, and before the lame excuses start, no other 3D software has the lengthy open and save times (for the same files).
Best,
Jason. -
True that.
And the slowness of Explode - when you want to flatten the component hierarchy of a model.
Which by itself is probably related to SketchUp's auto-merge feature. Adding 1000 edges to a context (group or component) will slow down for each edge. I assume it's processing the entire content of the context you add to for each entity.Or the Component Browser window - when you navigate the browser to a folder with lots of components. While the file system (Explorer) lists the content quickly, and Ruby can enumerate the content quickly, the Component Browser is doing something which makes it very slow. And it does this every time to unroll the window as well.
Or right clicking on a material in the In Model list of Material Browser - when there are materials applied to many entities it just makes the window go unresponsive for a while - the menu finally flickers briefly to life before it disappear and you're unable to use the menu items. (I wonder if it's computing the total area of the material before displaying the context menu...)
Or the dreaded registry corruption that makes SketchUp spawn thousands of registry items which bogs down the performance completely until the registry items are erased and toolbars rebuilt.
So many things that can generally improve the user experience.
-
@thomthom said:
And as Hammond mentioned, many operations cannot be done in parallel - so multi-core processing isn't a magic bullet either.
I agree with you that Explode is extremely slow - and I hope this can be improved somehow. Though only the developers know how to do that. What we can (and should do) is let them know what feels slow - then let them work out how to address it.
i wonder if something like explode would actually be able to use multiple cores.. like each core is assigned to a group then explodes it.. when it's free again, it jumps to another group.. etc..
i honestly don't know what really needs to happen when trying to explode multiple groups at once but it just seems like an area of sketchup which could incorporate parallel operation..
-
Each core would have to test entities against all other entities, so they would have to share the data set. So when one processor accesses (reads/writes) the data set, it needs to be locked for all others to prevent inconsistent data (data corruption, see wikipedia). Probably no win (if you don't find a very clever way).
Most entities don't intersect anyways, so it is mostly a question how to quickly exclude those that don't share the same space (can be efficiently tested with octrees). We can also assume that the old entities don't need merge-tests with each other, as well as the new inserted entities (only between old and new).
I imagine splitting the data set into chunks for each processor is not easily done with vector graphics (maybe easier with voxels). -
Explode sucks! You need to plan your day around it!
-
Sometimes refreshing a scene can hang a bit. Intersect, and even save it just doesn't feel powerfull in these respects. And of course the odd crash. I've dabbled in other softwares and they feel bulletproof in these regards when compared.Of course the payoff is often the GUI and learning curve. I hope for performance improvements, if it has to be re-written at some point doesn't it make sense to ensure it's 64 bit for longevity ? Surely most operating systems will not support 32 bit apps at some point. Even if the only reason is addressing more ram wouldn't that enable better performance with complex scenes, even opening & saving ?
I have a feeling that the very core of sketch up, inferencing is the cause of a lot of the problems. Perhaps a simple toggle on or off would help.
-
@chedda said:
Even if the only reason is addressing more ram wouldn't that enable better performance with complex scenes, even opening & saving ?
No. There is only the ability to address more memory. Complex scenes and saving opening won't perform any faster with 64bit.
-
These 64-bit threads always seem to head in more or less the same direction— here's what I've gleaned from this one so far. People want the SketchUp team to work on:
performance improvements for all users: Users should be able to load, save, operate upon (ex: "explode") and render at interactive frame rates models with (some big number that gets bigger every time we increase overall system performance) of polygons.
Everyone always benefits from improvement to SketchUp's performance. The reality (for all software systems, not just SketchUp) is that performance is always bottlenecked somewhere. We're always working on removing the 'next' bottleneck in line. The 'last' bottleneck we worked on was rendering performance for large models— SU8 has an entirely new rendering pipeline. 'Merge' operations (implicated in 'ungroup', 'explode', 'import' &etc.) are a reasonable 'next' bottleneck to work on, though there are other"64-bit" as a technology, however, really offers no panacea for performance in SketchUp. Specifically:
- **64-bit modeling operations don't execute faster than 32-bit ones.**Look to faster CPUs for improvement to execution speed for core modeling operations. A single fast processor core.
- 64-bit computing does not improve realtime rendering performance. Look to faster GPUs for improvement to realtime rendering performance. Lighter models will always render raster than heavy ones.
- 64-bit computing does not improve file open/save performance. Look to faster disk I/O (as with SSDs) for improvement to disk-access operations. Larger files will always be slower to open than smaller ones.
- 64-bit computing does not improve software reliability. 64-bit operations are just as likely to crash as 32-bit ones. Submit crash reports when you can— that's the only way we can know what went wrong.
- 64-bit computing can address more memory, but SketchUp modeling operations are not bottlenecked by memory. Models of 1-2m polygons still fit neatly within 32-bits worth of memory.
improvements for developers: Rendering engines (mainly, V-Ray; to a lesser degree, Maxwell) should be able to execute 'inside SketchUp' in a 64-bit environment, rather than running their rendering in their own thread.
3rd-party rendering engines are free to execute operations in 64-bit environments if they design their architecture to do so. Many of them have done so today— there are significant architectural advantages to doing so. Some renderers, like Maxwell, market the ability to execute in a 64-bit environment (as well as the ability to do things like distributed network rendering) as an advanced feature that justifies purchasing their "Maxwell Studio" rendering suite.
Oddly, perhaps, the single strongest argument for a 64-bit "version" of SketchUp hasn't really come up in this thread yet. Developers who implement .skp import|export in their applications using our freely-licensed SDK will benefit from 64-bit builds of our precompiled libraries when they begin shipping 64-bit builds of their applications. They don't strictly speaking need them, but it would simplify matters greatly if they could have them.
john
. -
To clarify -- I'm always interested in performance benefits for all users... but Sketchup being what it is, and being limited in the ways it seems it will always be, it would seem to me that the most profitable outcome (for everybody involved) is to give developers the most robust platform (and 64-bit would absolutely be part of that).
One thing that doesn't get mentioned in your posts (perhaps because this doesn't occur to you) is part of the reason 64-bit support is not being clamored for by more developers is SketchUp's ongoing public perception as a "toy" -- therefore, many 3rd party developers won't touch SketchUp. The 32-bit limitation is certainly part of that perception -- and I think more developers would be attracted to the package if some of the development "bottlenecks" (like 32-bit limitation) were rectified.
However, most importantly, I cannot imagine a long-term strategy where Trimble benefits from SketchUp remaining 32-bit... Therefore, I think you are hiding something. After all, the most damning evidence is that going 64-bit is not that hard, for most software companies it is really more of a question of "why not" -- meaning, even if there is no tangible gains now, it is future proofing. Your inane resistance indicates that there is a much more compelling reason (to you) to not do it... one which you are not sharing with us.
Best,
Jason. -
Generally dumb question:
If staying low-bit is so refreshingly cool, why not develop 16 (or even 8 bit) version?
-
Obvioulsy, I'm no programmer, but doesn't 64 bit open the door for new avenues. As John stated, other plug-in developers would benefit from a 64 bit format. Maybe SU in its current configuration doesn't benefit from 64 bit, but what about the future; not only within SU itself, but how it works with other 64 bit programs (all the rendering engines I use)?
Again, to me speed is not necessarily the main drive of performance. A lot of that can be accelerated with hardware as John mentioned. I'm amazed what my new EVGA GTX 680 with 4Gb can do on (3) 47" monitors. Heck when I am moving quickly in orbit, all the materials stay rendered.
-
@rv1974 said:
Generally dumb question:
If staying low-bit is so refreshingly cool, why not develop 16 (or even 8 bit) version?16bit allows for ~65,000 individual values..
i don't know how many values something like a square polygon requires but with 16 bit sketchup, i'd guess we'd run out of memory somewhere under 10,000 entities.. and sketchup still performs very well with that size model..
32bit brings the number up to 4billion+ integer values.. if you had a sketchup model which would cause you to run out of memory, it doesn't matter anyway.. the model would be so incredibly sluggish that it would be absolutely worthless..
-
@jbacus said:
Oddly, perhaps, the single strongest argument for a 64-bit "version" of SketchUp hasn't really come up in this thread yet. Developers who implement .skp import|export in their applications using our freely-licensed SDK will benefit from 64-bit builds of our precompiled libraries when they begin shipping 64-bit builds of their applications. They don't strictly speaking need them, but it would simplify matters greatly if they could have them.
.
a few years ago, i was thinking collada would be the ultimate means of taking sketchup models in and out of other applications..
doesn't seem like it's going that route though.. at least with the other apps i use..
-
@jason_maranto said:
To clarify -- I'm always interested in performance benefits for all users...
Exactly, right? And that's what I care about as well. That's why I think it is worth spending time explaining these technical issues in such detail— I'd hate for folks to have the wrong expectations about the benefits available.
Whether you think of SketchUp as a toy or not, performance is really the key issue here. "64-bit" just isn't a technology which delivers the kinds of performance improvement you're looking for. Wouldn't you rather have our development team working on stuff that will make a material difference for you?
john
. -
I like how sketchup is so small, it's a tiny program or at least it used to be. Would it be so difficult to be re-written ? I am aware of my technology shortcomings, it's just that we were shown 64 bit as the way ahead by so many 3d apps and operating systems. Eventually 32 bit will be legacy code, i think that is a given right ?
btw i'm glad you have a presence here in the forum John.
-
@jbacus said:
Whether you think of SketchUp as a toy or not, performance is really the key issue here. "64-bit" just isn't a technology which delivers the kinds of performance improvement you're looking for. Wouldn't you rather have our development team working on stuff that will make a material difference for you?
I absolutely would like to see the team working on stuff that would -- however there are 2 parts to that:
- As yet I don't see that they are working on anything that will make material gains to me.
- I've demonstrated clearly that I know precisely what 64-bit support will mean, and I want it still.
Look, here's the thing, part of the reason I've been so aggressive towards you is you tend to cop an attitude of superiority... whether you mean to or not.
What I mean is comments like this:
@jbacus said:
"64-bit" just isn't a technology which delivers the kinds of performance improvement you're looking for.
I know precisely what I am looking for, and I know that 64-bit will deliver it. To say that I don't and it won't is insulting to my intelligence. Furthermore, you often say things dismissive of the intelligence of SketchUp users on the whole... we get enough of that from outsiders -- we don't need it coming from the top guy of the SketchUp dev team.
I resolved that if you would continue to treat us as idiots, then I would treat you as an idiot as well. I don't need excuses from you, I will help pay to keep your software in business based on what you do, not what you say... you will not be successful in convincing me to do otherwise.
So I suggest you use your time to write new code rather than post on forums arguing why we don't need XZY feature... I suspect if you did, you would find that alot more material gains would be made.
Best,
Jason. -
@jason_maranto said:
I know precisely what I am looking for, and I know that 64-bit will deliver it. To say that I don't and it won't is insulting to my intelligence.
He didn't say you didn't know what 64bit will deliver. You're reading a bit much into it.
He agreed earlier that 64bit have a benefit for render engines - and that, and the SDK, was one of the few areas where 64bit had any use. Further he does outline that it is possible for render engines to run their stuff outside the SketchUp process - so it's not like the current situation is a complete blocker for 64bit engines. I would think that is one of the reasons why 64bit doesn't float to the top of the to-do list. After years of being under Google which focused mainly on integration with their mapping services there are many many things that could be done to improve the product in other direction. And we're yet to see a full version Trimble SketchUp release.What he dismissed was all the other misconceptions that SketchUp will miraculously run faster or more stable. As people will be might disappointed with a 64bit SketchUp if they expect it to run faster.
The point of tension here appear to be mainly about different priority for the various features. I got mine, you got your, who knows where SketchUp's are at the moment. They've gone through internal changes this last year with new owners. And who knows what priorities Trimble sets. I guess we get a first hint on the next release.
-
Base camp was not encouraging... when he does post, the things he says have not been encouraging... so I can only base my opinions on the information available.
Well, that and the track record -- which has not been stellar. Which combined with the fact that it looks and sounds very much like "meet the new boss, same as the old boss", leads me to be a bit pessimistic.
I would love to be optimistic, and that is more my normal state -- but I have seen nothing to give any hope.
Best,
Jason. -
I'm positive you could not be directing your post at me... because that would just be stupid.
But then maybe I'm giving you too much credit...
You sell SketchUp right? Well where do you suppose SketchUp would be without all of the 3rd party plugin developers?
OK -- so now that we've established that insulting 3rd party developers is idiotic to suicidal for Sketchup developers... lets establish part 2.
Why, oh why, in the world should a 3rd party developer be forced to reinvent core programmatic elements that SketchUp has made no warranty they will not completely alter in near future builds?
Meaning, if I were to put alot of time and energy into doing just what you suggest -- what is to say they (SketchUp dev team) would not wipe out all the competitive benefits I've gained by my hard work at any point in time(and with no warning)?
In fact this scenario is extremely likely -- so as a 3rd party developer I am not touching that with a ten foot pole... the work should be done by SketchUp so that all interested parties benefit equally rather than each party re-inventing the wheel.
But more than that, any and all packages that are serious about supporting their 3rd party developers have already done so -- draw your own conclusions about the significance of SketchUp (Bacus) choosing to ignore this fact.
Best,
Jason. -
http://blogs.adobe.com/jnack/2009/08/a_64-bit_reality_check.html
nothing more to say.
The SU dev team should consider [url]carefully[/url]which projects they want to put resources on next. A 64-bit port of the already Large-Address-Aware SU (x86: 3gb / x64: 4gb) is surely a large and complex project that is of no apparent benefit to most of the users and only needed for sluggish plugin developers not willing to develop their own memory handling.
Modeling or alreay navigating/inferencing in complex models is bottlenecked by the rendering pipeline which is bound by the CPU/GPU and not by the available address room. Therefore SU models which consume more than ~2gb memory would be still slow/unusable even with a 128bit version (aka 'mine is bigger').
What really needs to be done and should be #1 on the 2do list of the dev team are speed improvements in the areas already mentioned above maybe by doing e.g. a profiling of the mentiond areas (if not already done) and rewrite the affected parts of the source in fast Assembly machine language (if not already done).
Advertisement