| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |

Evelgrivion
Coreli Corporation Corelum Syndicate
|
Posted - 2007.03.29 22:24:00 -
[1]
After seeing the growth of fleets, blobs, and warfare, knowing how much load goes onto the one processor, I think it is safe to say that one CPU does not maintain enough processing power to support a solar system in a large scale fleet battle - especially in battles that have over 300 people involved.
The only realistic solution left is allowing the Solar System threads to be spread across multiple CPUs. If CCP is working on this, what are the technical challenges involved? My understanding is that Python threads pretty well, but how are things for EVE in practice?
I would love to know if CCP is preparing to allow solar systems to span multiple nodes; it could finally lead to the end of horribly laggy fleet battles - a necessity in this day and age where there will essentially always be an advantage in bringing more numbers. ---|---|---|---|---|---|---|---|---|---|---|---|--- This isn't the signature you're looking for. |

Tar om
Minmatar Octavian Vanguard RAZOR Alliance
|
Posted - 2007.03.30 16:42:00 -
[2]
Hear Hear! -- We are the Octavian Vanguard www.octavianvanguard.net
"The belief in the possibility of a short decisive war appears to be one of the most ancient and dangerous of human illusions."
|

Max Hardcase
Art of War Cult of War
|
Posted - 2007.03.30 18:12:00 -
[3]
EVE also doesnt adjust what systems fall under 1 processor on the fly. Thats what downtime is for.
|

Xianthar
STK Scientific Rule of Three
|
Posted - 2007.03.30 20:24:00 -
[4]
Originally by: Evelgrivion After seeing the growth of fleets, blobs, and warfare, knowing how much load goes onto the one processor, I think it is safe to say that one CPU does not maintain enough processing power to support a solar system in a large scale fleet battle - especially in battles that have over 300 people involved.
The only realistic solution left is allowing the Solar System threads to be spread across multiple CPUs. If CCP is working on this, what are the technical challenges involved? My understanding is that Python threads pretty well, but how are things for EVE in practice?
I would love to know if CCP is preparing to allow solar systems to span multiple nodes; it could finally lead to the end of horribly laggy fleet battles - a necessity in this day and age where there will essentially always be an advantage in bringing more numbers.
the difficulty is in synchronization. doing the math for 1 large fleet fight on 2 cpus is difficult at best do to shared data needed for both calculations and the fact that you may have to ensure that cpu A is finished with something before CPU B works on it, etc. non blocking data structures can help with this some but there are many issues.
it is a hugely difficult problem to solve...newer cpu's with many cores on 1 die sharing a large L3 cache should make this easier, i hope. Multiple CPUs across separate blades working on 1 system will most likely never happy, even with inifiband between the blade the sync issues would be huge.
-xian Your signature exceeds the maximum allowed filesize of 24000 bytes -Sahwoolo Etoophie ([email protected]) |

Xianthar
STK Scientific Rule of Three
|
Posted - 2007.03.30 20:25:00 -
[5]
Originally by: Max Hardcase EVE also doesnt adjust what systems fall under 1 processor on the fly. Thats what downtime is for.
downtime is mostly for database maintaince. The cluster is capable of changing what cpu a system is assigned to any time that system is empty. it's only limitation is that it can not move a system with a player in it to a different cpu. Your signature exceeds the maximum allowed filesize of 24000 bytes -Sahwoolo Etoophie ([email protected]) |

Shiraz Merlot
Octavian Vanguard RAZOR Alliance
|
Posted - 2007.03.31 08:30:00 -
[6]
Originally by: Xianthar it is a hugely difficult problem to solve
Don't be silly. Fine-grained locking techniques and sensible logic design make a high degree of parallelism easy to develop. This stuff is a solved problem.
What's embarassing is that Python doesn't support SMP, at least not officially, despite projects such as Parallel Python. This is where CCP should be focusing their server-side development.
/SM
|

Xianthar
STK Scientific Rule of Three
|
Posted - 2007.03.31 14:40:00 -
[7]
Originally by: Shiraz Merlot Python doesn't support SMP
read: http://www.stackless.com/
-xian Your signature exceeds the maximum allowed filesize of 24000 bytes -Sahwoolo Etoophie ([email protected]) |

Shiraz Merlot
Octavian Vanguard RAZOR Alliance
|
Posted - 2007.04.02 04:02:00 -
[8]
Originally by: Xianthar
Originally by: Shiraz Merlot Python doesn't support SMP
read: http://www.stackless.com/ -xian
Stackless is even less SMP-friendly, since it implements its own tasklet scheduler over a single OS thread.
/sm
|

Savvy
Gallente LFC Lotka Volterra
|
Posted - 2007.04.05 09:03:00 -
[9]
Companies that do finite element analysis have been getting problems to be solved across multiple cpu's for years and some now use gpu's to do the work not cpu's as its hundreds of times faster that way (yes I do mean Graphics Processing Units).
This kind of processing is hardly new but it does require a carefully planned programing approach to make it work.
I would like to see CCP solve the issues as raised by the OP as lagged out fleet mess is no fun to anyone and 300 is a small number for fleet fights these days !
|

Solbright
|
Posted - 2007.04.05 10:15:00 -
[10]
That'll be cool, then maybe the masses will finally get round to complaining about stutter instead of always blaming lag even when it's not lag.
|

Xianthar
STK Scientific Rule of Three
|
Posted - 2007.04.06 03:08:00 -
[11]
Originally by: Shiraz Merlot
Originally by: Xianthar
Originally by: Shiraz Merlot Python doesn't support SMP
read: http://www.stackless.com/ -xian
Stackless is even less SMP-friendly, since it implements its own tasklet scheduler over a single OS thread.
/sm
eve uses micro threads to manage almost everything in the eve game mechanics, stackless python is the reason that eve can run as fast as it does. You can in fact spawn a separate python process on the a second CPU and communicate between the two, this is where the sync issues are and load balancing between those processes would be a nightmare at best. There are too many threads needed in eve to use true OS threads to run them due to the fact that OS threads are terribly heavy, on most OS's spawning and switching processes is as fast(slow) as switching threads. So switching threads takes FAR too long compared to stackless python's mini-threads for eve to work. hence why stackless python is used instead of say C for the object intensive parts of the game code.
so what you/we really want is a python interpretor that works with the stackless scheduler to switch microthreads accross multiple CPU's close to as fast as the current stackless python scheduler can on a single cpu.
that is a very difficult problem to solve.
-xian Your signature exceeds the maximum allowed filesize of 24000 bytes -Sahwoolo Etoophie ([email protected]) |

Solbright
|
Posted - 2007.04.06 05:05:00 -
[12]
heh, GOTO on steriods ...
|

Shiraz Merlot
Octavian Vanguard RAZOR Alliance
|
Posted - 2007.04.15 15:01:00 -
[13]
Originally by: Xianthar so what you/we really want is a python interpretor that works with the stackless scheduler to switch microthreads accross multiple CPU's close to as fast as the current stackless python scheduler can on a single cpu.
Yes. And there is a considerable body of work in the HPC world on massively parallel systems already.
Originally by: Xianthar that is a very difficult problem to solve.
A good, small, experienced OS design team would do.
Arguably the x86-64 architecture isn't the right choice, either; the SPARC still excels most at the fast context switch.
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |