Jump to content

64 Bit Version of DCS possible?


Buznee

Recommended Posts

I've heard talk of DCS providing improved support for multicore CPUs but what about 64 bit support? Since it seems that DCS is very CPU intensive due to all the physics calculations does Eagle Dynamics have any plans of producing a 64 bit version of DCS? I could definately see some potential for greater fidelity in flight dynamics and complexities.

Link to comment
Share on other sites

I'm not sure 64bit would specifically improve the physics calculations (I suspect using GPU's would be better for that, but I don't know the code). The main gain from 64-bit would be the added adress space which would allow the executable to keep more things loaded within itself - for example more detailed terrain and so on.

 

Anyways, they did say somewhere that they will be doing 64-bit support before multicore.

[sIGPIC][/sIGPIC]

Daniel "EtherealN" Agorander | Даниэль "эфирныйн" Агорандер

Intel i7 2600K @ 4.4GHz, ASUS Sabertooth P67, 8GB Corsair Vengeance @ 1600MHz, ASUS GTX 560Ti DirectCU II 1GB, Samsung 830series 512GB SSD, Corsair AX850w, two BENQ screens and TM HOTAS Warthog

DCS: A-10C Warthog FAQ | DCS: P-51D FAQ | Remember to read the Forum Rules |

|
| Life of a Game Tester
Link to comment
Share on other sites

No, Nate, he must have messed up something.

 

64bit is nothing we ever will expect.

They told us and I can'tr find the thread they told us.

 

They said, was it Wags or was it EvilBivol, there's more to expect from multiprzessor than from a 64bit engine.

 

They had to overhaul the whole engine to introduce 64bit with only a very little advantage in compare with multicores.

 

That's whats stuck in my brain, so far.

Link to comment
Share on other sites

FWIW...

 

There's an article published somewhere... might have been on tomshardware although a quick search didn't reveal anything. To cut a long story short... moving to 64bits is mainly beneficial to the developer (i.e. compiling etc.). It won't improve performance in-game all that much, if any. Maybe somebody from ED (or any developer) could comment on this?

"It's not the years, honey. It's the mileage..."

Link to comment
Share on other sites

Actually I'm beginning to remember someone stating something along the lines of a 64bit engine was required before allowing for a larger more detailed terrain mesh and any more world objects. Not sure how this could work for all 32bit OSs currently in use though.

 

Either way I don't see it in the next patch.

 

Nate

Link to comment
Share on other sites

No, Nate, he must have messed up something.

 

64bit is nothing we ever will expect.

They told us and I can'tr find the thread they told us.

 

They said, was it Wags or was it EvilBivol, there's more to expect from multiprzessor than from a 64bit engine.

 

They had to overhaul the whole engine to introduce 64bit with only a very little advantage in compare with multicores.

 

That's whats stuck in my brain, so far.

 

You have it backwards.

 

Multithreading improves performance, but is a massive job. I have seen articles on tech sites explaining that making application X multithreaded generally means between two and four times as much development work and two and four times as much QA. However, it does improve performance quite a bit.

 

However, multithreading does not solve adress space issues, which is a severe limitation of 32-bit applications today. 64-bit applications will not cause much speed boosting (in fact, depending on how the software is constructed it can actually slow things down, since the memory adresses are bigger, but I am unsure of whether that was just a legacy problem with older 64-bit implementations).

 

However, porting an application to 64-bit is, compared to making the application multithreaded, a piece of cake. It mainly forces you to go through all those routines that handle memory and write them for 64-bit, and of course compile with a different compiler flag. (Then there's the QA bit to ensure that this didn't introduce obscure bugs.)

 

Making an existing single-thread application multithreaded, however, is a job the immensity of which cannot be overestimated. It basically involves going through every routine in the application and rewriting major portions of it to fit with a completely new process layout.

 

I'll see if I can find the thread.

[sIGPIC][/sIGPIC]

Daniel "EtherealN" Agorander | Даниэль "эфирныйн" Агорандер

Intel i7 2600K @ 4.4GHz, ASUS Sabertooth P67, 8GB Corsair Vengeance @ 1600MHz, ASUS GTX 560Ti DirectCU II 1GB, Samsung 830series 512GB SSD, Corsair AX850w, two BENQ screens and TM HOTAS Warthog

DCS: A-10C Warthog FAQ | DCS: P-51D FAQ | Remember to read the Forum Rules |

|
| Life of a Game Tester
Link to comment
Share on other sites

You have it backwards.

 

Multithreading improves performance, but is a massive job. I have seen articles on tech sites explaining that making application X multithreaded generally means between two and four times as much development work and two and four times as much QA. However, it does improve performance quite a bit.

 

However, multithreading does not solve adress space issues, which is a severe limitation of 32-bit applications today. 64-bit applications will not cause much speed boosting (in fact, depending on how the software is constructed it can actually slow things down, since the memory adresses are bigger, but I am unsure of whether that was just a legacy problem with older 64-bit implementations).

 

However, porting an application to 64-bit is, compared to making the application multithreaded, a piece of cake. It mainly forces you to go through all those routines that handle memory and write them for 64-bit, and of course compile with a different compiler flag. (Then there's the QA bit to ensure that this didn't introduce obscure bugs.)

 

Making an existing single-thread application multithreaded, however, is a job the immensity of which cannot be overestimated. It basically involves going through every routine in the application and rewriting major portions of it to fit with a completely new process layout.

 

I'll see if I can find the thread.

 

As an aspiring software engineer I'm looking forward to the link.

[sIGPIC][/sIGPIC]



64th "Scorpions" Aggressor Squadron

Discord: 64th Aggressor Squadron

TS: 195.201.110.22

Link to comment
Share on other sites

http://forums.eagle.ru/showthread.php?t=39270&highlight=64bit+multithread

 

From an old interview:

 

http://simmoders.com/index.php?topic=234.0

 

Any multi-core and DX10 plan along the way?

 

Multi-core support will likely be available in DCS at a later point, but right now our bigger focus is on providing full 64-bit support. 32-bit is currently limiting some of our options. As for DX10, we see no persuasive reason to add it at this time.

 

EDIT

As an aspiring software engineer I'm looking forward to the link.

 

Well, that link isn't really exhaustive, it mainly serves to highlight their decision as it is known to me.

 

Most of my references about the difficulty and gains of the two in my earlier post are not based on DCS or what people associated with ED/TFC has said, but rather articles I have read on Anandtech, Toms and various other sites, including some research papers related to massively parallell computing projects like Folding@Home.


Edited by EtherealN

[sIGPIC][/sIGPIC]

Daniel "EtherealN" Agorander | Даниэль "эфирныйн" Агорандер

Intel i7 2600K @ 4.4GHz, ASUS Sabertooth P67, 8GB Corsair Vengeance @ 1600MHz, ASUS GTX 560Ti DirectCU II 1GB, Samsung 830series 512GB SSD, Corsair AX850w, two BENQ screens and TM HOTAS Warthog

DCS: A-10C Warthog FAQ | DCS: P-51D FAQ | Remember to read the Forum Rules |

|
| Life of a Game Tester
Link to comment
Share on other sites

Multithreading improves performance, but is a massive job. I have seen articles on tech sites explaining that making application X multithreaded generally means between two and four times as much development work and two and four times as much QA. However, it does improve performance quite a bit.

As a developer, its not really true to say that making an app multithreaded will generally add two to four times development. sometimes doing things in a thread solves some problems and can make application time shorter. the thing to remember is that many developers do not understand threads and start using them willy nilly and get themselves into a corner. e.g. race conditions, thread safety, attempting to update the UI from a worker thread, spawning a thread from the main thread and then waiting on it (defeats the purpose).

 

 

However, multithreading does not solve adress space issues, which is a severe limitation of 32-bit applications today. 64-bit applications will not cause much speed boosting (in fact, depending on how the software is constructed it can actually slow things down, since the memory adresses are bigger, but I am unsure of whether that was just a legacy problem with older 64-bit implementations).

indirectly it can. logically, you place resource loading into another thread and perform asynchronous IO freeing up the main thread. if you used just one thread then it would have to wait for the memory, at least with threads you can do something else at the same time.

 

 

However, porting an application to 64-bit is, compared to making the application multithreaded, a piece of cake. It mainly forces you to go through all those routines that handle memory and write them for 64-bit, and of course compile with a different compiler flag. (Then there's the QA bit to ensure that this didn't introduce obscure bugs.)

ya thats pretty easy. if you're a good displined c++ programmer your typedefs for pointers and such won't change really.

 

Making an existing single-thread application multithreaded, however, is a job the immensity of which cannot be overestimated. It basically involves going through every routine in the application and rewriting major portions of it to fit with a completely new process layout.

agreed. rewriting an application to use threads that did not use threads in the first place would be a nightmare so i agree with you there. then again rewriting an application is always a nightmare. though it does not require rewriting every routine. some parts of the application will never benefit from being made multithreaded, re-written in parallel et al. :thumbup:

  • Like 2

hardware: Alienware Area-51 7500 - 2x 8800 GTX 768 MB SLI - 4GB RAM - Vista 64-bit - Saitek X52 Pro - TrackIR 5 Pro

Link to comment
Share on other sites

FWIW...

 

There's an article published somewhere... might have been on tomshardware although a quick search didn't reveal anything. To cut a long story short... moving to 64bits is mainly beneficial to the developer (i.e. compiling etc.). It won't improve performance in-game all that much, if any. Maybe somebody from ED (or any developer) could comment on this?

 

well, theoretically 64 bit is more than allowing for more memory, it also increases the word size of the CPU for one thing allowing it to store larger integer values in registers which is a boon for calculations. where previously you may have to break up a number into multiple memory locations and resort to trickery to achieve the same result albeit slower. hopefully they have increased the size of floating point registers and increasing floating point precision which has caused issues in the past.

 

for example, in my motorola 6809E assembly programming days, i thought it was pretty neat the 8-bit CPU with 8-bit word could mulitply two 8-bit values and shove the result in a single 16 register. that allowed for a max size of 65535 unsigned or -32768 --> +32767 signed. what fun we had. it even had a hardware divide instruction which took a significant number of cpu cycles.

 

then along came the motorola 68000 - a 16 bit cpu with 16 bit word[1] and so many address bits i dont remember. the registers are now all 32-bit instead of 16 in the 6809. now suddenly we could store much larger values and perform much more trickery. with each incarnation, CPU cycles for an operation may change or a new instruction is introduced that replaces a few steps in the old cpu.

 

now apply this to the move from 32 bit to 64 bit cpu and you'll get an idea.

 

the above sounds like a pro when you consider a CPU-bound application like BS.

 

i think i know the article you mentioned, i've been madly trying to find it.

  • Like 1

hardware: Alienware Area-51 7500 - 2x 8800 GTX 768 MB SLI - 4GB RAM - Vista 64-bit - Saitek X52 Pro - TrackIR 5 Pro

Link to comment
Share on other sites

though it does not require rewriting every routine. some parts of the application will never benefit from being made multithreaded, re-written in parallel et al.

 

Yeah, sorry, my grammar was a bit unclear there. I didn't mean rewriting major portions of every routine, just that you need to get yourself a clear picture of what all routines do so you know which ones you have to work on splitting and so on. Should have had a divider of sorts in the sentence structure there.

 

That aside, great thanks for your elucidation on various aspects of my post. As always there is greater complexity than first meets the eye - and complexities that go both ways in the argument. Threw you some rep for that. :thumbup:

[sIGPIC][/sIGPIC]

Daniel "EtherealN" Agorander | Даниэль "эфирныйн" Агорандер

Intel i7 2600K @ 4.4GHz, ASUS Sabertooth P67, 8GB Corsair Vengeance @ 1600MHz, ASUS GTX 560Ti DirectCU II 1GB, Samsung 830series 512GB SSD, Corsair AX850w, two BENQ screens and TM HOTAS Warthog

DCS: A-10C Warthog FAQ | DCS: P-51D FAQ | Remember to read the Forum Rules |

|
| Life of a Game Tester
Link to comment
Share on other sites

EtherealN, you should be banned for using the word "elucidation". :D

Dusty Rhodes

 

Play HARD, Play FAIR, Play TO WIN

 

Win 7 Professional 64 Bit / Intel i7 4790 Devils Canyon, 4.0 GIG /ASUS Maximus VII Formula Motherboard/ ASUS GTX 1080 8 GB/ 32 Gigs of RAM / Thrustmaster HOTAS Warthog / TrackIR 5 / 2 Cougar MFD's / Saitek Combat Pedals/ DSD Button Box FLT-1

Link to comment
Share on other sites

beugnan knows his stuff. I've done lots of multi-threaded stuff, and there is definitely a huge advantage to using it, but depending on the original design it can be a major rework. Most multi-player engines nowadays are multi-threaded which is fairly easy to do because the sockets are inherently multi-threaded for ansync I/O, but who knows about the physics(s) engines. I'm sure putting the player's ship in it's own thread is feasible, but what about the campaign engine etc? And you have to have some marshalling for all the different threads, so with an app as complex as this I'm guessing it would be a bit of a nightmare. I honetly don't miss working in game development- the atmosphere was fun, but more often than not you're tasked with extremely daunting problems such as this.

Link to comment
Share on other sites

But I love that word! :P

 

If you want something obscure, you should learn words like matutolypea ("getting up on the wrong side of the bed"), or parapraxis (bit like a "freudian slip"). Tonnes of fun ones out there. :D

[sIGPIC][/sIGPIC]

Daniel "EtherealN" Agorander | Даниэль "эфирныйн" Агорандер

Intel i7 2600K @ 4.4GHz, ASUS Sabertooth P67, 8GB Corsair Vengeance @ 1600MHz, ASUS GTX 560Ti DirectCU II 1GB, Samsung 830series 512GB SSD, Corsair AX850w, two BENQ screens and TM HOTAS Warthog

DCS: A-10C Warthog FAQ | DCS: P-51D FAQ | Remember to read the Forum Rules |

|
| Life of a Game Tester
Link to comment
Share on other sites

Yeah, sorry, my grammar was a bit unclear there....

 

...Threw you some rep for that. :thumbup:

 

no problems buddy

 

sweet! thanks :)

hardware: Alienware Area-51 7500 - 2x 8800 GTX 768 MB SLI - 4GB RAM - Vista 64-bit - Saitek X52 Pro - TrackIR 5 Pro

Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...