Sketchup 64 bit?
-
@unknownuser said:
What about animation export? Or high res .jpeg export? Why wouldn't processes like these work faster, similar to the benefits 64 bit processing provides other render engines? Same would go for LO.
it's not that they will work faster.. it's just that they will work to begin with..
say you want to export 40,000px wide jpg... you can't do it now in sketchup as you'll run out of memory.. with 64bit sketchup, you could do it but it's going to take a long time..
via David Rutten.. developer of grasshopper for rhino.. (which is a 64bit app)
@unknownuser said:
64 bit applications do not run faster and do not use less memory. In fact they probably use a little bit more memory. The only real difference between a 32 and a 64 bit application is that you can access more memory on 64 bits. So you can load larger files and generate more data.
Every time you store something in memory it has to be stored at a specific location. We call this location an address. The first thing you store can be stored at address 0*. If that thing requires a total of 18 bytes, then addresses 0 through 17 are used up. The next thing you store can then be stored at address 18. And so on and so forth. At some point you run out of addresses and when that happens there is no more room to store any new data and there is thus nothing more that your app can do and that's usually when Windows shoots the application in the head and buries the remains behind the chemical sheds.
The total number of unique addresses that can be represented by a 32-bit integer is 4,294,967,295 (4 GigaByte). However Windows only allows a 32-bit app to access 2GB, or potentially 3GB if a special switch is set. A 64-bit application is allowed to use 64-bit integers to identify memory addresses, which means the highest possible address is now 18,446,744,073,709,551,616 (or 18.45 ExaBytes). Basically, as long as you have RAM to back you up, a 64-bit application will not run out of memory. Of course it may still become prohibitively slow as a lot of data requires a lot of computation and 64-bitness does absolutely nothing to make things go faster.** Not true in reality, Windows will already use up some of the available memory just to load the application.*
-
I believe the future will see much more diversity in hardware architectures, but at the same time due to (para)virtualization, thin client (or mobile) + cloud architectures, the technical realization will become less relevant. It's not something we will bother with.
Some softwares even have been back-ported to 32 bit, just because at the moment that showed better speed performance.%(#222222)[
@unknownuser said:When an application can run fine either in 32-bit or 64-bit mode, the 32-bit mode tends to be a little faster. Larger pointers means more memory and cache consumption, and the number of bytes of CPU cache available is the same for both 32-bit and 64-bit processes.
@unknownuser said:
All those pointers that used to need 4 bytes, now they need 8. For example, the default requirement in Emacs is 60% more memory when it's built for a 64-bit architecture. This extra footprint hurts performance at every level of the memory hierarchy: bigger executables take longer to load from disk, bigger working sets cause more paging and bigger objects mean fewer fit in the processor caches.
]
A 64-bit SketchUp would actually require more memory, but that alone is obviously not reason enough to port it.%(#222222)[
@unknownuser said:The plan is to include 64bit functionality.
]
So we "know" that someone at Trimble thought the next SketchUp version would include something with 64 bit functionality. And we know Trimble wants to integrate its services in various ways. And what if it is just a 64bit Explorer thumbnail extractor extension (because Explorer can't use the 32 bit thumbnailer)? No hint so far that it will be the SketchUp engine itself. Let's wait and see.@unknownuser said:
What about animation export? Or high res .jpeg export?
We can't look into SketchUp to see why it's not as fast as we wish, but there could be a lot of reasons. And there could be a lot of solutions. When speaking about graphical things, doesn't that remind you of a certain high performance component of your computer**?**
-
@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
.
Advertisement