• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Management is clearly unconvinced that better performance = PROFIT. It doesn't matter whether any of us think otherwise.

DLCs were announced. Not performance fixes.

I do apologize, I believed you were arguing that it doesn't, not that it does.

I do agree, poor management is to blame for 99.9% of the issues PDX is facing right now, and as the company gets bigger and more known, their internal problems will become more and more apparent to potential customers and employees.

Their business structure sounds much like how telltale games WAS, with overworked employees making lower than industry wages, while working on games that have multiple DLC releases over years, in quick succession, with lots of bugs and issues that are never resolved and a management that treats everyone like garbage.

If they do not change anything, the company doesn't stand a chance to ever being anything other than, "that one company that tried to steal art from microsoft."
 
Last edited:
I do apologize, I believed you were arguing that it doesn't, not that it does.

I do agree, poor management is to blame for 99.9% of the issues PDX is facing right now, and as the company gets bigger and more known, their internal problems will become more and more apparent to potential customers and employees.

Their business structure sounds much like how telltale games WAS, with overworked employees making lower than industry wages, while working on games that have multiple DLC releases over years, in quick succession, with lots of bugs and issues that are never resolved and a management that treats everyone like garbage.

If they do not change anything, the company doesn't stand a chance to ever being anything other than, "that one company that tried to steal art from microsoft."
Cut the all the useless bloat... ( most of those who don't work on game)
Problem fixed.
 
Please remember, that you insisted to be given this explanation.

- I picked the Fibbonacci sequence, because it is a perfect example of being unable to calculate any value without having calcualted every value beforehand. Wich happens to be the exact problem of arriving at any gamestate in any game.

- I excluded storing the sequence, because that is one of those shortcuts games can not take. Because people were actually stupid enough to sugest that "solution" to the stated problem. As if that was somehow magically applying to the game reality.

- I did not expect you to be both
a) smart enough to find another way
b) not smart enough to get my intention. And in fact continuisly not getting it over hours
c) somehow thinking that this would help in any way, shape or form with multitasking a game

I will add this to the list of "stupid solutions" I have to exclude in the future.

Here is a parallel Fibonacci that gives linear increase in speed without any overhead, ie 8 cores are 8 times faster

Code:
int fib(int n) {
  if (n < 2) return n;
  int x = spawn fib(n-1);
  int y = spawn fib(n-2);
  sync;
  return x + y;
}

See https://en.wikipedia.org/wiki/Cilk
 
Please remember, that you insisted to be given this explanation.

- I picked the Fibbonacci sequence, because it is a perfect example of being unable to calculate any value without having calcualted every value beforehand. Wich happens to be the exact problem of arriving at any gamestate in any game.
In that sense it's a rather dissimilar example. Aside from the Fibonacci sequence not requiring to compute preceding values, sequential Fibonacci computation is very "narrow" - its state is just 2 numbers. On the opposite side the game state is "wide". In something like Stellaris it's probably megabytes, so to evolving from game state to another requires a lot of computations that are mostly independent and thus can be done in parallel.

I think your example illustrates the reality of the situation (even if it wasn't your intention) - the game can be very well parallelized and optimized, but that requires some thinking, often up-front and for various reason there are probably many things that are implemented akin to the naive Fibonacci calculations.
 
Fixing performance is not as profitable as making and selling more DLC.

You cannot make PDS allocate more resources to fixing performance.
Selling DLCs might be more profitable in a short term, but poor performance can have effect on the reputation and lead to declining profits in the long term. So business-wise it's unclear what is better. We don't really know if PDS allocated enough resources. It's quite likely that the root problem is not something they can fix easily and might require significant code rework. They may be working on that, but it will take time before we will see the results.
 
I hope you're not expecting logic from Paradox here. The same Paradox that hired another games company (with one game to its name) that openly stole assets from Stellaris, to re-create the same game, only without stealing assets from another IP. The same Paradox that didn't bother to check if they had stolen anything and ended up having to pull the game because, unsurprisingly, Gamebear had stolen assets from a major western company. Luckily for Paradox, their community found it pretty quickly.

So... Expecting logic from Paradox at this point. Not a good idea.
 
Here is a parallel Fibonacci that gives linear increase in speed without any overhead, ie 8 cores are 8 times faster
I envy your optimism :)

Code:
int fib(int n) {
  if (n < 2) return n;
  int x = spawn fib(n-1);
  int y = spawn fib(n-2);
  sync;
  return x + y;
}

See https://en.wikipedia.org/wiki/Cilk
Let's pick a simple example (n=6) and look what will happen. Thread #1 will run, spawn thread #2 for n=5 and process n=4 itself (and only when both n=5 and n=4 are computed it will proceed to compute n=6). Thread #2 will spawn thread #3 to compute n=4 (note that thread #1 is already computing the same - n=4) and proceed computing n=3. In the meantime, thread #1 will spawn thread #4 to compute n=3 (again already being computed) and proceed to n=2. And so on... So the result is that it will be very parallel and will be doing a lot of duplicated work in parallel. That's not even looking at the overhead of parallelizing at such small granularity.

I would guess it will be many times slower than a simple single-threaded loop... That example is on wikipedia to demonstrate how to use CILK - not how to efficiently compute Fibonacci numbers.
 
Selling DLCs might be more profitable in a short term, but poor performance can have effect on the reputation and lead to declining profits in the long term. So business-wise it's unclear what is better. We don't really know if PDS allocated enough resources. It's quite likely that the root problem is not something they can fix easily and might require significant code rework. They may be working on that, but it will take time before we will see the results.

For the managers on the floor as opposed to the executive, what is better is whatever they are incented to do. If their performance (and thus their bonus/raise) is measured by shipping DLC on specific dates then producing and shipping DLC is what will be done. The executive are supposed to take a longer view, but a pernicious issue in public companies is they are incented to increase stock value right now, future be damned.
 
I envy your optimism :)


Let's pick a simple example (n=6) and look what will happen. Thread #1 will run, spawn thread #2 for n=5 and process n=4 itself (and only when both n=5 and n=4 are computed it will proceed to compute n=6). Thread #2 will spawn thread #3 to compute n=4 (note that thread #1 is already computing the same - n=4) and proceed computing n=3. In the meantime, thread #1 will spawn thread #4 to compute n=3 (again already being computed) and proceed to n=2. And so on... So the result is that it will be very parallel and will be doing a lot of duplicated work in parallel. That's not even looking at the overhead of parallelizing at such small granularity.

I would guess it will be many times slower than a simple single-threaded loop... That example is on wikipedia to demonstrate how to use CILK - not how to efficiently compute Fibonacci numbers.

You mistaken, n=6 gets to the first spawn, and continues into it treating it as a normal function call, then continues on in non parallel fashion all the way to n=1. Magic happens on return from spawn. Free cores are able to pickup the code after first spawn from initial thread, and continue execution from y = spawn fib(n-2).

You can download cilk yourself and try running the fib example, it works with a free Visual Studio you can download from Microsoft, obviously it also works with gcc on Linux. its almost linear increase, non cilk straight C version taking 40 seconds, cilk version with one core 41 seconds, cilk version on 8 cores 5.5 seconds.

The key as to why cilk gets this performance, each cilk function is compiled twice with a fast and slow variant, the fast variant is almost equivalent to non-parallel version, with only a few extra assembly instructions after each spawn, checking if code after it was stolen. 99% of the time the code running is the fast vetsion.
 
Last edited:
Cut the all the useless bloat... ( most of those who don't work on game)
Problem fixed.

That isn't the problem, they underpay their staff, so they cannot even get people to fill in positions.

Their profits are more than enough to do so, but they don't see the big picture, eventually they wont even have enough staff for a single game, let alone the multiple they are trying to support currently.

Right now every game has a skeleton staff because of their pay scale and the way they mistreat employees.
 
I would just like to point out, that many things being said in this thread would not fly in the general forum, even a mention of incompetent management typically gets a person banned or put on probation, but not here.
This simply goes to prove what people have been saying, they made this thread so they can ignore the problem.
I doubt any of the games devs even look at this thread.
 
You mistaken, n=6 gets to the first spawn, and continues into it treating it as a normal function call, then continues on in non parallel fashion all the way to n=1. Magic happens on return from spawn. Free cores are able to pickup the code after first spawn from initial thread, and continue execution from y = spawn fib(n-2).

You can download cilk yourself and try running the fib example, it works with a free Visual Studio you can download from Microsoft, obviously it also works with gcc on Linux. its almost linear increase, non cilk straight C version taking 40 seconds, cilk version with one core 41 seconds, cilk version on 8 cores 5.5 seconds.

The key as to why cilk gets this performance, each cilk function is compiled twice with a fast and slow variant, the fast variant is almost equivalent to non-parallel version, with only a few extra assembly instructions after each spawn, checking if code after it was stolen. 99% of the time the code running is the fast vetsion.
It's always useful to do a sanity check, especially when you're seeing timing in seconds. What is a reasonable time to compute a Fibonacci number? I've quickly wrote the code and a serial version computes it in under 200ns. That is 5 million Fibonacci numbers per second. Fib(60) ~= 1.5e+12 and won't fit into integer used in that code. So to compute every Fibonacci number that fits into integer would take approximately 0.012ms. So what exactly that code is spending 40 (or 5.5sec) on? Just in case I've also wrote the linear recurrence version of the code. Of course, in that case, the time to compute the number was increasing for larger n, however for n=60 it's still only 40ns (as a curious observation at n=160 the time to compute via linear recurrence started to exceed the time to compute it directly).

The natural answer is that they came up with this code, so that it parallelizes well and can be used to illustrate usage of CILK. It's not intended to show how to compute Fibonacci numbers
 
That isn't the problem, they underpay their staff, so they cannot even get people to fill in positions.

Their profits are more than enough to do so, but they don't see the big picture, eventually they wont even have enough staff for a single game, let alone the multiple they are trying to support currently.

Right now every game has a skeleton staff because of their pay scale and the way they mistreat employees.

If this is true, that behavor is truly insulting the concept of human intelligence...

By the way, the bloat keep stealing ressources from the usefull part to feed itself like cancers do... So even if I don't want to believe this right away, it makes total sense.
 
Last edited:
If this is true, that behavor is truly insulting the concept of human intelligence...

By the way, the bloat keep stealing ressources from the usefull part to feed itself like cancers do... So even if I don't want to believe this right away, it makes total sense.

Bethesda releases a broken game. Promises to fix it. In the meantime, subscriptions for QoL features that they intentionally stripped out of their game!

Activision lies about lootboxes in their upcoming Modern Warfare game.

A company developing an AI to target whales brags about an individual spending $150,000 on a mobile game.

..Yes. They are insulting the concept of human intelligence. Because people keep throwing money at them.
 
Bethesda releases a broken game. Promises to fix it. In the meantime, subscriptions for QoL features that they intentionally stripped out of their game!

Activision lies about lootboxes in their upcoming Modern Warfare game.

A company developing an AI to target whales brags about an individual spending $150,000 on a mobile game.

..Yes. They are insulting the concept of human intelligence. Because people keep throwing money at them.
lfirUiM.gif

Fuck this shit I'm out...
 
Management is clearly unconvinced that better performance = PROFIT. It doesn't matter whether any of us think otherwise.

DLCs were announced. Not performance fixes.

I completely agree with you and will follow suit with my limited mods and work. The sad part is that not buying the DLC invites more risk to completely cancell all further DLC and patch work since it 'won't be profitable' i.e. becomes a self fulfiling prophecy.

PDX has the money to give to a chinese developer, because building something new is simpler and easier and doing it in china is dirt cheap. All of Riots new games are coded in china, while designers and management are in the US. Remember, this industry is labor intensive.

It goes without saying that this thread is the final graveyard where this discussion will just die. Stellaris: what a waste of potential.
Our only hope is to roll back to older versions and play that game and perhaps revitalize modding for older versions.
 
It goes without saying that this thread is the final graveyard where this discussion will just die. Stellaris: what a waste of potential.
Our only hope is to roll back to older versions and play that game and perhaps revitalize modding for older versions.

There is always the possibility of a rogue engineer saying "sod it" and doing some stuff off-book. I'm not holding out for that, though. (And of course, off-book check-ins tend to piss off project managers. QA probably won't care though.)