Iff you could have one thing in the next update it would be. (Archive)
-
@A.S:
Soo, let me ask stuipid then. Why they invented 64bit systems in the first place then?
Because 32-bit systems can only adress a given amount of RAM. To be precise: 2Ā³Ā² bits. (AKA ~4GB.)
To go back a bit, you said this:
āRegards your answer refering to 64bit suggestion. DonĀ“t you think it would benefit to address all cores.āHereās where I think youāre getting confused; 32bit vs 64bit isnāt about āadressingā cores. Itās about memory adresses. Like this: whenever the computer needs to access or write to memory, it accesses a given memory location. To find this location, it uses an adress. Pretty much the same way the postman uses your adress to find you, or a phone number is used to find your cell phone, or an IP adress is used to find your computer. The memory space is how many adresses are available. (Compare with the ongoing transition from IPv4 to IPv6 for internet; weāre actually running out of IPv4 adresses nowadays, so IPv6 is being phased in to give us a lot more of them.) In a 32-bit system, you have 2^32 adresses. In a 64-bit system, you have 2^64 adresses. You can see this in effect quite easily; take a 32-bit system (or install a 32-bit OS) and try to use it with 8GB of RAM. Youāll find that you donāt get to use your 8 gigs; it stops at 4.
āAdressingā cores towards using them for computation; that is, the processing of instructions, is done with threading. This is a different thing; you can multithread just as easily (or rather, with the same amount of difficulty) on 32-bit as you can on 64-bit. Indeed, multithreading has been done on 32-bit (and 16-bit) waaay back. There is no difference, from a programming perspective, between multithreading an application on a multi-core CPU and doing it on a multi-CPU computer. Each core in your multi-core CPU is in actual fact acting as a separate CPU as far as your program is concerned.
@A.S:
32vs64bit for dummies:
Note that they explained it correctly; ie, they didnāt say what you said.
When it comes to a wider space for communication, what you are then talking about is buses. These are the lanes that transmit information between components (be it internal to the CPU or between components). These can have differing widths, allowing multiple datastreams to occur simultaneously. 64-bit vs 32-bit has absolutely nothing to do with this. An easy example to give would be PCI-Express; you know how the ports and sockets say āx16ā and āx8ā etcetera - those are the amount of PCI-e lanes available for simultaneous use. (And the limited bus width of the PCI-E controller is the reason why SLI setups might force cards to go in x8 mode even though theyāre sitting in x16 sockets.)
Now, if you have three channels, youāll ask (simplifying now) for three adresses to be read simultaneously, and get the results simultaneously - faster memory access. But if you are on 32-bit, the total adressable space will be only those 2Ā³Ā²; that is, when that memory access/write request is āsentā, it is a number of potentially 2Ā³Ā² bits of length. And if the file you want to manipulate is bigger than that - say, a big uncompressed video for editing - then you are boned. Your computer wonāt be able to do it. (Here, btw, is also the reason why FRAPS will cut itās raw output files at 4GB; itās a 32-bit process, it cannot adress more than that, so it has to cut the file and start over on a new file.) Using 64-bit memory architecture solves this nicely, allowing you to use your 8, 16, 32 or 128 GB RAM setups. (And theoretical limits in the multiple exabyte range, or about a million times more than current computers.) Basically, what it does is allow you to efficiently handle large amounts of data. And with many games today reaching double-digit gigagbytes for download, expecting them to sit nicely in 4GB of RAM is an exercise in futility; especially when OS also has to sit there.
-
32 bit is a limit for Falcon because the EXE can only use ~1.7GB of memory. Donāt ask me why exactly and I know that 2^32 is ~4GB, but if anyone ever seen a CTD that came after the sky turned black, then itās because that ~1.7GB limit was pushed. usually ATM if there are no leaks, then 1.7GB should be enough, but looking to the future, 64-bit EXE is the way to go.
-
My number one wish is a day/night switch. Think about the possibilities: external lights (more visible at night), cockpit lighting, afterburner (brighter at night), JHMCS / NVGā¦
I totally agree.
My number two is add water environment mapping for Plains set type. This may solve this problem:https://www.benchmarksims.org/forum/showthread.php?14333-Ground-units-movement-over-water-type-tiles&p=200927&viewfull=1#post200927
https://www.benchmarksims.org/forum/showthread.php?15668-Tiles-water-black-floor
And no popcorn on AB tiles (set type water ). Some Airports are on coast.Edit:
I looked at Kunsan tiles and all is water set type, not explode on these tilesā¦
These three tiles is water type (water shader), and no problem:Can anybody explain why in other theaters it is impossible?
-
Iām on Fedora19 so itās 3.11+ mesa 9.2 (build 9.2-1.20130919). Sadly iām not flying for last few years as my lappy is not really up to the task ( Core2Duo 2.1 + Radeon 4330m). But I saw your posts. It seems thereās a hope for us Iām really looking for 1stQ of 2014 when Iāll get new rig. Most likely Iāll set for Samsung AtivBook 8 current model (i7 + Radeon 8870) or Haswell refresh if itāll get AMD gpu. I donāt really wanna mess with closed binaries.
Donāt get ATI over 6xxx!!! The performance is truly awful, at least for now.
The drivers are improving, but ironically, itās CAYMAN that has best perf, even 5xxx has better perf than [78]xxx.
-
32 bit is a limit for Falcon because the EXE can only use ~1.7GB of memory. Donāt ask me why exactly and I know that 2^32 is ~4GB, but if anyone ever seen a CTD that came after the sky turned black, then itās because that ~1.7GB limit was pushed. usually ATM if there are no leaks, then 1.7GB should be enough, but looking to the future, 64-bit EXE is the way to go.
Isnāt BMS 4.32u6 using large address aware flag? That means full 4 gigs.
-
One thing for the next update? Hmmmā¦. AI wingmen being able to perform a break and visual pattern for landingā¦
This is just a wish from an occasional player (usually single player). More advanced players certainly see other priorities.Enjoy your virtual and real flights.
-
Because 32-bit systems can only adress a given amount of RAM. To be precise: 2Ā³Ā² bits. (AKA ~4GB.)
To go back a bit, you said this:
āRegards your answer refering to 64bit suggestion. DonĀ“t you think it would benefit to address all cores.āHereās where I think youāre getting confused; 32bit vs 64bit isnāt about āadressingā cores. Itās about memory adresses. Like this: whenever the computer needs to access or write to memory, it accesses a given memory location. To find this location, it uses an adress. Pretty much the same way the postman uses your adress to find you, or a phone number is used to find your cell phone, or an IP adress is used to find your computer. The memory space is how many adresses are available. (Compare with the ongoing transition from IPv4 to IPv6 for internet; weāre actually running out of IPv4 adresses nowadays, so IPv6 is being phased in to give us a lot more of them.) In a 32-bit system, you have 2^32 adresses. In a 64-bit system, you have 2^64 adresses. You can see this in effect quite easily; take a 32-bit system (or install a 32-bit OS) and try to use it with 8GB of RAM. Youāll find that you donāt get to use your 8 gigs; it stops at 4.
āAdressingā cores towards using them for computation; that is, the processing of instructions, is done with threading. This is a different thing; you can multithread just as easily (or rather, with the same amount of difficulty) on 32-bit as you can on 64-bit. Indeed, multithreading has been done on 32-bit (and 16-bit) waaay back. There is no difference, from a programming perspective, between multithreading an application on a multi-core CPU and doing it on a multi-CPU computer. Each core in your multi-core CPU is in actual fact acting as a separate CPU as far as your program is concerned.
Note that they explained it correctly; ie, they didnāt say what you said.
When it comes to a wider space for communication, what you are then talking about is buses. These are the lanes that transmit information between components (be it internal to the CPU or between components). These can have differing widths, allowing multiple datastreams to occur simultaneously. 64-bit vs 32-bit has absolutely nothing to do with this. An easy example to give would be PCI-Express; you know how the ports and sockets say āx16ā and āx8ā etcetera - those are the amount of PCI-e lanes available for simultaneous use. (And the limited bus width of the PCI-E controller is the reason why SLI setups might force cards to go in x8 mode even though theyāre sitting in x16 sockets.)
Now, if you have three channels, youāll ask (simplifying now) for three adresses to be read simultaneously, and get the results simultaneously - faster memory access. But if you are on 32-bit, the total adressable space will be only those 2Ā³Ā²; that is, when that memory access/write request is āsentā, it is a number of potentially 2Ā³Ā² bits of length. And if the file you want to manipulate is bigger than that - say, a big uncompressed video for editing - then you are boned. Your computer wonāt be able to do it. (Here, btw, is also the reason why FRAPS will cut itās raw output files at 4GB; itās a 32-bit process, it cannot adress more than that, so it has to cut the file and start over on a new file.) Using 64-bit memory architecture solves this nicely, allowing you to use your 8, 16, 32 or 128 GB RAM setups. (And theoretical limits in the multiple exabyte range, or about a million times more than current computers.) Basically, what it does is allow you to efficiently handle large amounts of data. And with many games today reaching double-digit gigagbytes for download, expecting them to sit nicely in 4GB of RAM is an exercise in futility; especially when OS also has to sit there.
There is nothing wrong with what you posted. Technically your post is correct, BUT the difference is that there is the know-how in specifics as āengineerā or coder and the ability to utilize that know-how.
As flightsims were pretty much show-off oppertunities for PCs in the past in order to demonstrate what they can do, sims are still benchmarks today in terms of what can be done and how, from coder- and hardware perspective.
Not only because of the wider memory access under 64bit, but because of the ability to split each module (flight physcis, dnyamic weather, environment engine, Ground and Air taking manager, etc etc) under different threads OR/AND cores. The benefits are obvious and a 64bit environment is consequently a āhelperā achieving this, from stability to more data or details processed at the same time ā¦etc etc.
Thus a āMemory-Busā aswell, which is also a Bus in the core (namely double the width in the cpu architecture) will improve speed NOT the FPS necessarily. Big difference: One can calculate 10000 things with 60 FPS or 20000 things with 60 FPS.The issue is, that this has not been utilized well in ANY sim for the home-pc market to my knowledge, exception is Rise Of Flight who followed the right direction regards programing architecture and seperated modules (at least threads-wise). Programing in seperatly calculated modules is āunavoidableā as one can not queeze everything through the same ātunnelā especially with flight-sims with mutiple and independent calculation-areas and constanlty growing data to be processed. We all know the term ābottleneck avoidanceā and 64bit does his job right there.
Fighterops was another approach (Modules diverted to different threads/cores parallel and simultaniously), but they failed as we know.
But even if all that would be not important, just the wider memory access is reason enough to go for 64bit, especially for flight-sims.
āā¦ donĀ“t embrace excuses, but solutions ā¦ā
cheers
-
@A.S:
Thus a āMemory-Busā aswell, which is also a Bus in the core (namely double the width in the cpu architecture) will improve speed NOT the FPS necessarily. Big difference: One can calculate 10000 things with 60 FPS or 20000 things with 60 FPS.
Unless you are positing a scenario where memory amount is a serious bottleneck, no. Well, sure, you can throttle execution, but thatās different.
I think you might be confusing 64-bit processors with newer processors that, through being new, have innovations in other areas as well. Stronger internal buses in the CPU have nothing with the 32-64-bit thing to do. What has happened, however, is that desktop computers has made the transition at a time when innovation in memory buses (and ALU, register design etcetera) all were necessary. Mainframes transitioned to 64-bit in the 70ās, workstations in the early 90ās. And note how they did so with no real link to multicore execution and while being hopelessly outclassed by the hardware we have available on the desktop when they commenced the transition back in 2003-2004ish. (Indeed, the first two 64-bit desktop CPUās I ran were both single-core, running 32-bit XP and 64-bit Linux in dualboot.)
64-bit memory adressing gives access to bigger datasets, allowing you to do more. Your description of it is just wrong - or explained in such a way that it is indistinguishable from wrong. If you are so certain, you could perhaps offer a direct example of what you mean - at the nitty gritty. Iām quite at home in computer components and CPU architectures, so donāt worry, Iāll understand it as long as the terminology is somewhere around right.
However, what RoF did was multithreading. But want to know a little secret? Rise of Flight is 32-bit.
Like DCS previously, it has two compiled paths in the installer, and if the OS is 64-bit it installs 64-bit, if OS is 32-bit it installs 32-bit. But hereās the important thing: even when running 32-bit path, it still has all the same multithreading things that you mention. These are completely separate things and Rise of Flight is actually an example of that fact! They were able to implement multithreading in a good way since their engine saw itās design stage when multicore processors (32 or 64-bitā¦ who cares? When it started, it was actually majority 32-bit OSes on pseudo-64-bit hardware.) Which is not the same thing as being 64-bit and is completely irrelevant to it.
What has happened, and which I continue to feel is what is causing you confusion, is that the transition in mainstream consumer equipment has happened to occur roughly simultaneously for both 64-bit and multicore processor architectures. (Though that depends on how you count, considering how for the first 5-7 years of 64-bit desktop processors they were none-the-less sold with 32-bit OSes, since with just 256MB of RAM and similar itās not like they need the memory space anyhow - but since the same architectures were also used in server silicon, that synergy of design effort meant that they did get theoretical support for 64-bit operation as long as they got a 64-bit OS. I personally ran 64-bit Linux back then, since - as most remember - 64-bit XP had atrociously bad driver support.)
@A.S:
But even if all that would be not important, just the wider memory access is reason enough to go for 64bit, especially for flight-sims.
THERE you are getting it.
Being able to manipulate greater amounts of data is huge for combat sims. Civvie sims like MSFX etcetera - meh, not really, cool for ultra-hot terrain packs I guess. But combat sims that, for example, want detailed ground environments that are at the same time large do need to be able to hold a lot of data. (The bubble solution of Falcon 4 only goes so far, since there might still arrive issues in some MP scenarios.)
-
64-bit memory adressing gives access to bigger datasets, allowing you to do more XXXXX
Add āsimultaniouslyā to it and then YOU GET IT
You can also read here for educational purpose: http://blog.tune-up.com/windows-insights/32-bit-vs-64-bit-more-bit-more-performance/
The internet is full of āComparing 64bit and 32bit CPU benchmark resultsā clearly showing performance advantages with 64bit, but it always depends what you are measuring too of course.Here are some example from the CPU tests. (higher numbers are better) TEST: CPU - Integer Math PT6 64bit, Win2003 64bit, Result = 193.3 PT6 32bit, Win2003 64bit, Result = 92.9 PT6 32bit, WinXP 32bit, Result = 92.9 TEST: CPU - Find Prime Numbers PT6 64bit, Win2003 64bit, Result = 217.7 PT6 32bit, Win2003 64bit, Result = 158.2 PT6 32bit, WinXP 32bit, Result = 157.9 TEST: CPU - Data compression PT6 64bit, Win2003 64bit, Result = 2584.6 PT6 32bit, Win2003 64bit, Result = 2578.6 PT6 32bit, WinXP 32bit, Result = 2582.77
What we need to understand is HOW CAN WE BENEFIT FROM 64BIT IN SIMULATIONS AND WHY (NOT ONLY MEMORY WISE) !
I donĀ“t think i can contribute anything more (even if nitty gritty) to someone who already has its own concreted position to the matter and to be honest i canĀ“t even bother explaining again noticing where this might go (waste of time).
Therefore, all to say i guess is: Cool, take your expertise into the DCS and let the 32bit results speak there. -
AS,
If you donāt post source code to benchmark, compiler, its version, stddev, used compiler/linker flags, itās worth less than nothing.
My SSE3 float code with GNU CC and sane flags has about the same perf on 32-bit and 64.
-
AS,
If you donāt post source code to benchmark, compiler, its version, stddev, used compiler/linker flags, itās worth less than nothing.
I am not hunting specific cases or āexceptionsā to proof counter-argumentative situations.
How 64bit can be utilized for flight-sims generally i pointed out in post 86. -
Actually, 64-bit pointers are slower than 32-bit to pass around Not to mention real RAM usage with tons of them.
-
Isnāt BMS 4.32u6 using large address aware flag? That means full 4 gigs.
Not sure what is ālarge address aware flagā exactly, but if the limit is not 4GB, I assume that you are right.
Actually, 64-bit pointers are slower than 32-bit to pass around Not to mention real RAM usage with tons of them.
Maybe, but tests showed that 64 bit EXE isnāt slower than 32.
-
Thereās āeditbin /LARGEADDRESSAWARE some.exeā that users have been using already for some time, with large sceneries and somesuch.
Please see:
- Set LargeAddressAware flag on 32 bit executables.
-
So I donāt knowā¦ I guess thatās the case in development EXE which we are using, but still the EXE is limited to only ~1.7GB of RAM, beyond that itās simply crashing.
-
well the 64bit exe which I-Hawk said itās faster the case till now was that it was slower and that was why there was no 64bit exeā¦ hmm maybe something changed in the mean timeā¦
Besides that I believe more needed (and more painfull for the coders) would be to better use of cpu coresā¦ like the known demanding aggregate deaggregate functions that bring CPUās on their knees and have a huge FPS impact not to mention that itās limiting unitās - objectives - features numbersā¦ If those functions could be transferred - calculated by other cores, and balance the CPU load, then the whole experience would be smoother, and would open a whole new chapter for BMS details and realism. Also would keep the HW budget to a good point.
I know that is said that the code itās multicore but is it optimized on the above? Or would such optimization give better results?
-
Being realistic and accepting that what we have now with terrain ( new Balkans and several other WIP) and graphics is pretty darn good, and not going to get much better, I would really like it if the AI were better and ground troops etc more controllable. It seems bizarre that after 10 years, these basic things are still causing issues. Better and more volumetric ( I mean thicker , fluffier cloud layers) clouds would also be a great addition to the realism. And realistic JDAM function would be great as wellā¦
Finally, better terrain elevation, to remove the spiky mountains and flat hill sides.
Apart from those, BMS is pretty much perfectā¦
-
After all, BMS runs at around 100FPS on taxi and 250FPS in the air on a moderate i72600K and 570GTX system with 4GB+, if the settings are not āgreedyā pushed out to the max (HDR Bloom, Cockpit Shadows etc.).
This is quiete an accomplishment i would say, isnĀ“t it? ā¦ considering everything going on in a campaign.
Even IL-2 HSFX7 (graphics extensive) runs on the same system with 250-600FPS (OpenGL), which is even better, but this sim doesnĀ“t have so many things being calculated as BMS does i guess.
Rise of Flight runs excellent on compareable systems (so i am told), FSX, Cliffs over Dover and even Warthunder with cinematic graphics run flawless (so i know), only latest DCS products (so i am told) have a big issues to even get close to those FPS ranges on moderate systems, suffering at the lower ends where it is still āplayableā.
-
I would really like it if the AI were better and ground troops etc more controllable. It seems bizarre that after 10 years, these basic things are still causing issues. ā¦ā¦
Wellā¦as i worked a lot on AI WVR recently, i can garantee you that this area is far from beeing basic.
Just to give you an example in WVR :
- first you need to teach AI how to keep Corner speed , for that you need to manage Thrust AND Stick position
- Throttle code for AI was 100% wrong since original F4, rewriting it was necessary, this had collateral damages everywhere in code (climbing profiles/ timing for navigation / fuel consumption / refuel positionning / interception courses etc)
- No code was existing for determining what stick position was necessary to maintain a certain speed assuming throttle was set correclty
- after stick code was re written, discovery was made that the stick position passed to the AI FM code was badly handled ā¦so it had to be fixed as well , this had collateral damages everywhere stick position was sent to AI FM ā¦
and that is JUST ONE exampleā¦just to be able to maintain a speedā¦now imagine everything that needs to be done for having a complete AI operationnal
so yeah , AI is pretty much busted in every domain, has always been ā¦some areas will be improved
Ground troops management -> see you in 3 -4 weeks
-
I think thatās the real issue here. Everyone has his or her wishlist, but very few people actually understand how complex it is to change things in Falcon given the age of the original code, the compromises that had to be made back then, and all the changes that have been made since.
Iām just grateful for what weāve got to be honest. Anything coming out in 3 to 4 weeks is a bonus :bowd: