These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE General Discussion

 
  • Topic is locked indefinitely.
 

multithreading and the current code.
Author
Previous Topic Next Topic
Darek Castigatus
Immortalis Inc.
Shadow Cartel
#1 - 2013-11-25 21:27:44 UTC
So im curious if CCP has ever actually sat down and worked out how long it would take to rewrite the current code to take advantage of multi threading??

I know its always been mentioned as a major issue in terms of performance improvements but i know next to nothing about it other than a lot of people say it would make ramping up eves performance much easier.



Pirates - The Invisible Fist of Darwin

you're welcome
brinelan
#2 - 2013-11-25 21:53:30 UTC
They have said in the past that the problem is keeping the threads in sync is the bigger issue. So if thread 0 has your command to shoot and thread 1 processed that command and the ship exploded, if they get out of sync your target would explode before your click to shoot registers. May not be the best example but its an example nonetheless.
James Amril-Kesh
Viziam
Amarr Empire
#3 - 2013-11-25 21:54:06 UTC
brinelan wrote:
They have said in the past that the problem is keeping the threads in sync is the bigger issue. So if thread 0 has your command to shoot and thread 1 processed that command and the ship exploded, if they get out of sync your target would explode before your click to shoot registers. May not be the best example but its an example nonetheless.

Race conditions are a *****.

Enjoying the rain today? ;)
babyblue
Republic University
Minmatar Republic
#4 - 2013-11-25 22:25:03 UTC
You won't neccessarily get a performance gain anyway due to something called False Sharing. I've seen code designed to run on 8 cores (4 cores x 4 hyperthreaded) only give 1.5x performance when a naive interpretation of program flow would make you think it should be nearer 8x as fast. Coding to avoid false sharing is very hard on modern CPUs. Firaxis managed to solve the problem in Civilisation V with some very clever pipelining tricks (well, not tricks, just a good design pattern). The problem for Eve is a lot of the code is running interpreted Stackless Python, so that's a whole other layer you'd have to strip out and re-write to give you more control over the platform architecture.

As brinelan says, your thread synchronisation has to happen at some point in any case. For the graphics this happens in the driver, so the only gain you get from multi-threading is batching commands which might not be much of a win (DirectX demos certainly don't impress very much). On the server side, there need to be low level locks all over the place to keep things in sync, so the bottleneck might appear there even if you solve it elsewhere.

I think in future a lot of grunt work will be done server-side with CUDA, Direct Compute or similar, making use of GPUs like NVIDIA's Tesla. You'd get a massive performance gain but... you still need to synchronise, so perhaps not.

Anyway, multi-threading software is hard and debugging multi-threaded software is even harder. It can make a developer go grey overnight.

Cheers.
Tippia
Sunshine and Lollipops
#5 - 2013-11-25 22:38:48 UTC
Somewhere between 1 and 58 years.

Some of it is already in progress, but is less about classic multithreading and more about sectioning off particular tasks that aren't as reliant on continuous synchronisation and offloading them to a separate server.
Tau Cabalander
Retirement Retreat
Working Stiffs
#6 - 2013-11-25 22:50:34 UTC  |  Edited by: Tau Cabalander
Client side:

Last I checked, CPU usage wasn't an issue, but GPU usage is.

Damn cloud effects!

CCP is transitioning to DX11 though.

Server side:

Stackless Python. That wouldn't have been my first choice.
Frostys Virpio
State War Academy
Caldari State
#7 - 2013-11-25 23:15:06 UTC
Tippia wrote:
Somewhere between 1 and 58 years.

Some of it is already in progress, but is less about classic multithreading and more about sectioning off particular tasks that aren't as reliant on continuous synchronisation and offloading them to a separate server.


Sometime it really feel like doing code from scratch is easyer than "morphing" to multi threaded.
Frostys Virpio
State War Academy
Caldari State
#8 - 2013-11-25 23:17:11 UTC
Tau Cabalander wrote:
Client side:

Last I checked, CPU usage wasn't an issue, but GPU usage is.

Damn cloud effects!

CCP is transitioning to DX11 though.

Server side:

Stackless Python. That wouldn't have been my first choice.


It probably looked like a good idea 10 years ago. Maybe they just never predicted it would have that many client connected to a single system at the same time so a single thread was not that bad.
Toshiro Ozuwara
Perkone
#9 - 2013-11-25 23:20:22 UTC
brinelan wrote:
They have said in the past that the problem is keeping the threads in sync is the bigger issue. So if thread 0 has your command to shoot and thread 1 processed that command and the ship exploded, if they get out of sync your target would explode before your click to shoot registers. May not be the best example but its an example nonetheless.

That already happens when you shoot someone with missiles at range. The wreck tends to appear before the missiles land.

It didn't take long to locate the tracking beacon, deep inside the quarters for sleepin' They thought they could get away Not today, it's not the way that this kid plays