Live data from Hacker News

EVE Online moves to Python 3

eveonline.com

231–237 of 237 posts

Re: EVE Online moves to Python 3

#231

Earlier quoted context omitted.

Rewriting it in Rust isn't automatically faster and more importantly Eve's gameplay is constantly being iterated on and Rust has proven to be bad for that. Moreover, most of Eve's bottleneck isn't single server speed, it's mostly network IO and database queries and latency. The big TiDi skirnishes in particular are slow due to this.

On the iteration: I'm not sure that's the case anymore? Sure new content is added but it's largely within existing systems. The game is closing in on 25 years old at this point. I've no insight into what specifically their bottleneck is. The database doesn't sound like it'd be a factor, though, since the slowdowns are isolated to single nodes handling the area with players and don't effect others.

>The database doesn't sound like it'd be a factor, since the slowdowns are isolated to single nodes handling the area with players

It doesn't sound like it because you haven't been paying attention. By and large, the TiDi slowdowns are because of network IO (i.e. too many players connected to a single node), but the database causes stutters when large numbers of ships are exploded at once.

DB needs to update inventory, skills, implants, and killboards which requires multiple round trips. Moreover, while these round trips to the DB happen, the core processing threads often end up yielding waiting for the SQL Server instance to respond.

But again, I only mentioned it as part of the problem. The core of the issue is definitely Network IO. Someone activates a module or weapon, you need to send that info to 1-10k players as a packet update. That's the source of delays, not processing speed. Rust won't magically speed that up, the network layer is already written in C.

Re: EVE Online moves to Python 3

#233
post #212

Earlier quoted context omitted.

But if you don’t, you don’t use Python anyway

Maybe you have finite time to do the implementation and your task is IO bound? (which is where using async makes sense, by the way)

Lets make a specific example. You have an APIs to services with data that you want to synchronize to a cache in a local database. The providers allows a maximum of 1-3 connections for each api.

You can write this in async with a pool of connections to each provider, or you can have a pool of worker processes that each have one connection to each provider.

Which will be easier to debug, and which design is easier for the next developer to read, understand and modify? Performance wise the wast majority for both designs will be on waiting at the initial connections to the apis and time spent fetching objects.

Re: EVE Online moves to Python 3

#234
And if they'd written in it in Perl 5.8 from 2002, they could stick "use v5.8.0;" at the top of all their files and run it today in Perl 5.42, because the language interpreter maintained backwards compatibility.

You can't run old Python code on modern Python interpreters, and you can't write Python code today knowing whether it'll work in the future. You never know when the Python org is going to change their minds and break something essential to what you're doing today.

Python appears to prioritise supporting code that hasn't been written yet above code that already exists.

Re: EVE Online moves to Python 3

#235

Some basic sample code for stackless python, for those like me who had never heard of it: https://github.com/stackless-dev/stacklessexamples/blob/main... Say "stackless tasklet" five times fast.

the language's main repo [1] has been archived since feb this year.

i wonder when the migration was started and whether it made sense to not migrate it to another framework instead.

[1] https://github.com/stackless-dev/stackless

Re: EVE Online moves to Python 3

#236
post #233
post #212

Earlier quoted context omitted.

Maybe you have finite time to do the implementation and your task is IO bound? (which is where using async makes sense, by the way)

Lets make a specific example. You have an APIs to services with data that you want to synchronize to a cache in a local database. The providers allows a maximum of 1-3 connections for each api. You can write this in async with a pool of connections to each provider, or you can have a pool of worker processes that each have one connection to each provider. Which will be easier to debug, and which design is easier for…

Now let's change the example but bump the limit to 3000 connections.

Re: EVE Online moves to Python 3

#237
post #236
post #233

Earlier quoted context omitted.

Lets make a specific example. You have an APIs to services with data that you want to synchronize to a cache in a local database. The providers allows a maximum of 1-3 connections for each api. You can write this in async with a pool of connections to each provider, or you can have a pool of worker processes that each have one connection to each provider. Which will be easier to debug, and which design is easier for…

Now let's change the example but bump the limit to 3000 connections.

And if the there were 3000, 30000 or 300000 providers the problem would be different. The example I gave was one where I have considered async but went with multiprocessing, which is also why I asked the parent commenter above if they found any direct benefit to readability or debugging when going async.

It would be interesting to hear what kind of domain are you working in where you have 3000 simulations connections to different service providers.

Post reply on HN