ruhtraeel

Hello, I was wondering if there was any progress made towards being able to cancel actions such as reloading a rocket launcher, or switching weapons while moving. I recall a developer saying that it was difficult due to their animation engine, but I was wondering if there was any official progress on it, since there has been a mod allowing you to do it since 2013. Thanks

Thank you for the clarification. Although asking for actual proof of graduation, etc is completely unnecessary, it is much easier and much less unsettling to know (or hope) that the person should know how having software development experience does not necessarily mean that it is applicable to optimization scenarios. Background and e-peens aside, the reason for my posts are to hopefully educate people that otherwise wouldn't have known the reasons behind the game's performance. This can have multiple benefits: 1. Less posts saying "OMG THIS GAME IS CPU BOUND, SUPER INEFFICIENT etc etc" 2. Community involvement. By sharing and laying down knowledge, people with backgrounds from other areas can begin to at least attempt to fix/discover workarounds to (and sometimes succeed, such as overclocking RAM) performance issues. I believe it's at least more productive to an individual's knowledge, not even necessarily fixing the game, as opposed to sitting there and waiting for an engine rewrite.

I'll start off by saying that I didn't state any explicit assumptions; only deriving from my own background. Also, without going into too much detail, Software Development and Computer Science are two very different fields. Software Development is mainly taken from a high-level perspective, with high level languages. Computer Scientists aren't "codemonkeys"; their purpose is not coding; rather, they understand the mechanics behind the code, the computer, and the logic and math behind it. The biggest factor is that instead of writing code given the tools and environment to do so, many of the connections between the hardware and the software must be explicitly stated. This is where I believe that my knowledge will help. No, I don't ever extensively learn how to write "nice" or "organized" code. I learn about why things work the way they do, hence the science part, rather than the direct application, such as software engineering. In terms of solid proof, there are numerous documented cases (a couple pages back) of people overclocking their RAM and getting major benefits. While we obviously can't change the operation of Windows or the hardware, we can at least conclude that the allocation of memory is inefficient in this game. The major disconnect comes from the high vs low level debate. In Visual Studio, if you write a program in C#, for example, you will encounter hardware bottlenecks much more rarely, especially because higher level software development has an API and framework built for it. This means that memory management and such is automated. However, without reaching the level of assembly, C and C++ both require manual memory management and such, which provides a much closer look to why things take longer/are slower. By looking past the "trial and error" way of optimizing framerates, we can sometimes find certain high-level methods of increasing performance. For example, if people only stuck with changing view distance, graphical settings, and overclocking processors, it would take much longer to realize things like RAM being a major factor in the overall performance. Overall, I disagree that looking at the memory allocation of the game is useless, because there are many things to be learned.

You're wrong. The visibility setting affects the amount of calls to memory, which in turn affects FPS. Notice that while the framerate improves when you turn down visibility, CPU/GPU usage is still minimal at times. I am a game developer, and a computer science major. It's in my degree's nature to look into these things, and try to find the exact problem given the information that we know, and the background knowledge that I have.

There will always be a relationship between memory mapped and the CPU. Context switching is when a process is switched out for another one; this takes an unavoidable amount of time. This happens when the task at hand is waiting for the synchronization of timings/threads (pretty much the basis of Amdahl's law), or when the task is waiting for I/O (THIS INCLUDES MEMORY!!). What this tells me is that it's not a stupidly large amount of data being referenced from memory at each call (this would cause lock ups and stuttering), but rather a LOT of references being called in total. This makes sense because while the memory operation itself might not take that long, the context switching back to the task when the memory reference has completed ends up taking even more time. So, it's not that the multi-threading is inefficient, per-say, but rather that the memory references causes threading to BECOME inefficient. All in all, the problem is that things are referenced in memory way too often; instantiated game objects have their pointers, and are constantly referenced to. This explains why people gain so much from faster RAM.

If you really want to know how to optimize software, take a look at my post's link at the bottom of page 332, as well as my post on page 335. In those pages, I explain how memory is mapped from virtual to physical using page tables, and why it slows down performance.

...This statement doesn't make logical sense. I said that those pages can be referred to for why ARMA's performance is as it is. You're essentially saying that I will fail hard at something that has already been done. Besides, I'm confident that my background will at least help in these related topics. I would like to know your opinion as to why I will "fail hard" at something, however. I did see that guide, and I've actually followed it to help boost my framerates. However, I think that the guide is missing information on why the framerate is as it is. The guide is end-result heavy in that it says "because we've tried it a lot, this change seems to affect this performance". It never really explains why something happens, just when it happens. Reasons behind certain correlations include numerous pointers to memory, the CPU cycle waiting for memory references to finish, and page tables being scattered across random locations in RAM. If we can show users the direct reasons and causations of framerates, rather than just what settings to change, we can hope that people will take this research even further and discover things that haven't already been found.

I know that for me and numerous other people, it's because of a RAM bottleneck. Both the CPU and GPU utilization drop when I look at scenes with a lot of objects such as towns. Read "Low CPU utilization & Low FPS" pages 332-336 for the basic rundown of why the FPS drops happen, in terms of hardware.

I honestly feel like this thread can be closed after page 332-336. That's all the evidence you need for why Arma's performance is as it is, and possibly what you can do to improve it. Everything after that is just people complaining. Perhaps I will make a thread regarding performance, the reasons behind it and what you can do to improve it and then request it to be stickied or something.

The "every system is different" explanation isn't satisfactory anymore for a lot of people, which is why we even bother to dig deep and find out exactly why this happens. Why did your system get 5 3dmark points higher than your previous run? There's a reason for that. There's a reason for everything. When you say that it's "confusing and ridiculous" as to why you get that performance, we are finding out why, and not just saying "every system is different" then leaving it at that. For the vast majority of users here, ARMA's inefficient use of memory is the culprit behind their low framerates. And yes, all this discussion is to dig down and find out what the exact cause of lower framerates etc, are. The point here isn't "listen to me because I have xx years of experience", or "listen to me because I can overclock my processor to x ghz". That doesn't change the reason or outcome behind all this. On a side note, I would REALLY like to ask Dean Hall more questions regarding the new DayZ engine and how it supposedly uses RAM better. I'd like to know exactly what they're doing to improve their engine, and whether or not it can be applied to ARMA 3. He mentioned in his response that the memory fixes would allow the Infusion engine to spawn triple the amount of objects in the world/zombies, etc. This directly reinforces my experiences; when I look at an empty field, I get great FPS. When I look at a town with many more objects, my CPU and GPU utilization both drop a lot. Try overclocking your RAM, and telling ARMA to use larger page files for less page swapping using Fred41's malloc fix.

The game engine obviously needs optimization, but we're almost completely sure as to what needs to be optimized. The suggestions given are based on this knowledge, and it seems to help many users. Sure, it won't cover up for the engine's shortcomings entirely, but it's the best we can do at this point aside from just being angry and calling things "bad".

OC your RAM for the biggest difference. EDIT: Just read Dean Hall's DayZ"infusion" engine interview. Something that may be of interest, and may confirm exactly what we speculated: http://www.reddit.com/r/Games/comments/27uf74/rgames_rdayz_ama_with_rocket_dayz_is_moving_to_a/

What we've concluded to, unless proven horribly wrong, is that ARMA is memory bottlenecked. Overclocking your CPU/GPU won't help much (at least it doesn't for me), regardless of what core it runs on. Overclocking a core would just mean that the program sends requests to malloc/reference memory faster. It won't change how fast these requests are completed. Because there's so much stuff loaded in the game, pointers to memory are used frequently; this causes your CPU/GPU utilization to drop when looking at a town with a lot of objects, for example. This is also why Fred's malloc fix helps, and someone discovered that overclocking your RAM helps as well (don't forget the thread name). I'm not sure if the OP reads this thread anymore, but he should post clearly that the biggest reason behind slowdowns is that this game is not well optimized for memory. This should avoid any further confusion/speculation. So, OC your RAM, etc.

Thanks. If this works for me (aside from other things, such as the movement mod that allows jumping and stuff), I know what my next 3 days will be spent on. I've also thought of an improved interaction system; if the ARMA engine provides a function that spits out the coordinates/direction of your crosshair, perhaps this could be used in accordance with player position to make a standard "e to interact" system.

TBH, when someone mentioned a "malloc" fix, I was instantly intrigued; if it was what I was expecting, then it could truly lead to good FPS gains. Good job Fred41; people like you help keep games going. I am going to look into this "large page malloc" more once I get off work. Also, I forgot to clarify one more thing: Amdahl's law is the absolute limit for performance gain. This would happen only if every single process/thread gets to a point of execution where a mutex (mutual exclusion) is needed to prevent race conditions, or else weird stuff like Heisenbugs start appearing. I wouldn't say that we've hit the absolute limit of Amdahl's law yet, where every single thread has been optimized to the point where it can't be changed without messing up functionality; just individual conditions where a mutex is needed. Cache hit/miss is pretty hard to calculate, yes. It's one thing to sit in an Operating Systems course final and then do a replacement algorithm for a string of 8 numbers, but it's another thing to do it for an entire system...

I wouldn't expect the -cpuCount parameter to affect much; at most, I'd imagine that there would just be more cores waiting for memory accesses, unless your CPU is REALLY old. [quote name=Polymath820;2705543 And memory addresing what do you mean by that? The de-allocation / re-allocation of memory? Or hardware related issues as well? Such as the type of memory addressing a CPU within the cache uses e.g full-associative' date=' set-associative or direct mappped? Or the primary motherboard mounted DIMM chips which run exceptionally slow and have an accessing only 1% of the time for all the L1,L2 and L3 caches? That as far as I know from a book that I am reading that is what happens "Upgrading and Repairing PC's 21st edition by Scott Mueller" Deallocation and reallocation, yes. Here's the top answer in the link I posted about how to optimize your game: Imagine this: You have some refresh of an element every miniscule amount of time. Within this refresh, there are possibly multiple loops (for, while, etc). Within each of the loops, you refer to a pointer for an object you created, which is stored somewhere in virtual memory (which gets translated into physical memory), not necessary related to the location of other things that are accessed near it. This gets expensive FAST. This is what I was talking about regarding big O analysis: if you have like 5 nested loops in a piece of logic (O=n^5), each of which access something in memory, and the entire piece of logic is part of a function that refreshes at very high rate, these accesses are going to start to bottleneck everything else in the system. EDIT: Sorry if I forgot to clarify some stuff. When you malloc something (whether it would be an object that you need, or a buffer for input, etc), it gets translated to a virtual address. This address is NOT the address in your physical memory (RAM). The virtual address needs to be translated into a physical address. This uses page tables; the page table's address goes through a translation procedure (just an algorithm that looks at each byte block of an address and where it corresponds to in physical memory). If the translation of the address of an entry inside a page table points to somewhere not in physical memory (RAM), it raises a page fault, and then the OS has to go looking on the hard drive for it.

Being able to work in an area such as video game design would be am incredible opportunity, as it was one of my primary reasons for choosing Computer Science as my degree. Location becomes the biggest issue, however, as I am currently delegated to primarily oil and gas applications for programming in my city. The closest significant video game studios to me are Bioware, Edmonton and Relic Entertainment, Vancouver. I do think that there are an abundance of talented programmers in Europe, though. Anyone ever notice that almost every 3rd party mod of a game has the majority of characters with thick European accents? Either there is some intrinsic value of European languages that perfectly suits video game characters, or they have some amazingly talented programmers over there, judging from some of the mods that I have played. Or both.

I agree. I remember this issue in my Operating Systems course, and if I remember correctly, since memory can't be split up/resized and shuffled around once allocated (at least in Linux, IIRC), I think the ARMA engine itself needs to rethink when and how often it accesses memory because of this problem. Ex. not constantly updating stuff that the user can't see. Having the source code would be super nice lol; I actually want to try and change some things in it now.

Your issue with the GPU engine might also be explained by the constant memory addressing. This would cause the other hardware such as your GPU to sit idly, possibly explaining your results. I don't understand your point here. Are you saying that every game wastes GPU compute power? I don't know why you are comparing Metro Last Light saying that someone else's GTX 780 "only" uses 0-3 while your's uses #0 in ARMA 3. I also don't really know how Mantle fits into this, could you elaborate please? That's a very comprehensive manual, I'm going to bookmark that for reference when making some intensive low-level programs. It would be interesting if a game was profiled to see the degree of change between each of these optimization tweaks, without getting into the hard calculations of theoretical performance. I do agree that it's difficult to exactly pinpoint the issues, but from my experiences with programs in the past (including seeing my friend write a game engine from scratch, even though I wasn't in the course), as well as the evidence from people's results, my best guess would be that everything is constantly loaded into buffers from memory rather than from arrays/vectors. This would cause a lot of CPU/GPU overhead. Obviously it would be illegal to do a hexdump of the program while it's running, but all we can do is speculate. Unless a BI developer comments on whether or not we're on the right track of understanding the engine? ;-) It would be nice to have BI community representative for the general game itself as well as a developer representative for some of the technical aspects of it.

Can you pose an alternative reason behind this? The way I see it is, unless Windows' context switching algorithm sucks or something (which obviously isn't the case), the CPU/GPU are both constantly waiting for something to finish. Because the usage is so low, my best guess would be that they're constantly waiting for memory operations to finish, such as mallocing for buffers and such. Each one of these requires the translation from virtual (or logical) to physical addresses of RAM, which ends up taking a long time. My evidence behind this is that the more there is on the screen, the less the CPU/GPU are being used. This might possibly be everything being loaded from memory? This is also consistent with someone else's finding (I don't remember the exact thread name), where they discovered that overclocking your RAM had some performance boost. I know that for me, I get solid framerates looking at nothing but grass and trees, but the moment I look at a town, my CPU/GPU usage drops, as does my framerate. (Blame Intel's memory based architecture for this; having a crapton of registers like SPARC would make computers a lot more efficient but (possibly?) a lot less affordable. SPARC assembly was 10x less a pain in the ass to program. Want optimization? Get rid of more NOPs!) See Amdahl's law, and what I said above about the degree of which you can do this. Again, like I stated above, see above for which tasks get delegated to what thread/core. I'm not sure what you're trying to say here. Obviously, when you try to make an engine, you try to make it well, and not poorly. If you're saying that the game engine doesn't need to be rewritten because of this, you're proving by example, which isn't correct. If you're just saying that's something to keep in mind, then it's obvious that when you try to make an engine, you try to make it well, and not poorly. I do understand that writing a game engine is time consuming, and takes up a lot of a company's resources (Using Unity in my game design course was a lifesaver, whereas some other groups had to struggle with Gameboy Classic/Atari 2600 assembly and such to get to less than half of what we did), but there's a point where you might realize that this might be the thing holding you back. Also, if anyone is interested, these are some good general principles as well as tips and tricks to squeeze out performance from your game: http://gamedev.stackexchange.com/questions/853/c-low-level-optimization-tips

So first off, complaining to a forum moderator won't do anything. They just regulate the forums; it doesn't mean they know anything about how the game is written itself, or that they have any special power over BI's business decisions to continue releasing content rather than creating a new engine. Trying to dig at moderators for answers or venting at them isn't going to work well; it'll just leave both parties frustrated. That being said... I don't think this engine can last another full game without a significant overhaul. ARMA 2 was the first foray into modern gaming, and ARMA 3 refined it, but it seems like there isn't much else that can be fixed. At this point, I don't think adding more content will be able to hold the playerbase for another game. ARMA 3 already has so much gameplay content; giant maps, numerous weapons and many drivable vehicles. I think it's reached a point of diminishing returns here, where adding more content won't do as much as rewriting the game engine. I know for me personally, the frustrations/suggestions with the game that come to my mind are purely technical. Furthermore, in making the new engine: -Please run big O analysis. Don't have cubed loops, etc. -Please don't constantly access memory; page faults are expensive. Don't have redundant code and billions of pointers (is this one of the culprits?); take advantage of the cache, especially when a game's scale is as large as ARMA's. -Don't constantly refresh/calculate things that aren't necessary. Activate listeners only when necessary. -I don't expect the engine to reach Amdahl's law or anything, but delegating less important functionality to different threads and having another core help would be nice. BRB, writing super unoptimized code for an oil and gas company LOL

This * 1000. Yes, making an entire engine from scratch is a lot of work, but since they aren't forced to release a game every year like CoD, they have the time to do so. There are even things that can be fixed with less effort, and have even been done by the community: 1. Switch weapons while walking 2. Interrupt actions (I wouldn't still be reloading if I was being shot at) 3. Breathing is way too loud

Make actions interruptable. Even Dyslecxi complains that he wouldn't continue reloading while being shot at in his videos.

For me, the ONLY thing that affects my FPS is view distance. The pattern was that if I was looking into the distance without many objects on screen, I would get 95% GPU usage and around 45-55 FPS with everything maxed out. However, when I look into a town on Altis, my GPU usage steadily drops to around 50%, and my FPS tanks to around 28-30 FPS. I originally thought that this was because of my CPU bottlenecking, but after checking its usage, it is steadily at 60%-70%. This is frustrating because I know my GPU is more than capable of handling the game (seeing as how I can get like 45 FPS when it's at 95% usage), but it isn't even my CPU that's making things worse, as it's not even being used that much either. I have a feeling if the CPU usage can catch up, then the GPU usage will catch up as well, giving higher frames. As of now, the first mission in the new campaign is almost unplayable and certainly unenjoyable, as sometimes it feels like a slideshow with the low FPS combined with the occasional stutter when the game has to load objects.

I really hope something is done with the performance soon. IMO it and accessibility (make moving cancel actions please!) are the two biggest issues right now facing ARMA 3, and should be focused on the most. I was playing through one of the showcases (the one with the large scale warfare). Upon reaching the town, I got around 15-20 FPS. I went over to check my GPU usage, and it was hovering at around 40%. When my GPU usage is above 90%, I usually get 50-60+ FPS.