What is 64bit all about?

[Kevin McAllister]

There is a lot of talk about VW and 64bit. You could automatically think 64bit must be better than 32bit. I was curious and saw this article today -

http://news.cnet.com/8301-1035_3-57602372-94/the-real-reasons-apples-64-bit-a7-chip-makes-sense/

Seems things aren't as simple as you might think. While some of it is specific to the mobile sphere, in the middle there is a great explanation of 64bit computing and what its advantages and disadvantages are.

The biggest advantage I can see for VW is access to memory but at the moment I've never seen VW use more than about 2.5GB. At that point, more often than not, it crashes. That's significantly below the 4GB ceiling that 32bit creates. So I'm guessing there are other limitations under the hood in VW that need to be sorted out first.....

Something to think about anyway....

KM

[Tom Klaber]

No it is a big deal. It is true that there are a lot of sectors that may not benefit directly from 64bit architecture, but CAD/Modeling software is definitely one that does. I am not sure why you are hitting a 2.5GB ceiling, it maybe because the other 1GB (32bit can actually only access a little more than 3.5GBs) is being used elsewhere on the computer and so what VW is asking it to do pushes it over the edge.

The more processes VW can run at once combined with the more information it can hold in rapid access, the better the performance will be. It will also allow the creation of complex tools and operations that require more memory to run correctly.

[Kevin McAllister]

Thanks Tom. I'm definitely a layman when it comes to this. And I'm certainly not downplaying the importance of 64bit. It just sounds like there may be other issues at play that are equally as important.

NV is aware of the 2.5-3GB ceiling I mention. I only know where VW starts to fail on my system because of some discussions with Tech Support regarding a sheet layer viewport rendering issue. I actually have 16GB of system memory, plenty for anything else that is running.

Personally I think the lack of support for multicore processors is more of an issue. I hate watching VW use a single core (other than the Renderworks engine) while almost everything else uses all of the cores available on my machine.

KM

[taoist]

They are delaying the inevitable.

Can't keep adding features and not have the software utilize the hardware.

It's not like 64 bit is something entirely new.

Archicad is 64 Bit

My other CAD software is 64 bit.

I realize that it would require coding changes.

They could have been working on this for years and have it ready to go.

It's not like they are only working one item.

Yes, multicore would be a great help.

I feel like we are being held back due to there lack of improvement in this area.

IMHO

[IanH]

There is a lot of misinformation about 64bit. People talk about 64 bit as if it is one thing, but its not, there are two sides to 64 bit and I would bet that VW has been 64 bit for many many versions.

I almost commented in a recent thread where there was a really uneducated pop at VW not being 64 bit until their phone was. However I decided against it.

I was one of the pioneers of 64 bit computing, having converted a major banks trading system from 32 bit to 64 bit 20 years ago. We were used as a beta tester for the compilers manufacturer who also designed the chip (DEC Alpha for anyone interested). I also do a bit of iOS development and now the announcement has been made, I can say that 64 bit tools are now available to us.

What does 64 bit mean?

It means that registers and bus' in the chip are 64 bit long/wide, instead of typically 32 bit. This means that one operation can work on a number twice the binary size, or, do things in one operation that may have previously taken two.

OK. What does 64 bit really mean?

These registers are used for a number of things, such as holding numbers or holding memory addresses. So a 64 bit processor can process larger numbers more efficiently or reference more memory.

Do we make use of these larger registers now?

Yes and no. Most applications are compiled using compilers that can handle these bigger numbers. Even on a 32 bit operating system, if you have a 64 bit processor (as most processors are these days) and was built using the 64 bit settings (typically enabled by default), you will be taking advantage of these 64 bit numbers. I would be highly surprised if VW was not doing this.

However, to take advantage of 64 bit addressing, you need first to be using a 64 bit operating system and to compile the system in 64 bit addressing mode.

Are there any downsides to 64 bit?

Yes. Many numbers do not require 64 bits to hold them so do not take advantage of the extra speed. In addition, many data structures contain data smaller than 32 bits, such as 1 byte. For some applications, this can cause a major problem when migrating from 32 bit to 64 bit due to the way that the chip works in 64 bit chunks and how the compiler optimises data structures. To take advantage to the extra speed offered by 64 bits, numbers must be aligned on 64 bit boundaries otherwise the number needs to be fetched in two operations, one fetch for the part on one side of the boundary and another fetch to get the bit on the other side. So this can cause things to run *much* slower. To avoid this, humans or compilers can optimise the structure by moving numbers within the data structure around to avoid larger numbers spanning a boundary. And this needs great care especially with older applications where numbers/etc within the data structure are expected to be found in certain places. So you can subtly break an application and may not even be aware of it. And thats even before bad practices of 'casting' (using a number in a way that it was not intended, ie casting pointers to memory locations and integers is common practice, and so are casting characters and integers) one structure into another.

64 bit numbers looks potentially problematical but 64 bit addressing looks a no brainer to me?

Well, unfortunately no. I briefly mentioned casting pointers to memory locations and integers. Well, if your integer is 32 bit and your address pointer is now 64 bit, you have to change something. In addition, many applications share memory between processes. How this sharing mechanism works may have changed - in windows, part of the memory at the top of 4GB address is used for shared memory and assume that OSX does similar. Not withstanding having to build for 32bit and 64 bit version and test etc etc, the final nail is that takeup of 64 OS being so recent, there is much legacy code build for 32 bit that, to be honest, isn't ever going to be converted to 64 bit. So if you app uses third party libraries that are 32 bit, you are stuck in a 32 bit world, a very costly/slow process of re-enginerring the application to use a different library/method (which I suspect is the route that VW is taking) or using a very inefficient method where every time you need to call the library, you convert from 64 bit to 32 bit, call the library, then convert back to 64 bit. For library that are called very frequently, this can cripple an applications performance.

Do I need 64 bit for my application?

Well it depends. To be honest, I would expect 64 bit data structures in any modern application, but the gains in performance on this can be quite small or even negligible and done poorly, a negative performance increase.

64 bit addressing on the other hand is very much mis understood. People often confuse memory with regard to RAM/Virtual memory, 32/64 bits, OS/application/processes/threads and talk themselves into thinking that they need more RAM or a 64 bit OS. At the end of the day, the 32/64 bit limits refer to the amount of memory that a single process can address. The amount of RAM in a system has no bearing on this. Taking 32 bit OS, a process can address 4GB of virtual memory, of which none, some or all of this may be in physical RAM. Out of this 4GB, it is generally split 50/50 or 75/25 between process only and system/shared. So for ease, lets simply say that a process can address 2GB virtual memory and a bit of shared memory that is application dependent. Now, if you application runs as a single process, then your application can address 2GB virtual memory. However, if you now split your application across multiple processes, then each processes can address 2GB virtual memory. This is how VW and Renderworks is likely to work. Whether the Parasolid engine runs as another process I do not know, but theoretically, Parasolid could run as a separate process too, and all of a sudden, you have an application that can handle 3 times the amount of data/code as previously.

So 64 bit is not all its cracked up to be.

For anyone interested, the banking application that I converted from 32 bit VAX to 64 bit Alpha took about year and a bit to convert, start to finish. It was I suspect, much larger than VW and in a typical configuration, ran across 50 or so processes, some fairly autonomous whilst others made significant use of shared memory between processes. It held in core, details of every single FX and MM trade undertaken in that bank that day plus details of every single cashflow in every single currency from that day into the future - iirc 30 years for MM trades. It was alot of data, however, even the trusty 32 bit VAX's could handle it. Out of the year or so time to convert, there was about 6 months analysis/converting the code/waiting for release versions of compiler, 4 months writing conversion routines for the data structures, 3 months testing, and time for release. And throughout 75% of that, we were constantly having to work with other developers who were producing new/changed functionality.

I don't personally think that VW is dragging its heels as in some ways, the reliance on third party software and inability to perform much automated testing (we had hundreds of reports that we could compare between releases) makes for added complexity.

[Christiaan]

I almost commented in a recent thread where there was a really uneducated pop at VW not being 64 bit until their phone was. However I decided against it.

It's jest Ian. Nemetschek aren't dragging their feet, they just behind on nearly every front and who knows why? 64-bit is just one example. The fact that a mobile phone and associated software is 64-bit before our professional CAD software is pretty telling.

The fact of the matter is we have 64-bit machines and GBs of memory that VW is unable to take advantage of. And it shows when we're trying to do everything in 3D. The amount of memory errors/crashes we've had since moving to 3D is unacceptable.

[Ozzie]

Apple is also dragging their feet especially when it comes to phones or tablets

Why people keeping hanging onto them astounds and amazes me

I am confident VW will address the 64 bit issue; maybe not in this release coming ? who knows?

Must be a huge amount of work to convert all that code

I upgraded from VWLMRW 12 to 13 this week and was surprised at how good it is

Pushing a large project for three days and have had very few or no crashes

But ... am running W8 on a fast puter

And ... not trying to start a Mac vs Windows thingy - just what goes on in my working life

[IanH]

I will add one point further. I personally do not believe that VW will ever become 64 bit.

They will start from scratch/buy in third party system and come up with something that will do 20% of what VW does now and do that well. The remaining 80% will be functionality that is rarely if ever used. People will moan just like they do now, but will soon learn that the new functionality will do 99% of what they need just like VW does now, just in a slightly different way.

Vectorworks is a huge cumbersome animal that has long had its day. The annual updates seem to break as much as they add, a sure sign that a piece of software design is well past its sell by date.

I think... I hope Vectorworks know that. There is just so long that a design can be bent, stretched and used for things that it was not originally intended before it eventually breaks beyond repair. Sometimes you need to step back, put the box of sticking plasters away, start over and build something new using the lessons learned from what has gone before and embracing the best of technology available now, not 20 years ago,

For me, Vectorworks knew that the moment they bought into the subscription model. It gives them breathing space to come up with something new and introduce functionality by stealth that no one would pay for otherwise but will ultimately provide familiarity for when the new system is revealed.

Whether it is called Vectorworks or not will be down to the marketing department.

Just my 2p but I say it with my ex development managers for what was once the worlds largest bank hat on.

[Christiaan]

That doesn't ring true with their Parasolids efforts though. Why go to all that trouble to do under the hood stuff if the plan is to ditch?

[J Lucas]

I was told by at tech rep, two or so years ago, that they are if fact working on the transition to 64 bit and that they expected it to be rough.

[Ilay]

Ozzie

Must be a huge amount of work to convert all that code

Hm, i manage plugins of c4d in visual studio, between x86(win32) and 64-bit(mostly it's easy to switch x86 to x64, click to which build need to compile)...but stack if used new additional libs(like intel embree) which will handle normally at x64(need more RAM)

currently Maxon dropped win32 or x86 platform...

I think why not x64:

1. management of security options as licensing

2. several plugi-ns which used or mentioned by Ian as used technology are x86 platform based

example - sketchup reader, but new x64 reader appeared in latest sdk from Trimble

(i'm sorry for my English)

Edited September 12, 2013 by Ilay

[PVA - Admin]

It is happening slowly but surely. Renderworks was the first up since the engine behind it was being replaced anyway a few years back, so it was exactly the right moment to go ahead with 64 bit for that module. Especially since it would benefit the most from losing the low RAM cap that 32bit suffers from.

As time goes more and more components are being replaced, but a lot of people think "Well just press the 64 bit button, its simple." and it really isn't.

Vectorworks has been built up as a massive and complex pile of tools over the course of nearly 30 years, none of it is that old any longer of course, but you get the idea. As dependences in the application on older code, or things like QuickTime are removed, then more and more of the application can be moved to 64bit as it should be.

[Patrick Fritsch]

Thank you Jim for the "open" dialogue. It's very comforting for users like us to know the eventual NV roadmap when our livelihood dollars rely on it.

[Tom Klaber]

I was told too by a rep that they have been working on 64bit. My source stated in no uncertain terms that it was VW's dependence on QuickTime that was holding things up. He thought they would be able to release a 64bit version in 2015 - along with some other major workflow / referencing improvements.

This was over a year ago, so I do not know if the timeline is still current.

[ray isaacs]

jim.

thanks for joining the conversation and letting us hear the story from the vw side. as patrick said, it is comforting.

cheers,

ray

[Ilay]

Hello Jim

As time goes more and more components are being replaced, but a lot of people think "Well just press the 64 bit button, its simple." and it really isn't.

i agree and it's not easy to switch between different OS like Windows and Mac

also, as i understood

1. vw v.2014 like c4d 14 will be for x86 and x64

2. next v.2015(with rw based at c4d r15) will for x64?

[Kevin McAllister]

Thanks to Ian and everyone for all of the insights. They really help in understanding it all.

KM

[PVA - Admin]

also, as i understood

1. vw v.2014 like c4d 14 will be for x86 and x64

2. next v.2015(with rw based at c4d r15) will for x64?

Vectorworks 2014 will work on both 32 and 64bit OSes, but will not have different versions foreach, it will have some modules that will take advantage of 64bit and some that wont.

There wont be a two applications labeled "Vectorworks 2014(x86)" and an "Vectorworks 2014(x64)" for instance, as you find with some other software packages like Cinema 4D currently.

If you install it on a 32bit OS, then everything will still function, but have none of the speed benefits.

I do not know for sure about Vectorworks 2015 as far as having different "flavors" for 32 and 64bit. (Even if I did I would unfortunately not be able to discuss it until it became official. No offense intended, policies and all that.)

Edited September 13, 2013 by JimW

[Ilay]

Thanks a'lot for reply.

I understand.

I do not know for sure about Vectorworks 2015 as far as having different "flavors" for 32 and 64bit. (Even if I did I would unfortunately not be able to discuss it until it became official. No offense intended, policies and all that.)

I'm sorry for asking(i forgot about nda of vw's roadmap)

But thank you and to your team for python bindings!

(can we also use cython in it's environment?)

Edited September 13, 2013 by Ilay

[Christiaan]

So as expected with VW 2014 we still run into out of memory errors and crashes. I expect until VW is capable of addressing more memory via 64-bit this problem is going to stay with us.

[Christiaan]

I will add one point further. I personally do not believe that VW will ever become 64 bit.

They will start from scratch/buy in third party system and come up with something that will do 20% of what VW does now and do that well. The remaining 80% will be functionality that is rarely if ever used.

Missed the mark on this one Ian!

So 64 bit is not all its cracked up to be.

Personally I'm loving not being plagued by out of memory errors!