multithreading vs events

[OverKillasdwqe]

what would be a better architecture
multi threading (for instance monsters spawning)
vs
events being raised on the main thread (for instance when monster get killed it check if it needs to respawn more)

i know that i would need atleast 1 more thread to manage stuff that doesn't have event to respond to also to avoid blocking the main threat at any cost, but im talking about the main architecture where i would have maybe 10 threads vs 2 threads (one would be main, second would be for event handling)

what you folks think is better and why
feel free to mention another better architecture

[Y u k i]

A single threadpool thread can respawn all your mobs on a timed intervall. Thats simple to code and doesnt eat much ressources. Just build a queue where you insert dead mobs and use the timed thread to check if it should respawn, do that loop every other second and you're fine.

You should optimize other parts first, respawning mobs isnt really demanding

[OverKillasdwqe]

Originally Posted by Y u k i

A single threadpool thread can respawn all your mobs on a timed intervall. Thats simple to code and doesnt eat much ressources. Just build a queue where you insert dead mobs and use the timed thread to check if it should respawn, do that loop every other second and you're fine.

You should optimize other parts first, respawning mobs isnt really demanding

you specified the case rather than generalize it which is what i wanted to know in the first place
i was talking about excessive usage of multithreading vs simple use of threading with every thing based on events call backs and which would save me more memory usage also be safe and reliable no matter how complex the design would be

i kinda prefer simple threading with alot of events running on timer being raised by player actions and others
if x kill some monster, i add a func to summon more with time + a delay
if x got super man, i add a func to stop the sm at certain time and add more seconds to that time when he kills monsters
on server start i add all events with a func for each event to handle it on time
and so on

on the other hand of excessive usage of multithreading
i check for monster spawns and summon them with a thread
i check for all players flags and act upon
i check for time and switch on events time to start one of them

[Y u k i]

Then go with a event based async model. Events do not have to block if you use TPL or BeginInvoke. Threads will slow you down more than you'd get a speedup if you use too many threads.

[OverKillasdwqe]

Originally Posted by Y u k i

Then go with a event based async model. Events do not have to block if you use TPL or BeginInvoke. Threads will slow you down more than you'd get a speedup if you use too many threads.

thanks for the information, i've edited my second post (maybe you need to have a look)
also i was hoping for reasons of why would too many threads slow me down

[Y u k i]

Let me explain threading using this disgusting looking cake.

The cake represents a CPU Core. Every slice is a thread. Threads 'split' the cpu into smaller parts so a single unit can look like its performing multiple things at once.

To do that, it has to "context switch" between all threads.



As you can see, my 8 core cpu is sliced into 1100 parts. That means it has to switch between 1100 states every so often. The OS tells the cpu when and how often to switch between threads.

Switching is very expensive, thats why using alot of threads JUST FOR YOUR application will slow it down as its not certain how much time each thread gets. For example, your thread might need 3ms to complete work, it gets only 1ms of cpu time and has to wait for 10ms for the next share. You see where I'm going with that right? Imagine you having 20 Threads...

If you have lets say 5 threads, you should be fine. I use a thread for Mobs, Players, Items and Packets <- Just the processing queue in and out, everything else is used with async events. I really spent alot of time reading and learning the TPL so I can do **** threadless and the performance is awesome so far. Me and Execution ran our source and Conquer Server v2 (Hybrids) and saw superior speed in every case one case even 12% faster than hybrids.

[InfamousNoone]

I wouldn't use v2 as too proud of a point of comparison. v2 was ahead of it's time but due to me inexperience with async and multi-threading there are some pretty wonky things that go in v2, like creating a thread every time an attack happens -- which is very very bad.

Given 30k mobs, 1k players (all active hunting) Conquer is so undemanding of resources that you should be able to do all of this (processing packets, monsters, and pretty much everything) in 1-3 threads with under 5% cpu usuage. This is what I would consider a reasonable goal and I wouldn't bother over modeling things to, you know suit say 10k players and "do it the right way" you're looking at 2-3k on 1 server tops and even that would be an overestimate since UG doesn't even see that much.

[Korvacs]

Worth noting that while Yuki complains that 20 threads would be ridiculous for one application, based on the screenshot provided 59 processes are using around 18 threads each.

So actually 20+ threads is perfectly fine and shouldn't be considered a hindrance, we're talking nanosecond delays when switching threads on todays hardware, it's not the 1990s any more.

[Y u k i]

Originally Posted by Korvacs

Worth noting that while Yuki complains that 20 threads would be ridiculous for one application, based on the screenshot provided 59 processes are using around 18 threads each.

So actually 20+ threads is perfectly fine and shouldn't be considered a hindrance, we're talking nanosecond delays when switching threads on todays hardware, it's not the 1990s any more.

You should never underestimate adobe after effects AAE and the Media bridge plus all the extra services use around 400 threads...

[Korvacs]

Originally Posted by Y u k i

You should never underestimate adobe after effects AAE and the Media bridge plus all the extra services use around 400 threads...

No you shouldn't though that preciously proves the point, it doesn't matter how many threads you use. It's entirely about what you do with them. Nowadays multi-threading dramatically outperforms single threading for the exact reason that you can spawn more threads to evenly distribute your work and complete it faster over all.

Please stop spreading doom and gloom about multi-threading, most of it is inaccurate. Multi-threading hindering performance only really effects older low core processors, and those without hyper-threading, in almost all other cases its an improvement.

[Y u k i]

Well atleast I made you post something useful to all of us in the end.

[Korvacs]

Originally Posted by Y u k i

Well atleast I made you post something useful to all of us in the end.

Thanks for the laugh, now back to your corner.

[Super Aids]

The real problem with a lot o threads are not performance, but dead locks, synchronization and concurrency.

[Korvacs]

Originally Posted by Super Aids

The real problem with a lot o threads are not performance, but dead locks, synchronization and concurrency.

And even then none of those are problems if you design your threading correctly.

[KraHen]

The idea would basically be not to give a specific thread a specific task, like this is the attack thread and that is the spawn thread or whatever, distribute what needs to be distributed over all threads, if you can pull that off, you`re good to go. For instance, you could just make a thread that executes callbacks in a queue, then add an attack there, a spawn, whatever. This is what I use out of a CO context, together with an epoll based socket system and it has not failed me to this very day (its running for internal testing with 1000 CCUs/day 8hr, and yes, its an MMO). This has given me the best results with the minimal amount of threads, but you need to design your system carefully.

Of course, specialized threads can still be added, like a thread which specifically handles timed stuff or whatever (even that is an overkill anyways, but meh, deadlines are deadlines).