Sketchup 64 bit?
-
@anteolic said:
This is full email from my gmail for evrybody who think that i don contact really sketchup team.But the biggest problem now is that evrybody says that there will not be 64bit sketchup, and i got answer with 64bit funcionality. What that mean
The sales personnel must have mistaken something. I talked directly with the developers, referring to this thread. The next SketchUp version will not be 64bit.
-
Does being 64 bit allow sketchup to be multi-processor aware ? Some commands like explode or group etc really take a long time. Also i had hoped the stability issues would be addressed by this move.
-
@chedda said:
Does being 64 bit allow sketchup to be multi-processor aware ? Some commands like explode or group etc really take a long time.
nah.. they are linear processes (or.. 1 woman makes a baby in 9mos but 9 can't cook one in 1month.. not even 64bit ladies)
@unknownuser said:
Also i had hoped the stability issues would be addressed by this move.
yeah.. sketchup would more_likely_than_not get better, faster, and more stable upon going 64 bit..
not because of the 64bitness.. but because the devs will be making lots of changes to the core in order to go 64bit so while they're in there tinkering around, they'll be more likely to address some other long needed changes.. -
@chedda said:
Does being 64 bit allow sketchup to be multi-processor aware ? Some commands like explode or group etc really take a long time. Also i had hoped the stability issues would be addressed by this move.
No - the only thing 64bit gives an application is the capability of addressing more memory. That is it. Nothing more, nothing less.
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.
-
@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.
Advertisement