No, I am a good one. Multithreading isn’t that hard. The reason why they haven’t is because they used literally the worst language for the core systems. ■■■■■■■ stackless python, which doesn’t support MT. I’m honestly surprised they haven’t tore the code down and refactored it to something more sane. That’s what they need to do, and yes I know it’s a huge task. But they really need to refactor or start from scratch in a real language. I’m not sure if SP can use modules created in other languages but honestly, that’s where I’d start first if possible. Start offloading things from the original code in to modules that’s been coded in a different languages that supports MT and can do the best job for the task at hand. ie R for some things, C/C++ for others. After a while, the code itself will resemble the architecture of a microkernel. Once it’s like that, you can unplug the remaining code and replace it with a real language.
a phi co-processor or GPU would be able to do that in 1 or 2 cycles. The amount of pipelines they have is insane
You just proved you don’t know ■■■■ about programming.
Parallel programming is the hardest thing in programming (from an engineering pov). It can’t be tested, it’s very hard to debug, it’s randomization-prone, a single bug won’t be detected but will cause a thousand other ones. It requires interlacing the code for CORRECT performance(which means harder debug), to the point just observing the code makes you feel you may break it.
No it can’t.
You know what kills GPGPUs ? the “if” keyword in your language (jX in assembly). That KILLS the gpgpu because the pipeline uses precache of instruction and the instruction flow is killed by this keyword.
Anywhere you make “if” statement, your gpgpu needs to double the number of pipeline and memory to keep with performances. (this is limited by the instruction cache size though - so if cache for 8 instructions, that means 256 times the pipelines and memory)
GPGPU are NOT meant to be usable to MMO servers. Why don’t use use a gun to shoot the item you want to send directly ? It’s so much faster !
Modern CPU’s are designed to distribute the workload across multiple cores - not maximum single core performance and this is unlikely to change. Bigger fights will require multi-threading. Logically, there is no reason why the processor needs to deal with each ship serially - those calculations can be done in parallel. You may need to collapse to a single thread to resolve the outcomes but it should still be a lot faster than the current situation.
This is a lot of work for a rare event but the big fights are a big part of what makes Eve special and I believe it would be worth the effort.
The DATA must be hold in ONE physical place.
When you want to “deal with ship in parallel”, you need to copy the whole data to each other thread, because you don’t know what data must be used in the “dealing” process. THEN you need to merge all small modifications, and apply them toe the main DATA place. The cost of creating the small chunks of system we “deal with”, of transmitting the data to each of those chunks, and finally of merging the data (and I don’t even talk about conflicts) can, and most reasonably will, exceed the gain induced by parallel computing.
Lol, JFC, “multithreading isn’t that hard”? I have two words for that: race conditions. When you understand why things like that are a hellishly difficult problem to solve you will understand why this thread is so ridiculous.
The issue with that is how intensive the resolution thread will be because we all want all our command to be resolved in the correct order no matter which core ran the command. If my point get nullified because your warp command was processed a little bit faster on a different core, the game will feel random.
There are a number of mechanisms for synchronous sharing of data between threads. I believe Eve developers use Stackless Python which has synchronous queues builtin.
Since Eve operates on discrete server ticks, the processing for each ship is known at the beginning of the tick, it really doesn’t matter if it is processed serial or parallel. Thread synchronization is really only required when the results are written back out to shared memory. Processing order doesn’t really matter since the data is static during the tick.
Internet latency can make a difference whether your point or the targets warp command get processed first because they may not be processed on the same tick. If they are processed on the same tick, I believe the point wins.
The resolution thread will take the same amount of time whether the processing is serial or parallel. The per ship processing should go a lot faster in parallel depending on the number of cores available.
Nothing changes inside the “tick”. Damage will be applied based on shots fired during the previous “tick”. This information will be available to the thread processing the target ship. Order of application can use the same algorithm CCP uses now. Again this is digital - not analog. The battle is divided into discrete ticks - it isn’t continuous.
You’ve missed the point,
My ship has 100 shield with 0% EM resists but 99% explosive resists, 100 armour with 99% EM resists but 0% explosive resists and 100 hull with no resists to anything.
20 people shoot me each doing 10 damage, half of them do EM, half of them do Explosive.
Now if you process them all in parallel with no idea of order, all of them get calculated against my shield resists.
If you process them in a random sequence, which isn’t what the server does, then some of them will hit my shield and some my armour, but they can’t specifically try to allocate EM to shield and explosive to armour.
What actually happens as best as we can tell is that the server takes the exact time it received the command as the order of operations, so if the EM ships all fired 0.3 seconds before the explosive ships, they kill my shields with the EM damage and the armour with the explosive damage.
So while the EVE server operates in ticks, it appears it has a simulation of continuous time inside those ticks.
Otherwise weapons could only have perfect whole numbers of seconds for cycle times.
Net result, you can’t just dump it all into parallel, you have to keep it all in order, and the need to control that order and pass information to another thread and receive it again is probably just as taxing on the server as any of the single calculations themselves are.
if 500 person use guns at the same time, all the guns are applied exactly at this moment.
If FC says " target ccp_falcon. Shoot ccp_falcon in 3 … 2… 1… fire ccp_falcon "then the 500 monkeys (whom I belong to) will alpha ccp_falcon at the same tick. everybody must get its share of damage during that tick.
If each monkey shoots 10 damage, and ccp_falcon has 50% resists and 1000 hp in shield, 3000 hp 0% resists in armor, the first 200 ppl to shoot will deal each 5 dmg to shield, the 300 next will deal 10dmg in armor, but they will know what dmg they will deal only once the previous shots have been resolved.
Now, lets consider another things : CCP_falcon was about to shoot his CODE.RAY that obliterates trolls in vicinity and resurrect them as goons afterwards. The 500 monkeys shoot on the same tick CCP_FALCON activate his CODE.RAY ; but this time they deal in total double his ehp.
Since both activate their guns at same tick, do the monkey shoot half their guns before CCP_FALCON CODE.idy them ? Or does CCP_FALCON get his final vengeance against the Free Retards Of Zooland by shooting his BIG FAT GUN before half the monkeys show him them organs ?
You cannot answer this complex problem if you go parallel. You need to compute serial. Hence parallel computing is not a serial killer.
As they iterate on legacy code to replace it, one thing they could consider is adding In Case of Fire chunks of code that drastically simplify the number of calculations required for massive fights. Missiles, for example, instead of being required to calculate explosion radii and velocities against target sigs and speeds, simplify it down to either velocity vs speed, or radii vs sig.
Another option, if it’s relevant, is any graphical information the cluster needs to send could be reduced by going from gauge information to a number format. Even go a step further and treat ship models just like drones if the server starts peaking, there, but not visible unless you’re in max graphics mode. At that point if I wanted to know where something was, I’d enable those brackets.
Correct, but not relevant if the server is processing static data within each tick. The question is whether it cycles through each ship 1 at a time performing calculations for movement, defense, attack, etc… or if it processes all ships in parallel. The data it’s working with is the same either way. It can be ordered the same way it is now and processed the same way - as long as the data remains static, it doesn’t matter whether it is single or multi thread. As long as the instructions for that particular ship are processed in the proper order it won’t (for example) be able to shoot after it is destroyed.
If the server was trying to process continuous data your point would be valid but I believe it simply queues incoming data for the next tick while processing the current tick - as long as the ticks are 1 second, we don’t notice. In fact, the client lags on a good day. If someone shoots at me in highsec, I generally get the kill right notification before there is any evidence on screen that I’m under attack!
It can’t . cf my question on several ships bumping another one.
You can not consider the movement of entities in a parallel way, because you have to consider collision.
Seriously, you just CAN NOT do that. Stop affirming “you can”. Yes, you can put all those computation in parallel ; but then the synchronization work will make this have LESS performance than serial when handling with several entities.
The fact that a super fast ship, say 5km/second, can’t teleport through objects but instead bumps off them always kinda says that it doesn’t just take 1 second snapshots but calculates the entire trajectory, or at least enough snap shots to provide a reasonable approximation of them. And means you can’t calculate in parallel because you need to move each object in turn by increments.
The ‘lag’ you are talking about is not tick lag, it’s latency, where it simply takes time for the server to tell you about stuff it’s already calculated. And your client then has to actually render it. Also the kill right notification is the first thing in the list when someone fires on you in highsec, well assuming their safety doesn’t stop it. So of course it appears first
In my view the issue isn’t necessarily the server performance but rather the structure of large fleet combat.
If CCP magically doubled the server performance tomorrow you can guarantee that the combatants in the next battle would simply try to cram 12k users into the system instead.
The mechanism by which large fleet battles occur needs to change to limit the number of players on any given node (perhaps with multiple nodes holding individual battle sectors). How this would be done fairly is the tricky part of course. Fleet size limits for each side seems artificial, but it’s the only real way you couldlimit the numbers on each node to minimize TiDi.
The frustrating thing about the whole concept is how arrogant it is.
“Oh, if i were in charge, I would blam it out over a weekend. Obviously the reason why every studio on the planet is neglecting this is because I haven’t graced them with my obvious superiority, and not because it’s probably an impossible problem to solve. You may now praise me for being the world’s most superior intellect. I have solved all the ills of the world with one hand in my pants and the other on my keyboard. I said praise me!”
I feel like I could write a whole book mocking the “why don’t they just…” idiots.
Hmm… idea… probably a bad one since most ideas are bad. What if, when maximum tidi conditions occur, the server randomly started blowing people up. Pop the ship, pop the pod. Bring enough people to crash the node, and you’re probably going to lose a big chunk of your fleet.
I wouldn’t want any randomized destruction to occur as then any large battle could be arbitrarily decided by the RNG gods.
I’d prefer a fleet sized limit of say 2000 maximum (total) on each side for example (note numbers ere are just for example) system A. System A is surrounded by system B, C and D, for an attacker to bring in reinforcement as ships are lost in their system A fleet they need to control the gate (entosis?) to allow more ships through from the system B/C/D side. That would spread combat across multiple systems and hence multiple nodes. Defenders could of course reship from any active citadel where they have a ship ready to go up to the fleet limit.
That’s just a random idea off the top of my head, but any combat should be decided by the participants actions, not the servers.