Out of curiosity, Tom: How exactly does the map threading distribute work, and what work specifically?
Does this apply to object initialization at all, or simply distributing how appearance updates are communicated?
Are the threads spawned one per z-layer, or are they grouped by z-layer, or are they grouped by client?
Any information would be helpful so that people like me can tear apart how it works and eventually figure out how to manipulate it optimally.
ID:1495689
 Feb 12 2014, 3:45 pm
|
|
|
Feb 12 2014, 3:58 pm
|
|
Tom
 |
Lummox JR will have to answer that as I only did the initial multithread prototyping and this is more complicated. From what I understand, there is a separate thread pool that is used to handle the loading of data onto individual client maps, which is a large part of the server processing. Since that is easily done in parallel, it is logical to multithread. I do not believe it uses one thread per client but rather a dynamic thread pool, but I am not sure.
|
Thanks, Tom. Will page Dr. Lummox.
| |
Can someone even explain multithreading. What is it, and how do I even attempt to use it.
| |
Multi-threading, in short, is essentially writing a program that operates on multiple threads. Threads are executed in sequence by your processor. A single thread has a specific scope that it operates in as far as memory is concerned, and passing objects and data between multiple running threads takes a bit of planning and doing.
However, the advantage of multi-threading, should you adapt it to work for you with your application, is that each independent segment of that program can operate asynchronously, performing tasks that don't have to wait on the other threads. (Provided your CPU can schedule the instructions.) Basically, each thread has a slice of time allotted to it. If you have 30 threads running on your machine, your OS will be flipping back and forth between the threads. If the thread signals that it has nothing further to do, it yields to the next thread, allowing it to process. If the thread runs up against its allotted time, the CPU stops processing that thread for a little bit in order to allow the others to perform their tasks. Modern machines have multiple processors and very advanced schedulers that allow multiple threads to batch instructions to the same processor concurrently. A core i7 is basically a quad-core with hyper-threading, which breaks 3 of the 4 cores into 2 virtual processors, each with an allotted half of that core's total power. I'm a little fuzzy on some of these details. Basically, what DS/DD becoming multi-threaded means that certain parts of the client and server now aren't tied to one another. Within DD, there are essentially three components: The VM, the DD UI, and the networking layer. Both the VM and the networking layer communicate with a central core of functions and data in order to be interoperable. DS, on the other hand, has three slightly different components: The User Interface, the host-server (includes VM and server-side networking layer), and the client-side networking layer. These layers both communicate via a central core of functions and data. Essentially, Dream Seeker was recently made multi-threaded to allow the User Interface to not have to wait on the host-server to complete tasks before updating and interacting with the host-server. This really only affects the host, but in theory the reverse is true, which makes the experience better for the connected clients too. Tom and Lummox are now working on getting Daemon set up for a multi-threaded approach, which seems to involve separating out the Daemon UI and certain aspects of the networking layer to different batches of threads, which in theory should allow the VM a larger chunk of the server's CPU resources to perform intense tasks, and should also allow significantly more intense/regular network communication to be triggered before the server gets bogged down. As for how you use it? Well, you don't really. You have two options: On, and off at the moment. The virtual machine still operates on a single thread, and the only control you really have over BYOND is through that virtual machine. What I'm fishing for, is weird corner-cases where performance is impacted by potential flaws in the design (There are always flaws), or ways to exploit the way it's set up in order to achieve more smooth/stable flow by playing to the strengths of the system and avoiding the weaknesses. EDIT: It's really late, and I'm on a two day code bender here... Please correct any mistakes/miscommunications in this explanation at will. A lot of it is guesswork and piecing together cryptic explanations spanned out over years of jumbled forum posts. On top of that, my experience with multi-threading is pretty well limited to writing model loading pipelines, asset processing pipelines, and writing parallel socket-based MUDs in C++. Most of my understanding of how parallel processing works is gleaned from GPUs, and not CPUs. | |
So let me try to understand this, I get the concept of multi-threading.
Let's say you have a terribly inefficient game lets just say Naruto v3xjfrjdnd it runs at around 60-80% CPU pre threading, a server with ONE core and now that multi threading is enabled on the client and server the CPU could potentially increase two/three fold? But if multi threading is off on the server the CPU would continue as it did pre beta? Regardless of if the client had it on or not? I'm sure they have something in place in the back end to switch the clients threading off of the server doesn't use it. | |
A.T.H.K wrote:
But if multi threading is off on the server the CPU would continue as it did pre beta? Regardless of if the client had it on or not? I'm really not entirely sure here, I'm going on gut and what makes sense here. DreamSeeker's multi-threading decouples the UI stuff from the DS-server stuff. I'm not sure if it decouples the client-side networking stuff from the UI stuff as well. If the UI stuff is decoupled from the networking stuff, there is a chance that DS can span two cpu cores in order to divide the workload. However, very little that the developer does is going to directly impact the UI and client-side networking stuff. I want to be clear, though, that I'm only certain that DS is threaded if you are hosting. Even if it wasn't, it doesn't really matter, because the client being bottlenecked really shouldn't affect the server much. I'm not entirely up to speed on how BYOND deals with awaiting TCP message confirmations, or how an unconfirmed or delayed message impacts the server. If it were UDP-based, I'd have no qualms flat out saying that it would have no impact, but I just don't entirely know a lot about TCP. A.T.H.K wrote: Let's say you have a terribly inefficient game lets just say Naruto v3xjfrjdnd it runs at around 60-80% CPU pre threading, a server with ONE core and now that multi threading is enabled on the client and server the CPU could potentially increase two/three fold? I guess you would be concerned heavily about this, considering you run a server hosting business... This shouldn't affect you though, considering you should be using PAM or something like it to limit your users' access to their dedicated system resources. (I'm not all that spun up on Linux, really. You'd know more about that.) Anyway, it's my understanding that the UI thread for DD will be relatively lightweight, thus there's no concern about that being a separate thread. Then there's the map threading. In theory, the map threading being on separate threads should allow DD to access more of the available CPU time than a single thread would allow, since that thread can be assigned to a different core. Again, though, your concerns shouldn't really be a big deal, provided you have set up your users' access/resource limitations correctly. At least, in theory. I do want to make it absolutely clear, though, that I'm really balancing on the edges of my knowledge here, and I need to brush up on a number of things before I can say any of this with certainty. | |
The easiest way to think of it is that any operations that can be performed simultaneously could theoretically be done in parallel with threads (and if you have multiple cores, which most modern machines do, these will _truly_ be in parallel).
Now, in practice, this is a very difficult problem, so we're taking baby steps and just isolating operations that are easy. The most prevalent one is the generation and sending of the view (map) for each connected client-- since each client operates independently (that is, its view contents don't affect the other clients), theoretically this operation can be offloaded to a separate thread from the main server processing. So the server can tick away and do all of its computations on one thread, and whenever it needs to send the map to a player, that can be done on a separate thread, thus not delaying the normal tick. Obviously there are many other operations that could benefit from this approach but we have to get it working first. | |
Tom wrote:
Now, in practice, this is a very difficult problem, so so mutexes :v i have 100% faith that you and Lummox will give us something wonderful. hope i can afford to give you more $$$ soon, thanks for all the recent progress. | |
Honestly, I wouldn't mind seeing some sort of "I know what I'm doing" analogue to spawn that lets someone who knows how threading works have "true" DM threads, even if race-condition bugs were left entirely up to me/whoever to deal with.
| |