Discussion Visual Studio 2012 allows 64 bit build of Orbiter

[dumbo2007]

How about a 64 bit build of the core to allow access to more memory (> 4GB) for terrain data ? Apparently the x86 version of Visual Studio 2012 allows building 32 bit and 64 bit applications.

http://blogs.msdn.com/b/jasonz/arch...nd-net-framework-4-5-released-to-the-web.aspx

http://visualstudio.uservoice.com/f...s/2031185-create-x64-version-of-visual-studio

Has this been considered yet ? Most desktops have moved to 64 bit operating systems now.

Perhaps a 64 bit version of the core can be released for those interested in experimenting with terrain but do not need all the addons right away ?

 

[Urwumpe]

I am not sure if 64 bit really improves something there. While you can access more memory, your algorithms suffer often from being designed for 32 bit processors. It is pretty rare that a 64 bit version is really an improvement, especially under Windows.

 

[Hielor]

Switching to 64-bit can also expose bugs that were hidden previously, such as using 32-bit sizes for pointers--works fine on a 32-bit program, will crash on a 64-bit version of that same program.

 

[orb]

http://www.orbiter-forum.com/project.php?do=gotonote&issuenoteid=6703

 

[dumbo2007]

Switching to 64-bit can also expose bugs that were hidden previously, such as using 32-bit sizes for pointers--works fine on a 32-bit program, will crash on a 64-bit version of that same program.

But that's good for the application, no ? Then the changes to move to 64 bit will be carried out and Orbiter will eventually move to 64 bit anyway.

your algorithms suffer often from being designed for 32 bit processors

As in designed to consume less memory by smarter or more aggressive approaches ? Then a 64 bit application can benefit from that too.

Anyway I was just wondering that since building for 64 bit is now integrated in the main ide perhaps martins can give the core a spin in it and see what comes up. The addons do not need to be migrated right away but the extra memory access should help in getting better looking terrain and avoid sudden terrain changes due to delays in reading in stuff from disk.

 

[orb]

Anyway I was just wondering that since building for 64 bit is now integrated in the main ide perhaps martins can give the core a spin in it and see what comes up.

But building 64-bit code isn't new in the VS2012. It was already supported in the previous versions (i.e. VS2005, VS2008, VS2010), too. You only needed to have build tools installed for the x86-64 target.

 

[Hielor]

But that's good for the application, no ? Then the changes to move to 64 bit will be carried out and Orbiter will eventually move to 64 bit anyway.

Crashes and the like aren't generally considered to be good for an application, no.

 

[Urwumpe]

Also, you can already see how helpless people get, when a popular add-on is not updated ASAP.

 

[dumbo2007]

Yeah thats why I was saying that the 32 bit version can be kept around. The 64 bit version can be in addition to it as an alpha version. Its not like they are mutually exclusive.

 

[Urwumpe]

Yeah thats why I was saying that the 32 bit version can be kept around. The 64 bit version can be in addition to it as an alpha version. Its not like they are mutually exclusive.

But that would mean: Two branches of the engine, two branches of the API, two mutually exclusive add-on worlds. Currently, we couldn't even make a 64-bit proxy module for 32-bit add-on modules, because of the API structure.

 

[dumbo2007]

a 64-bit proxy module for 32-bit add-on modules, because of the API structure.

Interesting. Would such a proxy allow a 32 bit application to load 64 bit plugins ? Maybe a graphics client can be 64 bit and have access to higher memory and yet be loaded within the 4 gb memory space of the 32 bit core orbiter_ng.

Just curious, but whats there in the API which would prevent the proxy ? Is it the pointer sizes which Hielor mentioned before ?

 

[Urwumpe]

Interesting. Would such a proxy allow a 32 bit application to load 64 bit plugins ? Maybe a graphics client can be 64 bit and have access to higher memory and yet be loaded within the 4 gb memory space of the 32 bit core orbiter_ng.

Just curious, but whats there in the API which would prevent the proxy ? Is it the pointer sizes which Hielor mentioned before ?

No, but with some effort, you can have 32 bit applications that you can call by 64 bit applications. Not the otherway around. It is not easy, pretty nasty and requires a lot of effort because of the "two worlds".

You could for example have a 32 bit Orbiter Module container that is called by a 64 bit Orbiter over a defined interface. Would likely be slower than native 32 bit, but possible. The problem is just: You also need the static libraries of Orbiters in a way that such a proxy or wrapper is possible. Currently it is not.

 

[orb]

Would such a proxy allow a 32 bit application to load 64 bit plugins ?

64-bit Orbiter application would load 64-bit modules, and 32-bit Orbiter application would load 32-bit modules. Exchanging the data between 32-bit and 64-bit code would be done with interprocess communication.

 

[dumbo2007]

Hmm for the graphics client, I guess currently orbiter_ng actually loads the client plugin and communicates with it through shared memory(perhaps).

If this communication was through client-server sockets then the core and client could be 2 separate processes with different word sizes.

 

[orb]

Hmm for the graphics client, I guess currently orbiter_ng actually loads the client plugin and communicates with it through shared memory(perhaps).

It uses the plug-in's code directly by calling its callbacks (by using virtual table of registered in Orbiter pointer to the class instance) and the (DLL exported) API (used for example to create and register that earlier mentioned pointer to the class instance inside Orbiter). No shared memory, but common, single process addressing space.


On the bright side, 64-bit module interface could be completely rewritten, dropping all deprecated and obsolete parts, as all legacy modules would be still handled by the 32-bit Orbiter.

 

[RisingFury]

Why do you need 4 GB of RAM for terrain?!

 

[jedidia]

Why do you need 4 GB of RAM for terrain?!

I was wondering that myself... the processor/GPU able to process a four gigabyte heightmap in real time has yet to be built, I think...

 

[asmi]

Hmm for the graphics client, I guess currently orbiter_ng actually loads the client plugin and communicates with it through shared memory(perhaps).

If this communication was through client-server sockets then the core and client could be 2 separate processes with different word sizes.

No it's not - if that would be the case, the performance would be absent - thanks to certain API function (GDI, I'm looking at you)...

---------- Post added at 07:39 ---------- Previous post was at 07:37 ----------

Why do you need 4 GB of RAM for terrain?!

Well maybe because L12 heightmap is more than 2Gb?
But it's not about memory per se - it's about address space. In 64bit process, we could just map entire file into memory and let Windows take care of actuall loading/unloading parts of it as needed, while in 32bit we have to implement that paging in-out ourselves - and it's not an easy task.

 

[Urwumpe]

But it's not about memory per se - it's about address space. In 64bit process, we could just map entire file into memory and let Windows take care of actuall loading/unloading parts of it as needed, while in 32bit we have to implement that paging in-out ourselves - and it's not an easy task.

Ever heard of memory mapped files?

 

[asmi]

Ever heard of memory mapped files?

I'd suggest you to read again what you're responding to...
I take this as insult unless you will explain to me how to fit multiple 2GB+ files within 2Gb of address space. Remember MMF needs address space, and it's shortage is what lead me to consider going 64bit.