How to Unlock Multithreading for Rust? - Rust

I have a too low fps on Rust but i know that Rust do not use all my CPU, how to enable multithreading for Rust? Sorry for the bad english!

That kind of thing is something that has to be built into the game, and it's not really so simple to take a big game like Rust and split it across different threads -- especially when the foundations of the game are still being worked on. Everyone is having performance issues with Rust right now, it's a consequence of being in alpha.

[QUOTE=elixwhitetail;48020918]That kind of thing is something that has to be built into the game, and it's not really so simple to take a big game like Rust and split it across different threads[/QUOTE] X2, very few games actually use more than one CPU. Most games are actually single threaded and you cannot simply flip software from single to multithread with a command line switch, the whole software needs to be designed/decoupled in a way to take advantage of these multiple processors. Most games being very intensive on memory and video buses, there is very little gain to be had converting them to multithread to begin with. Just to clarify, most games do have multithread, but the core of the work is done in a single thread and cannot be separated. They might have a worker thread here and there for other task, but most of the time it's just a big loop drawing scenes and checking for user/network input between each draw. The whole multi-cpu trend we've been seeing for the past 15 years or so is a gimmick. You pretty much ever, ever use all of your CPUs in reality because processing power is rarely the bottleneck. It's mostly marketing value, "hey I have 6 CPUs and you have 4 you suck" kinda thing, but in reality, take just about any software out there be it games, video players, CAD, image processing, etc. Most of them don't even use more than one CPU. Multimedia is choked by memory/video speed, not CPU.

Deicide[RS] - Yes and no. If your system entirely started into a game, without anything else, I'd agree with you... However, you're disregarding the fact that you're also running an OS in the background, along with any other startup and active applications. All of these (potentially) use their own thread, and most of those applications are multi threaded (86% of the time, the UI is on a different thread to the processing core) - so the more threads you have, the better. Just because a game takes up (potentially) one thread, does not mean the rest are sitting idle by. Have you ever wondered why your entire game doesn't freeze while a hit calculation takes place?

[QUOTE=SemiDemented;48022851]Deicide[RS] - Yes and no. If your system entirely started into a game, without anything else, I'd agree with you... However, you're disregarding the fact that you're also running an OS in the background, along with any other startup and active applications. All of these (potentially) use their own thread, and most of those applications are multi threaded (86% of the time, the UI is on a different thread to the processing core) - so the more threads you have, the better. Just because a game takes up (potentially) one thread, does not mean the rest are sitting idle by. Have you ever wondered why your entire game doesn't freeze while a hit calculation takes place?[/QUOTE] The game is still single threaded even if the os and other stuff is using different threads and CPUs. Hit calculation isnt done in a thread you can quote me on that one.. The fact we are getting massive lag in gun fights proves this, the muzzle flash animation is slow as hell for some reason and freezes the whole game thread. I'm a software engineer with 20 years experience in multithreaded realtime applications, just saying, not pulling this stuff out of my ass.

[QUOTE=SemiDemented;48022851]Have you ever wondered why your entire game doesn't freeze while a hit calculation takes place?[/QUOTE] No, because calculating a hit takes minuscule amount of processing power to do. As Deicide said, hitscanning is done on same thread. It would actually be much worse(from implementation perspective) to do such a vital thing on a separate thread. Something like UI could be delegated in theory but who knows what sort of codebase and skill level the developers have. Not to mention Unity itself isn't very thread safe.

20 years experience? Okay - No one asked for qualifications, and I too am a software engineer. The following statement is the one that prompted my remark: "The whole multi-cpu trend we've been seeing for the past 15 years or so is a gimmick." Where as no, it is not a gimmick, because we still need more cores to do more things. Please refer to what I said here: "Just because a game takes up (potentially) one thread, does not mean the rest are sitting idle by." Please don't quote me out of context. And if you really do have 20 years of experience under your belt, you wouldn't disagree. --- And as for the minuscule amount, yes I agree. But compound that with every other calculation (Both from your character and others in every frame, in the local vicinity), as well as calculations with building, mining,day/night cycles, character animation, etc, what does all that amount to?

[QUOTE='Deicide[RS];48024841']The game is still single threaded even if the os and other stuff is using different threads and CPUs. Hit calculation isnt done in a thread you can quote me on that one.. The fact we are getting massive lag in gun fights proves this, the muzzle flash animation is slow as hell for some reason and freezes the whole game thread. I'm a software engineer with 20 years experience in multithreaded realtime applications, just saying, not pulling this stuff out of my ass.[/QUOTE] I agree with you - applications can be single threaded or multi-threaded, although whether hit calculation is done on an entirely separate thread is probably irrelevant given the minute computing power required. Assuming you're referring to the potential use of mutexes to lock/unlock core-code sections, which inevitably slow things down, you can if you're cool enough create an entirely lockless setup. But honestly, to refer back to your original post above your last one, I believe some applications do support more than the usual 4 cores, Battlefield being one of them. I guess it's down to the application. I've never really looked into Rust too much, I just wish it would support my crossfire setup. One can wish..

Alright Semi, I think we're just not understanding each other. Let me explain the gimmick claim. Back 15 years ago I don't know if you remember but it was at the apex of the AMD-Intel race for arms, processor speeds were pretty much doubling every year, the amount of R&D and progress in the CPU world in the 5 years before multi-core CPU's came out was probably the greatest in history. Then multicore CPU's came out and the public lost interest in faster CPU's, they started collecting cores and being content with increasing the number of cores. They somehow came to the conclusion 2x2500 was better than 1x3500, whereas in reality most application back then (and this is still true) were single threaded and thus only using one of these two CPU's. They also completely ignored the fact that CPU speed never was a real issue even back then, the bottleneck was the memory bus. Having a CPU that can calculate 15x more data is useless if you cannot get that data in faster. So that's what I'm calling a gimmick... They dropped the arms race... they still make them a bit faster but its nothing like it used to be... and well.. I'll take a 2 core with higher freq over a 40 core with lower freq for gaming anytime.

Yeah - I think it was a misunderstanding on both our parts :) Thanks for explaining, you have a very valid point there.

[QUOTE='Deicide[RS];48025798']I'll take a 2 core with higher freq over a 40 core with lower freq for gaming anytime.[/QUOTE] For gaming, maybe. But these days most home computers are multi function and a lot of software that isn't gaming is multi threaded. More cores have their uses, just not so much in gaming. Stuff like compiling code, rendering videos or 3d images, producing music, art... with the rise of freelancers multiple cores are more needed than ever. On the topic of Rust, since it's made in Unity you could just check the IL and see if it threads and for what.

[QUOTE=itisjuly;48026244]For gaming, maybe. But these days most home computers are multi function and a lot of software that isn't gaming is multi threaded. More cores have their uses, just not so much in gaming. Stuff like compiling code, rendering videos or 3d images, producing music, art... with the rise of freelancers multiple cores are more needed than ever. [/QUOTE] This is a lot less true than people make it to be. We do have lots of "tasks" running in our OS, but most of them are just idle waiting for events or other triggers. Look at your process list in the task manager you'll see pretty much all of those 50-100 tasks are siting at 0% CPU use. Even when it's not the case, they are all sharing the same HDD bus, the same memory bus, the same video card bus and GPU, etc. You cannot for example run two games at the same time on different screens and expect the same performance you'd expect if they ran each on their own separate computer with the same speed... Because the CPU is rare ever the bottleneck.. This is even more true with most of what you described (compiling, rendering video/images, music, art, etc) because all of these are either memory or hard drive intensive tasks. Doesn't matter if you have 2-3 or 100 cores if they're all waiting for your HDD or your 24 gb ram to deliver data to process. It's all a mirage I tell you. If they had kept increasing CPU speeds at the rate they were sustaining, we'd have 50K Ghz cpu's now and they'd eat a 8 core 4700 for breakfast.

Silly to suggest most modern day applications (of suitable size) are not multi-threaded to a certain degree.

[QUOTE='Deicide[RS];48026517'] It's all a mirage I tell you. If they had kept increasing CPU speeds at the rate they were sustaining, we'd have 50K Ghz cpu's now and they'd eat a 8 core 4700 for breakfast.[/QUOTE] What sort of shitty memory do you use that becomes the bottleneck in rendering or compiling? The reason we don't have 50k GHz cpus is because cooling them would be a nightmare. Cooling cpu with 4 cores at 3ghz is much much easier than 1 core cpu at 8ghz. That's one of the reasons we add more cores instead of more hertz.

[QUOTE=itisjuly;48026675]What sort of shitty memory do you use that becomes the bottleneck in rendering or compiling? The reason we don't have 50k GHz cpus is because cooling them would be a nightmare. Cooling cpu with 4 cores at 3ghz is much much easier than 1 core cpu at 8ghz. That's one of the reasons we add more cores instead of more hertz.[/QUOTE] Dude, I'm no electronics geek but I can tell you transferring stuff from your memory to your CPU is MUCH slower than the speed at which the same data travels within the CPU itself. If each processor had it's own memory and they didn't need to share it it wouldn't be a problem but the reality is that your 24 gb or ram (or whatever amount) is shared by your different cores and if they all want a 3 gb piece of it, the system is not giving 3gb to all 4 cores simultaneously, it's essentially queuing 12 gb of data and giving it piece by piece... So you have 3 cores sleeping on the job while the data comes in. Have you ever seen all your 4 cores at 100%? The only way you can effectively do this is by doing useless work, give or take a few very specific cases. You could start 4 threads that loop endlessly, this would probably lock 'em at 100%... but they aren't using data.. they are useless... So anyways, enough about this, the bottom line is most games are not going to take advantage of multiple CPU's and to do so would require tremendous amount of work and would increase the chances of having bugs by a factor that is bigger than the performance gained. TLDR; for gaming you want the fastest clock possible, number of cores is totally irrelevant so long as it's 1 or more :)

Actually i play rust but my computer still real fast while the game is open, the cpu usage of Rust is about 15% or 20%, and with everything else open the max ram/cpu/gpu usage is too low, i really wanted to run this game without anoying lag and screen freezes, but it looks impossible in the alpha version, thanks everyone! Anyone could tell me how to switch Rust to DX 11?

Dx11 is default

Anyone know a solution to reduce lag without low down my graphics?

[QUOTE=ValyrianLord;48029241]Anyone know a solution to reduce lag without low down my graphics?[/QUOTE] Buy a better computer or wait for the game to be better optimized if you don't want to turn the graphics down to get better performance.

[QUOTE=ValyrianLord;48029241]Anyone know a solution to reduce lag without low down my graphics?[/QUOTE] Select "fast" from the initial menu... Then in game hit F2 and play with all the settings until you have a descent framerate. If that doesn't work, you might have to consider the fact your computer is a Word/Internet Browser machine, not a gaming machine.

Alright, this multi threaded debate needs to stop. Is per the [URL="http://playrust.com/friday-devblog-23/"]Friday Devblog[/URL], Rust Experimental is currently using Unity 5. Referring to the official documentation on Unity's site [QUOTE='Official Unity Documentation']Unity 5.0 ushers in the 64-bit era, we’re upgrading PhysX to the newest and most powerful 3.3, and a new multithreaded job scheduler will be introduced so that you can light all the cores on fire.[/QUOTE] Quoting you on this: [QUOTE='Deicide[RS];48024841']The game is still single threaded even if the os and other stuff is using different threads and CPUs[/QUOTE] You can immediately see (Just from the graphics processor) that it's not single threaded. Now, you may say that I'm [I]still[/I] misunderstanding, but let's continue to the code side of things. From the [URL="http://answers.unity3d.com/questions/908054/unity-5-multithreading.html"]following Q&A post[/URL], the answer dictates that multithreading did not only start on Unity 4.x, but you could use `System.Threading` for any type of methods in your native code (Being C#) - So it's fair to say that there is a real good chance the dev's used tasks (requiring threading) for whatever methods they feel need to run. [QUOTE='Q&A Answer']You can already generate terrain (and, in fact, many bulk background tasks) on a separate thread using Unity 4.x[/QUOTE] [U]We may be confusing multi threading with using multiple CPU's[/U]. While you [I]could[/I] create a multi threaded application on a single CPU system, this will be highly lacking. This is because there is a limit to how many simultaneous threads can run on a single CPU (Usually 2). If there are more threads queued, the rest of them have to wait for the beginning threads to finish before starting. Thus, the more cores you have, the more [I]simultaneous threads[/I] you can have running at once. Based upon the evidence above, this will mean that your threaded tasks (and Physics) will be distributed along the available physical CPU's, resulting in a boost in performance.

If it needs to stop, you need to stop feeding the fire man :) Unity "providing a multithreaded job scheduler" doesn't mean Rust is using this, let alone using this in the fashion that you are hoping for or assuming here. The Q&A mentions generating terrain which is a very punctual and minute task compared to everything else going on in the game and again, this is all dependant on having a memory/hard drive access that allows actually getting a gain from this. I don't know how Rust is programmed map-wise, most games either use chunks (imagine the map is a grid, the game will load for you all surrounding cells and load/unload cells as you move about). You could have the chunks load in a thread, but that wouldn't change much in terms of game performance because it's not a CPU intensive task (it is on the other hand a hard drive intensive task and potentially a memory intensive task), it would just ensure a slightly smoother main thread (the one drawing, cause that's what most games do for the most part). You mention System.Threading. This is available to anyone using C# and we know the game is programmed in C# so yeah, theoretically they could go all out using threads like there's no tomorrow. That said, the same issues arise AND also a lot of libraries are not thread-safe so there are limitations to what you can do in threads. The bottom line is the same here, if you are talking about HDD and ram intensive tasks, it doesn't change anything if you throw 1 or 2000 cores at it, the CPU is not the bottleneck. And now you talk about multi-threading and using multi-cores. First off threads are an OS-level contraption, processors do not have threads or even know what threads are, they just run the code you give them. The OS can handle any number of threads, probably up to the 32 bit unsigned int limit I'm not sure and it's quite irrelevant anyways and all these threads can "run" on one core. The OS takes care of scheduling these threads on the CPU, following its priorities (again set at the OS level), giving each thread the CPU time it's allowed. Unless a thread is higher than every other thread, no thread will "wait until another thread is done", all threads at the same priority level will share the CPU time equally (so long as they are not idle). Unless you lock an application to a certain core, any core can end up with any thread from any application. If your application kicks off two CPU intensive threads and nothing else is currently using CPU, those two threads will be dispatched to two different cores (if available) and executed simultaneously. Now that we cleared all that up, I'll have to swing back to what I've been saying from the start. Lets take the chunk example I mentioned and say the game has a function called LoadChunk which takes a chunkId as it's parameter. Lets imagine the function loads the chunk from disk (75% of it's execution time and then takes the 25% left to uncompress and organize the data). We run this function with chunk 1 it takes 300 milliseconds. We run this function with chunk 2 it takes 300 milliseconds too. If we kick both of these in threads, it will not take 300 milliseconds to finish, it will most likely take approx 500 milliseconds. The reason for this is that most of the work is HDD access (in that 75% part) and memory access (in that 25% part), both of which are SHARED by both cores/threads. Your HDD doesn't magically quadruple speed when you pass from 1 to 4 cores... your Ram does not magically get to X4 speed either. Lets be clear, I'm not saying there is zero gain here, but the amount of work required to make a proper multithreaded application is rarely worth the effort that goes into programming it. If they spend that same amount of time optimizing the code, they will most likely end up with a faster end result. And back to the very original question in this thread.. the OP is asking how multithreading can be unlocked for Rust... It doesn't work like that.. The game is either entirely built to use multi-cores or not, it's not a compiler switch or a game switch, the game needs to be completely designed and thought out to use multiple cores and most of the CPU time of a game is rendering and rendering isn't something that can easily be multithreaded. Not just that, it's also a memory intensive task which would gain little from using multiple cores. And with this, I'm done with this thread :)

This game sports 49+ threads on runtime, still, irrelevant to the OPs original issue.

Any admin plz close this thread!

Geek fight!!!

[QUOTE=ValyrianLord;48057278]Any admin plz close this thread![/QUOTE] it was dead for 3 days before you bumped it..