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...