Who said SketchUp doesn't need to be 64 bit?
-
Just my personal experience, IĀ“m using blender for about 3 years, for some reasons I had to use the 32bits version since last year. DoenĀ“t notice any difference besides simulations and rendering, I end up outsourcing those to my home laptop, there is no difference in the viewport performance between 32 or x64, I can work with projects ranging from 100 to 300Mb with no problems.
-
I have some childish idea (before Bacus finally buried SU):
Let's organize some kind of petition* with our vision of the x64 agenda and send it to the Trimbe Executive Team.
*moderators could send PM with plea for signing to all 200K SCF members.
What do you think? -
@jaceguay said:
Just my personal experience, IĀ“m using blender for about 3 years, for some reasons I had to use the 32bits version since last year. DoenĀ“t notice any difference besides simulations and rendering, I end up outsourcing those to my home laptop, there is no difference in the viewport performance between 32 or x64, I can work with projects ranging from 100 to 300Mb with no problems.
I suppose you haven't read the entire thread...
As far as I've seen so far, no-one is claiming that 64bit will make SU run any faster...
The primary reason users want to see a 64bit version is the use of i.e. 3rd party integrated render applications, where SU - being 32bit - is the culprit because of the RAM limitation...
But it's also a request to make SU compatible with future computer systems as well as a hope that it will be able to handle high poly models better than what it can today... -
@frederik said:
@jaceguay said:
Just my personal experience, IĀ“m using blender for about 3 years, for some reasons I had to use the 32bits version since last year. DoenĀ“t notice any difference besides simulations and rendering, I end up outsourcing those to my home laptop, there is no difference in the viewport performance between 32 or x64, I can work with projects ranging from 100 to 300Mb with no problems.
I suppose you haven't read the entire thread...
As far as I've seen so far, no-one is claiming that 64bit will make SU run any faster...
The primary reason users want to see a 64bit version is the use of i.e. 3rd party integrated render applications, where SU - being 32bit - is the culprit because of the RAM limitation...
But it's also a request to make SU compatible with future computer systems as well as a hope that it will be able to handle high poly models better than what it can today...Yes you right it is not just about the viewport, itĀ“s almost heartbreaking to see so many incredible plugins that are exclusive to SU to be locked in a single thread x32 enviroment.
Besides, blender viewport is high selective of what is shown, for example, by default you wonĀ“t see any edges until you enter edit mode for a specific object, much of the modifiers values that should increase drastically RAM usage are only computed at render time, and you can also set different display modes for some part of your model, like wireframe or bounding box, you donĀ“t loose any functionality by doing this because it automatically switch back to the complete style when you enter edit mode for that object.
ItĀ“s a good idea for managing large scenes but you loose the view of the whole, GPU renderers should be making up for this. -
@pixero said:
Wow, this thread has really taken off.
A worrying thing is that it seems they haven't even started converting to 64 bit to future proof SU.If it isn't then please tell us what the bottleneck is and fix it.
By the way, how many developers are they? Does anyone know?
Those of you who were at Basecamp maybe have a clue.<I don't know but looking at some of the info they posted on basecamp and the new release of scan explorerI can only conclude their main focus has been support of other effort.
Is there anyway to run some diagnostics in the background that if SU runs out of memory makes a dump of all running processes and memory used at that point?
When these crashes appeared I didn't get a bugsplat I simply got that popup and another with "The application has unexpectedly closed". And it was gone. -
@solo said:
May I ask if SU works better on a 32bit machine than on a 64bit machine as a 64bit needs to emulate 32bits which in essence slows it down?
All else being equal between two CPUs where one is 32-bit and one is 64-bit, a 32-bit application will run at the same level of performance on both. Therefore, the underlying architecture of the CPU is irrelevant for a 32-bit SketchUp executable.
Here's where it gets fun.
We are absolutely certain that if we were to compile identical SketchUp code for 32-bit and 64-bit, and then benchmark the performance of the two on the same 64-bit computer, the 64-bit version would be slower.
-- "How much slower?"
We don't exactly know. Making that determination involves some very complicated analysis and a great deal of investigation that we don't think is worthwhile. After all, since I mentioned that we're somewhat resource-constrained, it would make more sense just to spend that effort in a real migration instead of making a prediction about it. The quick glance we did at this suggests there could be a slowdown of as much as 25%, or as little as 5%. Regardless, all else being equal, many of the CPU-based activities in 64-bit SketchUp would be slower than their 32-bit counterparts.
We hold in very high esteem the fact that we have continually improved SketchUp's performance with every single release. We are not opposed to releasing a 64-bit version of SketchUp in general, but in light of this, I think you can understand that we would be incredibly averse to releasing a new version of SketchUp that performs more poorly than its predecessor, no matter whether there's a mitigating reason. I can't say we'd never release something with a backwards step in performance, but it'd be a hard pill for our team to swallow.
Therefore, you can assume that the production of a 64-bit SketchUp would precipitate the need to invest even more resources in performance improvement than we normally would, in order to try to make up for the added deficit imposed by 64-bit compilation. This would of course increase my previous manpower and time estimates.
My point in explaining all of this is simply that, while those of us on the SketchUp team really do understand the frustrations of our users who run into problems due to the current 32-bit memory limitation, we must also be keenly aware of the massive investment required to produce that change, including all of the other desired fixes and features that would have to be sidelined in order to make it happen.
Andrew
-
@jeff hammond said:
can't ask a mac user.. the last two OS releases have been 64bit only.. ... also of note (maybe) is that even apple's lesser hardware (phones and tablets) are 64bit now... obviously, i'm not a developer but from a user pov, they're sending a pretty clear message.. quit making 32bit applications.
Jeff,
I think the perceived message of "quit making 32-bit applications" is just a side-effect of Apple's circumstances.
Apple's switch from PowerPC to Intel CPUs in 2006 marked a perfect opportunity to simplify development substantially by beginning the universal adoption of 64-bit CPUs. The funny thing though was that even they didn't make the transition quickly. Although there were already 64-bit PowerPC CPUs available, they weren't universally so, making Apple continually drag their 32-bit stuff along in the OS until they felt comfortable dropping PowerPC support. They also didn't release their new hardware with full 64-bit support as they could have. For example, our "Apple Xserve1,1" build servers from that era had 64-bit CPUs (as have all Intel Macs ever released), but not the 64-bit EFI necessary to utilize them. As such, they only supported the 32-bit kernel!
Finally abandoning 32-bit platforms altogether required Apple to consciously drop support for all of the old PowerPC architecture, which we saw them do a few years after switching to Intel, but then also had to abandon several of the first generation of Intel-CPU-based Macs in order to get to a complete level of universal 64-bit kernel support across the board. That only just happened within the last 18 months, IIRC.
Even so, this transition was lightning fast in comparison to what's happening in the Windows world. 15 years ago, people hoped Alpha and then Itanium CPU platforms for Windows would signal the end of 32-bit Intel domination in the PC market, but those both fizzled. Intel still reigns supreme and the fact that they still manufacture 32-bit CPUs, coupled with the open architecture of the Windows platform means that unlike Apple, Microsoft doesn't get to dictate the death of the 32-bit platform, whether on desktops or on less powerful embedded systems like ATM machines or tablets. As such, as long as the hardware is out there, it's in their interest to keep making software for it. This symbiosis means there's still a very large market of 32-bit machines being sold (I think it's around 10-20% of new PCs).
I think we see the same thing echoed in iOS vs. Windows tablets. Apple has the luxury of dictating 64-bit across the board, which just serves to simplify their lives massively, so they do, and then--BOOM--that's the way it is.
But my point here is that I think that the reason Apple is making everybody do 64-bit applications now is not because there's an incontrovertible technical advantage, but because of the massive simplification they created across their whole hardware and software development business by leveraging their god-like ability to dictate a single hardware platform across their kingdom. Third-party developers needing to fall in line with what they do is just a side-effect of a move Apple made to greatly benefit themselves.
...
Now, consider this: If only SketchUp had the luxury of being able to drop 32-bit support altogether, how much easier it would be for us to make the jump to 64-bit. With no 32-bit, there'd be no doubling of our testing surface, no making separate installers, no need to write all kinds of help center articles to explain to the masses how to differentiate the two releases, no modifying our store to provide different products, no educating our resellers about the differences, no translating all of that junk into a dozen languages, etc., etc., not to mention the cost savings associated with all of that.
I can't blame Apple for ditching 32-bit; that's the world I'd like to live in, too! But maybe this helps explain why adopting 64-bit while still supporting 32-bit would really suck, just like Apple saw for the 5-6 years they were in transition to the 64-bit-only approach.
Again, this means opening the 64-bit can of worms is even more expensive than just the effort required to create a 64-bit capable SketchUp.
Andrew
-
oh. I was thinking it would be more of 64bit sketchup replaces 32bit sketchup but I see what you mean about still needing a 32bit version around.. at least for a while (sort of like when you had ppc and Intel support with the mac version)
on a side note-- I'm a 'victim' of the 64bit only thing with osx since I still own a 1,1 Mac Pro.. I thought it was longer than 18months ago when it lost OS support but you're probably about right.. whenever mountain lion was released.
-
appreciate your detailed responses...
Sketchup, as well as Apple, no longer support 32bit hardware, so we may as well be your crash test dummies...
Maybe you can purge the 'carbon' that's still floating around...
24/04/2014 21:59:24.756 SketchUp[22606: *** WARNING: -[NSImage compositeToPoint:operation:] is deprecated in MacOSX 10.8 and later. Please use -[NSImage drawAtPoint:fromRect:operation:fraction:] instead.]
john -
Thanks for the response Andrew.
I do not know the technicality of what is needed or what is going to work better however I do know what I'd like to be able to achieve with Sketchup.
Maybe we can start a new thread and have a real discussion of what can be done to help us with higher poly models, not how to model leaner but rather how SU can be "fixed" to handle more complex scenes.
Many folks believe going 64 bit or multi thread would help, maybe even having a way to turn off the inference engine, I do not know so maybe we can all discuss and perhaps even find a direction y'all may be willing to investigate.
-
Thanks for taking the time to explain the intricacies involved. I think your comprehensive assessment of the current situation puts matters into perspective.
I wonder if the situation might be leveraged for the generation of an Ultimate SketchUp Pro 64-bit version (with all the bells and whistles sought by power users) via a Kickstarter-like venture? Have a look at what the power of crowd-funding can produce here, Kickstarter's 10 Biggest Success Stories http://www.cnbc.com/id/48725154
Mike
-
@jeff hammond said:
i highly doubt anybody from trimble is going to talk about this anymore.. pretty much anything that can be said about it already has.. at this point, it's either going to be 64bit or not and i don't think the end users have any say in the matter.. up to now, the stance is pretty much "if you want sketchup to be 64bit then too bad"
I agree, it does not look like SketchUp is going the 64bit route anytime soon.
Architosh recently stated that: "As a realtime rendering system (OpenGL-driven) there is no performance benefit for making SketchUp a 64-bit application." and quoted Bacus saying: "While there are increasing numbers of CAD developers offering 64-bit versions of their applications, it really isnāt a given that 64-bit computing (access to more memory) improves their performance.ā
Bacus also claims that: "SketchUp wonāt run out of system memory until there are tens of millions of polygons in a model, well past the point where any modern graphics card is capable of rendering the scene.ā
Link to article @ Architosh. The 32/64bit part is covered at the end on page 2.
-
@frederik said:
I suppose you haven't read the entire thread...
As far as I've seen so far, no-one is claiming that 64bit will make SU run any faster...
The primary reason users want to see a 64bit version is the use of i.e. 3rd party integrated render applications, where SU - being 32bit - is the culprit because of the RAM limitation...
But it's also a request to make SU compatible with future computer systems as well as a hope that it will be able to handle high poly models better than what it can today...I have the impression that Bacus is either not aware of this or does not understand the problems as most of his comments point out the performance part of the discussion.
-
Thanks for replying.
If nothing else, it's good to know your thoughts on the subject. But why are you so secretive about the future?
It's not like you have released a whole lot of cool new features that the competition would have stolen if they known about it.
I think we all know more about upcoming products from Apple than the tiniest bit about where SketchUp is heading.
As a professional user that is frustrating. "Is the next SU version going to fix [i]"this" problem or should we invest in some other software?" is a question we repeatedly ask our selves.[/i]I'd welcome a serious discussion about what is most problematic with SU for us power users and ways for you to fix those problems.
Now if 64bit version isn't the solution to working with heavy SU files what is?
I've never heard any explanation to your statement that 64 bit isn't the solution.
Could you please tell us what the bottleneck is?Why is it that if I have some heavy geometry in SU all of a sudden some soft edges become hard edges?
Why is loading and saving big scenes take forever?
In Photoshop you can press save and immediately continue to work. All saving is in the background.I could go on ...
I must say that some of John Bacus statements seems like he doesn't understand the importance of some of our wishes. Like his statement that quads isn't necessary.
I honestly don't understand why he is saying this and why he is using this arrogant way of expressing himself.
It's like he doesn't care for our needs. I feel I was a fool to believe that quads was one of the reasons he hired Thomthom.
Quads ARE important and could be incorporated into SU without the average user ever noticing.I feel that if there is to be some kind of discussion the initiative must come from you. Open up a bit!
A discussion, no wish list! We've done that already. -
Very well said Pixero. I think that pretty much sums up how many of us feel after the post-Trimble releases and Bacus' negativity towards power users.
-
@Andrew, very much appreciated you took the time to write here.
I guess, the 64bit discussion will be over for now. My concerns about Sketchup's future direction and the steps being considered to help us meet our clients growing demands though are not over.
For a lot of people here, working with Sketchup is a big part of business and thus affecting our time and income. If the same wishlists re-appear after every new release of Sketchup, at some point people can't afford anymore to stick to Sketchup and will switch to another program.
Communication is key, so please if you can, come back more often and share some insight about Sketchup's near future direction and, if possible, post again about our biggest concerns.
kind regards,
Max
-
@pixero said:
I know J. Bacus have said that: "Access to memory is not the bottleneck in SketchUp where 'more geometry' is concerned."
If it isn't then please tell us what the bottleneck is and fix it.The boring reality of this answer is that there isn't a single bottleneck. It's not as simple as just tweaking a single point in the code and everything runs in instant time.
There are many areas where performance can be improved, no doubt about it. But the discussions are much more fruitful if they are about "what is snow" instead of users discussion various guesses to what technical solution should be applied. Don't be blinded by buzz words as 64bit and dual-core - that's not the only thing that makes an application fast and responsive - far from it.
If you think that these two things (which very often come up) will fix everything then you will be forever disappointed.
If you experience that SketchUp crashes when it's memory usage exceeds ~3-4GB then you do have a real need for 64bit. So far, this really only happens when a third party process like a render engine is running inside of the SketchUp process instead of spawning a separate one.
But if anyone reading this thread thinks 64bit will have any performance impact, forget about it. It simply isn't.Dual core? Most modern computers these days have four cores. Now, for the sake of conversation, lets says that any operation could be split up and run in parallel, the max gain would only be a 4x increase. Consider how slow Explode is on a large terrain model. A 4x increase would not be enough to make that operation fast.
The real gain is made by improving the algorithms and data structures. Good algorithms are the true heros of performance. But there is no one-fit-all. There is no magic bullet.
Performance improvement is a continuous work and I can assure you it is of a high concern within the SketchUp team. But let us keep discussions at a higher level than low level technical level.
-
@pixero said:
But why are you so secretive about the future?
It's not just friendly ears that listen...
-
@tt_su said:
It's not just friendly ears that listen...
Spock is a member?
You know Spock had 3 ears didn't you? His left ear, his right ear and his final frontier
-
@kaas said:
For a lot of people here, working with Sketchup is a big part of business and thus affecting our time and income. If the same wishlists re-appear after every new release of Sketchup, at some point people can't afford anymore to stick to Sketchup and will switch to another program.
Here is my personal take on this, we need to nurture a larger third party developer community around SketchUp using SketchUp as a platform to provide a rich range of tool suites. Given the incredible large and diverse user base the best way to get quality tools for the different user types is to have more professional developers catering to the market. Each free to run their own direction based on their specific target user base.
I wish we where there already, but we still got a good amount of work to do.
Advertisement