Originally by: CCP Lingorm

---

OK some general points again.

Multiple Cores/multi threading can not solve all the problems.

Do you really want a multi-threaded combat engine? Your using a more complex setup than me and your hit/damage calculations take longer to perform, than mine on a simpler setup, but because of multi-threading mine are threaded out and complete first so my damage is applied to you first, even though when you damage calculations are completed it turns out I am dead .... not really the situation we want.

There are some things we can do about this using wait locks so that we gather up all the damage/hit calculations to be processed in a time slice, the process then waits for all the responses to come back and then continues to do the linear processing of all the results, so we spread out the processing load to multi-thread the bits that can be parallel processed. But this would have to be tested to the nth degree to make sure that the timeslice size is correct and multithreading and wait process works. And to be honest I would not like to start this with the combat engine .... something a bit less complex would be nicer and safer. Say the physics engine.

This is something we are looking into, but as you can understand it is not as easy as chucking in a couple of thread calls and recompiling.

I am hoping to have some nice news on this front soon (or getting the actual dev's involved in this work to write a blog).

---

Originally by: Fabrezio

---

...hire a consultant, someone with a PhD. This would solve many of your problems faster than having your engineers search in the dark like blind moles.

---

Originally by: Fabrezio

---

A couple of things:
1) We are talking about fractions of a second faster, not minutes, hours or days. As long as both are applied it doesn't matter the order. Furthermore, the limiting factor would be the cycle of the weapon and not the complexity of the calculation (as one is 4 orders of magnitude longer).

2) This demonstrates a general ignorance about multi-threading and parallelizing in general, which is disappointing.

3) You can break the problem down and apply something similar to tomasulo's algorithm:

Algorithm

More importantly, the concept of a re-order buffer:

ROB

What does this all mean? You transformed the problem (there really isn't a problem, but if they want strict control over when damage is applied, this would do it) from something that requires locks up the wahzoo into a very simple producer / consumer model, which is well understood.

---

Originally by: Lord Fitz

---

Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

---

Originally by: Roguehalo

---

Can you nano Titans?

---

Originally by: Nova Fox

---

Why not C#?

---

Originally by: Semkhet

---

If you allocate resources per system, you cannot preempt overload conditions since you act AFTER a player appears in a context. If you allocate resources first to each player and then modulate these resources according to the context and actual load (space or docked, and amount of people in system), you can design a naturally adaptive load balancing mechanism. You can preempt load conditions since the server knows where a given player wants to jump BEFORE executing said jump.

...

Hence there should be a master clock linked to a variable amount of temporary slave clocks created within these interactive contexts (let's say one slave clock per grid), and these slave clocks should be allowed to slightly alter their frequency according to load conditions in order to evenly spread latency among ALL actors.

---

Originally by: Kaeten

---

ccp need more hamsters...
yea they definitely need more hamsters..

---

Originally by: Lowa

---

Edited by: Lowa on 21/07/2008 16:01:10

This is a nice thread, there has been many like them but this one is good. And make me happy in pants. :)

Question: What is the top 3 most "resource" taking elements in a fight?
- Loading grid?
- 4000 drones buzzing about?
- Damage calculations?
- Profit?

As I did see some discussion on damage I go out on a limb and guess that doing damage calulations
is a pretty tough job for the CPU/software? In regards to that, and sorry if it has been asked/answered before;
- Would it help if damage was done at "set levels" based on skill, distance, weapon/ammo type etc?
Example;
- 425mm Rail Gun II
- Level 5 on all relevant gunnery skills
- Level 5 on ship skill
- No damage mods

Damage @ 0km to 50km range = 225HP using Antimatter
Damage @ 150km to 200km range = 115HP using Spike

- 10 more damage / damage mod

At a certain distance using certain skills, guns and ammo you would do 225HP damage. Not 223.3 or 34.1 or...
Then no calculations would need to be done that are based on speed, angle, fall-off etc.

PLEASE NOTE THAT I SEE MANY MANY MANY FLAWS IN MY OWN ARGUMENTS HERE!

I think what I'm trying to say is; can it exist a way to reduce the number of calculations needed
in battle without screwing up years of shield/armor resistance training? (not to mention the Nano lovers)
And even IF that was the case, would we as the players accept that for working, large scale battles?


Again, thanks for this thread, keep it going!


/Lowa

---

Originally by: Beltantis Torrence

---

Edited by: Beltantis Torrence on 14/07/2008 18:46:10

Originally by: Nova Fox

---

Why not C#?

---

For absolute speed C/C++ wins. C# is better than Python however, but I doubt the backend is written in Python (or at least I hope it isn't). Compiler optimizations are huge when it comes to sheer computational power. You want tail end recursion unraveled and inlined and as far as I know Python just isn't capable of doing that in the binary sense due to its interpreted model.

I think part of the issue with players making recommendations is that we don't know enough about the backend systems to make recommendations.

For instance, in terms of multithreaded order of execution issues mentioned earlier in this thread (time slices/sync objects verse FIFO), I have to question why a lot of these calculations are being done at all. So I mean my first instinct would be to take a look at the setup and see how much memory I had to work with (or RAM disks or what have you for ultra-fast caching) and then figure out at what point I could take computations entirely out of the equation with a large indexed pre-calculated table. Since Eve uses % and high precision for a lot of its calculations this becomes a battle of how much accuracy you'd lose by pre-calcing assuming you couldn't store every possible permutation. If that accuracy would fall under the realm of noticable in gameplay then you'd remove the computation altogether and you'd have fast IO responsible instead. Ideally you'd want to put all load on an equal distribution basis and do FIFO so you could eliminate as many sync objects as possible (as they act more or less like traffic signals for the data).

However, I couldn't make that recommendation short of throwing blind guess without understanding better what the load issue is. Might be nice if there was some sort of mechanism that'd allow us to understand and make intelligent suggestions without being burdensome for the dev team at CCP.

Edited to add shameless plug - I'm a partner in a consulting firm which, amongst other things, ports systems into cloud computing scenarios and does performance optimizations. Just incase CCP is interested in outsourcing some of the analytical pieces ;).

---

Originally by: bloomich

---

Hi,

Just a firendly question. Not a technical one on purpose. All I was going to ask was...

Roughly, how long do you estimate it might be before a solution to reducing or eliminating fleet lag is implemented?

I understand predicting the future is impossible, sometimes what might be 6 months away might actually be 2 years away. However, I am thinking that fleet lag might be sorted in around 2-3 years time.

---

Originally by: Napro

---

Originally by: Beltantis Torrence

---

Edited by: Beltantis Torrence on 14/07/2008 18:46:10

Originally by: Nova Fox

---

Why not C#?

---

For absolute speed C/C++ wins. C# is better than Python however, but I doubt the backend is written in Python (or at least I hope it isn't). Compiler optimizations are huge when it comes to sheer computational power. You want tail end recursion unraveled and inlined and as far as I know Python just isn't capable of doing that in the binary sense due to its interpreted model.

I think part of the issue with players making recommendations is that we don't know enough about the backend systems to make recommendations.

For instance, in terms of multithreaded order of execution issues mentioned earlier in this thread (time slices/sync objects verse FIFO), I have to question why a lot of these calculations are being done at all. So I mean my first instinct would be to take a look at the setup and see how much memory I had to work with (or RAM disks or what have you for ultra-fast caching) and then figure out at what point I could take computations entirely out of the equation with a large indexed pre-calculated table. Since Eve uses % and high precision for a lot of its calculations this becomes a battle of how much accuracy you'd lose by pre-calcing assuming you couldn't store every possible permutation. If that accuracy would fall under the realm of noticable in gameplay then you'd remove the computation altogether and you'd have fast IO responsible instead. Ideally you'd want to put all load on an equal distribution basis and do FIFO so you could eliminate as many sync objects as possible (as they act more or less like traffic signals for the data).

However, I couldn't make that recommendation short of throwing blind guess without understanding better what the load issue is. Might be nice if there was some sort of mechanism that'd allow us to understand and make intelligent suggestions without being burdensome for the dev team at CCP.

Edited to add shameless plug - I'm a partner in a consulting firm which, amongst other things, ports systems into cloud computing scenarios and does performance optimizations. Just incase CCP is interested in outsourcing some of the analytical pieces ;).

---

CCP Needs to hire this guy

---

Originally by: Lowa

---

Question: What is the top 3 most "resource" taking elements in a fight?
- Loading grid?
- 4000 drones buzzing about?
- Damage calculations?
- Profit?

As I did see some discussion on damage I go out on a limb and guess that doing damage calulations
is a pretty tough job for the CPU/software? In regards to that, and sorry if it has been asked/answered before;
- Would it help if damage was done at "set levels" based on skill, distance, weapon/ammo type etc?

---

Originally by: Locke DieDrake

---

I don't know the exact specs on the EVE blades, but I'm guessing they are pushing 5k FLOPS each.

---

Originally by: Eri Chell

---

So basically (only read like the first page) all this is, is new "bridges" between the differnt nodes in the cluster? Or is this a "bridge" between the CPU and HDs? Or both?

---

Originally by: Ishina Fel

---

Stream processing, so writes wikipedia, is a form of parallel processing that eschews "allocation, synchronization, or communication" between the processing units.

---

Originally by: Reptzo

---

That being said, I know that many things do not port well to video card stream processing.

---

Originally by: Reptzo

---

Nvidia and ATI are still battling for who will be the preferred GPGPU platform, along with Intel making an appearance in 2 to 3 years with their own CPU/GPU chip. While these systems may create huge performance gains, going to them may prove fatal in the long long. Until these systems are more widely accepted and established, one of the three companies could change their efforts, cancel their stream processing lines, or any number of things that happens to bleeding edge technology.

---

Originally by: Kazuo Ishiguro

---

Groups of solar systems are run on nodes (i.e. individual CPU cores). Each of these nodes has to be in constant communication with lots of other nodes, as people move around from one to another; it's not like rendering an image, a task which can be split into independent pieces that can all be worked on simultaneously. Also, we're not yet at the stage, afaik, where a single stream processor is more capable than the best available CPU core.

---

Originally by: Kazuo Ishiguro

---

I'm not sure whether the current bottleneck is in the process for generating the sets of combat calculations, or the calculations themselves. If it's the latter, I suppose it might be possible to farm them out to stream processors, and then back again, once infiniband is in place. i.e.

A tries to fire on B
...
Node receives command
CPU sends calculation request to stream proc
Result comes back
CPU propagates result to A & B

Of course, it might be that except in very big battles, this is a lot slower than doing everything on the CPU alone, because of the two extra transmissions.

---

Originally by: Lord Fitz

---

Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.

---