   [C#/C++]Multithreading
For those of you who havent heard, EVE Online encountered a massive 2800+ player fight the other day, which resulted in a less than perfect battle, I wont bother going in to details about the fight or game, however it generated a lot of complaints, the main one being "the game only uses one core, why not all?". The game is built using stackless python and C++ Now a spokes person for CCP responded with "...there's no simple way to make something multithreaded..." among other things. Ok so my question is (baring in mind I do ALL my multithreading work in C#), how accurate is this statement? I am not trying to cause a flame war or anything I just find this comment 'unusual' and feel it is invalid but due to limited experience in C++ it would be wrong of me to even assume this, help me understand what he means. The link is here: https://forums.eveonline.com/default.aspx?g=posts&m=2541374#post2541374 Thanks in advance PS: The reason I havent asked CCP myself is simply because they are terrible at replying and put very little effort in responding
  It's extremely hard to take an existing, large, code-base and try and shoe-horn in parallelism. You need to have a multi-core processing strategy in mind from the very start of the project in order to be effective.   ;  He is correct; multi-threading is not simple.. or to put it better; "multi-threading so things don't run the chance of crashing and other problems while still maintaining performance is not simple".This is the normal case of gamers, having heard about something, demanding it without really thinking about what's involved in a move like this when you are trying to build on an ever expanding 10 year old game which was originally designed and built back when multi-core systems were not the norm.Could they do it?Yes, given time all things are possible... but it'll take a lot of time and a lot of pain (and probably a few dodgy patches long the way) to do so.Based on the comments in thread re:lag in game things have certainly improved server side over the years (I seem to recall the early lag they talked about when I played around launch; jump into a system with a fair few people around the gate and things started to stall a bit...)   ;the main one being "the game only uses one core, why not all?" I was under the impression that the main issue was server load, not client? "...there's no simple way to make something multithreaded..."  ...  how accurate is this statement? I would say it's pretty accurate. You can't really just flick a switch and turn on multi-threading. While some optimising compilers can parallelise some loops if they can determine there are no side effects, in general you have to actually write multi-threaded code.  That's not too bad if you're starting from scratch. While multi-threaded code still has it's gotchas, more widespread use of the last few years has brought about some patterns and principles that ease the burden. But refactoring an existing code base to be multi-threaded? That's very rarely easy. ;  Writing multithreaded code is easy, writing multithreaded game code that actually performs better than its singlethreaded counterpart is a bit harder and modifying a huge 10 year old serial codebase to execute well in parallell ... well ... thats borderline insanity.Efficient parallell code is extremely different from efficient serial code, since EvE is a fairly old game there might be some low hanging fruit to pick but to get the big performance increases it might be cheaper to just start over from scratch with a new client engine.   ;  I don't know what kind of multithreading you did in C#, but from my experience it's not easier than in C++. So if you say, that multithreading in C# for all your needs is easy than either a) you're a freaking genius or b) your problems were perfectly fitted for multithreading.Our brain is just designed in a way that it thinks sequential. Once multithreading comes into play, it's hard to even imagine what might happen and to think of all possible scenarios. Andrei Alexandrescu from the C++ consorptium pretty much naiiled it: "Multithreading is just one damn thing after, before, or simultaneous with another". And that's all we know.When the code based is not designed for parallelism from the start it is a great step to adapt.The funny thing is, that most of those people complaining about only one core being used would shut up, if you'd just create <number of cores>-1 threads in your program doing nothing but an infinite loop so they see 100% of CPU usage.What I am trying to say is, that saying "...there's no simple way to make something multithreaded..." is very accurate. Usually, the first 2 or 3 attempts to parallelize a previously sequential algorithm/architecure will lead in full CPU usage but in slower execution.   ;I don't know what kind of multithreading you did in C#, but from my experience it's not easier than in C++. So if you say, that multithreading in C# for all your needs is easy than either a) you're a freaking genius or b) your problems were perfectly fitted for multithreading. Just to clear things up a bit, what I meant by my comment was I am only familiar with multithreading in C#, and since his comment was referring to C++ I was wondering what he meant. Oh and I should mention I wasnt a poster in that thread, and only became aware of it when it was moved. I dont actually 'play' but I do make use of their API so it made very little difference to me, this was simply curiosity more than anything :) Anyway thanks everyone for answering, I sometimes word things wrongly but this truly was a "if in doubt ask" moment;  Sorry if my comment sounded harsh or belittling or anything, it was not meant that way.   ;Also worth noting that a bunch of Eve's server-side code is written in Stackless Python, and Python in general is a nightmare to multi-thread. (there is a little doohickey called the Global Interpreter Lock, which throws a great big wrench in the works);Yeah, that thing is a pain... our old build system was based on Python which basically meant all build 'setup' was single threaded (which involved working out a dependency graph; quick on small asset counts but as the assets increased so a comedy wait time was introduced before it started building) and while the external tools were run outside python because of how it was designed you had to spin up 100s of threads in order to launch and wait for them to finish... (GIL is released when waiting on an external process.) Fortunately this became a big enough problem that a C#/.Net re-write was allowed \o/