open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: CarbonIO and BlueNet: Next Level Network Technology
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 [3] 4

Author Topic

Sister Megarea
Sisters of Agony
Posted - 2011.06.20 22:42:00 - [61]
 

Edited by: Sister Megarea on 20/06/2011 22:42:14
Geek p0rn - SPROING!!!

I'm not a "high level" programmer (Perl/MySQL), but dangit, this is the type of dev blog I really enjoy (Well, this and the ones telling us we're getting free SP ugh)

Tres Farmer
Gallente Federation Intelligence Service
Posted - 2011.06.20 23:03:00 - [62]
 

Just fast in: sweet Dev Blog. Will read once back home in.. phew.. 12+ hours Neutral

Robogod
Vires Quod Iunctum
Posted - 2011.06.20 23:07:00 - [63]
 

Hello, I wondered about this for some time knowing EVE ran on Python. There are ways around that blasted GIL though. They aren't well documented, but I've used them before. Python can be truely multi-threaded. Interestingly with Python's true multi-threads the threads don't even have to be running on the same physical computer. You would have to worry more about asyncronus execution, but it can be done for the rest of the code while still mantaining the ease of use of Python.

Being a programer myself I understand the aim for the higher level Python, but it's not the fastest when clock speeds don't go up, just number of cores. Python can be that "need for speed" though in terms of writing it, and even exicution if you lay down the right framework.

This sounds like a great improvement none the less. Network IO and transfer speeds are a huge impact on performance of clusters and MMOs. Good job!

Elyon Itari
Posted - 2011.06.21 00:22:00 - [64]
 

Edited by: Elyon Itari on 21/06/2011 00:22:29

This - the improvements, as well as the devblogs detailing them - is why we stick with you through outrageous feature claims and horrendous policy changes.

A+

Raid'En
Posted - 2011.06.21 00:57:00 - [65]
 

too much tech for me, the dark side got me and i didn't read it. only looked at the images
well anyway, less lag, right ?

Komen
Gallente
Capital Enrichment Services
Posted - 2011.06.21 01:00:00 - [66]
 

Very impressive. I shall be less upset about the CarbonUI bugs because of this blog. But it doesn't completely make up, and I really, really want to see more bugsquashing going on, because it's completely annoying having my windows jump all over the screen, having my ship start moving when I really did not double-click anything, etc, etc, etc.

Carry on and quick-march.

Chiralos
Merchant Princes
Posted - 2011.06.21 01:13:00 - [67]
 

In the recent video when Torfi said that bit about upgrading the F1 car during the race ... I see what he meant.

Good show.

Dezolf
Minmatar
DAX Action Stance
Posted - 2011.06.21 01:46:00 - [68]
 

Great blog. Only missing one thing; pseudo-code. ;D

I do have a quick question, though. It might come from it being 3:40 am, and me not feeling like googling atm.
With GPU's being used more and more for calculations etc. (and less for "sweet graphics"), Have "you guys" looked into that possibility with some of the things being done server-side?
If so, what were your findings?
If not, why not? (--This, I assume, is because it's either impossible, improbable, or a waste of time)

Also, something else, I assume that, because you release so much data on how EVE is running server-side, it's potentially easier to create "hacks" or similar (since people don't have to guess so much on the structure of the server-side of things), have you considered this?

[Fakeedit:]
Next time I comment on a dev-/techblog, I'll wait 'till I've had a good nights sleep. :P

MotherMoon
Huang Yinglong
Posted - 2011.06.21 02:25:00 - [69]
 

Edited by: MotherMoon on 21/06/2011 02:27:54
I'm just going to link this everytime someday incarnation wasn't a lot of work and It's just "one room"

Thanks for all tour work ccp

Vile Zurk
Posted - 2011.06.21 02:40:00 - [70]
 

You guys tried running your Python code base on PyPy? Its just-in-time compilation can bring surprising performance improvements.

As I don't see CCP porting its Python code base to 3.x soon, PyPy might be the way to go to squeeze more performance (mainly on your game logic servers as I understand it). Plus, using an alternate interpreter is a much less elaborate undertaking than removing Python/PyPy's GIL (as that's what it takes to do true multithreading) or even porting your entire code base to C++ or whatnot.

Internet Knight
The Kobayashi Maru
Posted - 2011.06.21 04:12:00 - [71]
 

Ultimately, CCP has come to realize what I've said all along:

Python sucks, even stackless python.

I don't want to say it, but... I told you so.

ihcn
Posted - 2011.06.21 04:17:00 - [72]
 

Originally by: Internet Knight
Ultimately, CCP has come to realize what I've said all along:

Python sucks, even stackless python.

I don't want to say it, but... I told you so.


we're all impressed at how much smarter you are than the people at ccp. no really.

Kariem Mahkasad
Minmatar
Star Frontiers
Ignore This.
Posted - 2011.06.21 04:58:00 - [73]
 

Thanks CCP for the tech-****. I'm in a Game Development degree and this stuff gets me all jittery and excited for my future in the industry. Keep up the awesome; ignore the whiners, hurdle the dead. Smile

CCP Spitfire


C C P
C C P Alliance
Posted - 2011.06.21 05:37:00 - [74]
 

Originally by: Komen
Very impressive. I shall be less upset about the CarbonUI bugs because of this blog. But it doesn't completely make up, and I really, really want to see more bugsquashing going on, because it's completely annoying having my windows jump all over the screen, having my ship start moving when I really did not double-click anything, etc, etc, etc.

Carry on and quick-march.


Despite sharing a common name, CarbonIO and CarbonUI are developed by two different teams. Smile (not to say that CarbonUI work does not bring performance improvements as far as the game client is concerned).

Gnulpie
Minmatar
Miner Tech
Posted - 2011.06.21 06:07:00 - [75]
 

That is completely awesome! WOOOOOOOOT

But what I don't understand ... you seemed to have invented a way to offload data processing (IO in this case) from the GIL and completely out of the usual Python-processing path, even have the abilitiy to run C++ modules on the fly without involving Python thus harnessing all the available multicore/multiprocessor power available.

Why can't that be done with the modules that handle the space simulation and creates "the lag" in huge fleet battles? Offload the critical parts from Python and the GIL, calculate bits and pieces using multicores/multiprocessors, use a static copy of the battlefield until all calculations are done, upload the result back to Python - just the same way you do it with the IO now?

Or am I missing something here? Are the space simulation modules too complex to be untied from Python and GIL?

Alain Kinsella
Minmatar
Posted - 2011.06.21 10:45:00 - [76]
 

Great read, it reminds me of some software here at work...

Anyway, your post implies that there is now a backend routing network (BlueNet) helping to optimize your network latency. They also appear to have a caching ability for local data, if I've read it correctly.

That brings up a couple interesting questions/suggestions:

1) Have you considered applying redundant connections on the backend, and 'predictive' secondary connections on the client? Example of the second would be to have the client's node pre-connect to the system associated to a gate you're flying to, and begin loading up data ahead of time. This could make the renders more seamless, and the jump lag would be reduced considerably.

2) Does this make it easier to decouple the pure python modules such that they can run in another OS? I can see those parts possibly running better in a more compact space, like the Sparc T2/T3 chips.
[Note this is pure curiosity; I think you're working well on windows boxes - better than I've seen Solaris in some cases.]

Ione Hawke
Posted - 2011.06.21 11:10:00 - [77]
 

Edited by: Ione Hawke on 21/06/2011 11:14:10
Originally by: CCP Curt

CarbonIO was never about reducing load directly, that's a side effect! BlueNet is about reducing serial load, when teams like Gridlock start using it to go-wide on the flying-in-space systems.



Uhu, can you give a time & effort scale when we can expect this to be applied to fleet battles? (as in, 'this is a piece-of-cake now and requires a week of diligent coding and carefull testing and voila', or 'this is a serious effort and requires a complete rewrite of all in space communication code, expect it summer 2013' or ... something in between :))


edit:
bleh, my portrait background is screwed up

VE Vengeance
Posted - 2011.06.21 12:50:00 - [78]
 

Originally by: Alain Kinsella
Great read, it reminds me of some software here at work...

Anyway, your post implies that there is now a backend routing network (BlueNet) helping to optimize your network latency. They also appear to have a caching ability for local data, if I've read it correctly.

That brings up a couple interesting questions/suggestions:

1) Have you considered applying redundant connections on the backend, and 'predictive' secondary connections on the client? Example of the second would be to have the client's node pre-connect to the system associated to a gate you're flying to, and begin loading up data ahead of time. This could make the renders more seamless, and the jump lag would be reduced considerably.

2) Does this make it easier to decouple the pure python modules such that they can run in another OS? I can see those parts possibly running better in a more compact space, like the Sparc T2/T3 chips.
[Note this is pure curiosity; I think you're working well on windows boxes - better than I've seen Solaris in some cases.]


Interessting point. The "prefetching" of near Solar solar systems sound interessting. The question is if the majority of the jump-process is getting information from the new node (the system you are jumping to) or the transport of your data to the new node. The second part would be something like "pre-send", so you send your basic data to the systemnodes of near gates. But I guess it would be complicated because if you pre-send/fetch data they are not accurate at the moment you jump through the gate. Alot of things could happen during warp to the gate :D

Ay Liz
Sacred Templars
RED.OverLord
Posted - 2011.06.21 12:51:00 - [79]
 

Very interesting. I look forward to any improvements Team Gridlock can achieve with this and Time Dilation.

Neolithic Man
Posted - 2011.06.21 12:53:00 - [80]
 

WHOA

Yvan Ratamnim
Posted - 2011.06.21 13:41:00 - [81]
 

Ok so this was all server side carbonio improvements that were astounding, but you say the bluenet things your seeing in testing are ASTONISHING or something of that nature and the tests shown are without bluenet...

what is the delay in releasing bluenet onto TQ? still not finished? is there a timeline on when bluenet will get switched on on TQ?

Consortium Agent
Posted - 2011.06.21 14:06:00 - [82]
 

Very nicely done blog CCP. This is the kind of details we like to see and isn't it great that this doesn't fly over the heads of many of your customers?! :P

I appreciate all the hard work you guys are doing with Eve from a back-end perspective - this sort of development frequently goes unnoticed and you end up with a lot of us asking for more this or more that without heed to the work you've already been doing. We still want more this or more that, of course <g>, but many of us do recognize what you're doing over there and why :)

I also understand the need to unify core code across multiple projects and I'd venture a guess that working with Sony's network for Dust514 may have assisted with understanding how to implement BlueNet?

In any case, I know I've been rough on some of you at CCP lately (and you deserve that) but really... this is awesome work and kudos to CCP developers for putting it together. This is going to make Eve lololfast(er) ;P

LLoyd Thomson
Posted - 2011.06.21 15:23:00 - [83]
 

I understood everything before the first occurrence of GIL.

No, seriously freakin good job. Must have been the hell to introduce

Skogen Gump
The Star Fraction
Posted - 2011.06.21 15:48:00 - [84]
 

Very good write-up but I have a question ?

I was led to believe that Python IO operations were not bound to the GIL:

Originally by: http://wiki.python.org/moin/GlobalInterpreterLock

The GIL is controversial because it prevents multithreaded CPython programs from taking full advantage of multiprocessor systems in certain situations. Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen outside the GIL. Therefore it is only in multithreaded programs that spend a lot of time inside the GIL, interpreting CPython bytecode, that the GIL becomes a bottleneck.



Is this a particular implementation detail of Stackless?

Also, Python 3.2 has re-written the GIL and whilst it's not perfect it certainly sounds better than it did:

Originally by: What's new in Python 3.2

The mechanism for serializing execution of concurrently running Python threads (generally known as the GIL or Global Interpreter Lock) has been rewritten. Among the objectives were more predictable switching intervals and reduced overhead due to lock contention and the number of ensuing system calls. The notion of a “check interval” to allow thread switches has been abandoned and replaced by an absolute duration expressed in seconds. This parameter is tunable through sys.setswitchinterval(). It currently defaults to 5 milliseconds.



Just wondering if you've seen any performance by moving to Stackless 3.2 ?


NoobPwn
Posted - 2011.06.21 16:23:00 - [85]
 

I think this is just an async networking model which has been widely used for about a decade, thing different is that your packet builder & parser is written in Python. You used to call network functions within python interpreter lock, now you access them via a queue and the send/recv process is done in other threads.

Good to know that you made such improvements, but things you really should get done is to get rid of standard Python interpreter once and for all, use something like LLVM to improve actual runtime performance.

Example:
http://code.google.com/p/unladen-swallow/

NoobPwn
Posted - 2011.06.21 16:31:00 - [86]
 

One more thing to say, the current client has issues with its compression library used, zlib 1.2.3 has bugs that can corrupt the heap. I encounter thread safety issues too, blue.dll(your ultimate interface to python objects) is referencing a class being freed elsewhere, crash in blue.BlueWrapper::ConvertBlueToPython call stack shows references from UI.

Kaelarian
Handsome Millionaire Playboys
Posted - 2011.06.21 17:09:00 - [87]
 

So does this mean that it could be possible to implement direct piloting control (e.g. joystick) in the future? The main bottlenecks seem to be the tick rates required for the network IO and Carbon. Depending on the implementation specifics, it seems like the primary remaining obstacle is Carbon.

Levitikon
Constructive Influence
Northern Associates.
Posted - 2011.06.21 17:37:00 - [88]
 

Originally by: CCP Veritas


Originally by: Taedrin
The idea is that an hour of programming time is worth FAR more than a couple CPU cycles. Higher level programming languages are better business than lower level programming languages.


Quoted for truth.



Nope. that's only true when you're writing a new iFart application for iPhone.

For huge, realtime systems with tens, or even hundreds of thousands of concurrent users, systems just like EVE, that few cpu cycles are worth much more than single hour of programmer.

For large enough systems, higher code efficiency is make or die matter. Just ask google, facebook, amazon or paypal.

Besides, with amount they pay you at CCP, it's not that your workhour is worth that much cpu cycles:P

Aineko Macx
Posted - 2011.06.21 17:56:00 - [89]
 

Originally by: CCP Warlock
...

Hello Jacky, I remember our discussion at the dev pub crawl about your research into the GIL problem and possible solutions. Are the improvements mentioned in this devblog the result of this research (i.e. the GIL can't be solved, but can be circumvented), or do you still have something in the cooker?

Isabella Thresher
Fat Kitty Inc.
Posted - 2011.06.21 19:14:00 - [90]
 

good blog, thanks


Pages: 1 2 [3] 4

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only