Originally by: Bartholomeus Crane

---

I happen to know a lot about this subject. It is my job, and for my work at university, where I do research into distributed virtual worlds/simulations I can tell you the following:

It is not stackless python that's the bottleneck. It is the fact that a single grid is maintained on one node, with only partial distribution for sub-tasks.

In such a case there is a limit to the number of tasks that can be handled by that node in a certain timespan. In other words, there will always be a point where more ships will always mean lower performance until it all stops. The huge fights CCP talks about simply can not be supported by this kind of architecture and any widening of the computational bandwidth will simply mean that the limit will be moved upward to be eventually filled there. In this is basically what's happened now.

For those that expect a solution, there are two types but you're not going to like them or what I have to say about them:
1. A change in game mechanics that applies pressure on players to keep the numbers on the grid small. In other words, some kind of stacking penalty, or, heaven forbid, some sort of arena idea (I hate it already).
2. Doing more tasks from one grid on other nodes in the cluster. Now, before you start shouting, think about that for a while, because it inevitably (there's only so much you can portion off afterall) means partitioning the grid, some players on this node, others on another, etc. This, and I've worked on this a lot, is very, very difficult to achieve in a virtual world where distributed data consistency is paramount. Without relaxing distributed data consistency at least to some degree, I don't see how CCP can seriously promise to do this one the hardware they now have to get to computational bandwidth they need to keep the promises they are making. To do this in the degree that I think is necessary, the latest low-latency connectionist architecture would be required. That should make effective distributed handling of a grid possible with a bandwidth suitable for the immediate, maybe even intermediate future. There is, afterall, on so much you can do with software, and since CCP have always kept mum about what they do in software, keeping in mind that this is such a deal-breaker for the business model, I have to assume that they are really pushing the envelope of what is possible within this architecture.

There were rumours CCP was thinking of buying hardware like that a year or so ago, but realistically, if they have done so then, it would realistically take two years or more to develop a stable system of production quality on it, not mentioning the fact that most of this hardware is still fairly experimental. In the meantime, there is only so much CCP can really do and I'm quite worried they've basically run out of options really.

But really, Python has little or anything to do with it, especially with all the modification CCP has made to it, specifically for running EVE. The problem is both fundamentally hard to solve and a workable solution requires top of the line and thus very expensive, and still experimental hardware.

You may now return to your regularly scheduled whining. Film at 11.

---