microprocessor-trend-data VS fleet

And the creator of that graph has updated it: https://github.com/karlrupp/microprocessor-trend-data

I'm not familiar with how Battlefield servers are run, but I’m going to assume they are single-core processes. That’s what most game servers I’m familiar are, anyways. Two of the most important attributes of a CPU are its clock rate (the number of clock cycles per second, which is a measurement of how quickly one core can execute instructions) and its thread count (i.e. how many different processes can be executing on the CPU at the exact same time). Over the past decade, CPUs haven't gotten much faster in terms of clock rate. Instead, they've been optimized to add more cores, so that the CPU can do more tasks at once. This means that game servers haven’t been able to fully enjoy most of the improvements to CPU performance over the past decade. More on this here. This isn’t to say single core processes have been completely left behind – advances in instruction-level parallelism such as AVX 512 can certainly benefit game servers if they are leveraged correctly.

Hard to say it's still "exponential"...what do you think the current constant doubling period is now?

Here's the single thread raw data from that repo. If you take into account clock speed increase (which, as you agree, have plateaued) we're looking at maybe a 2x increase in instructions per clock for conventional int (not vectorized) workloads.

Is there even another 2x IPC increase possible? At any time scale?

https://github.com/karlrupp/microprocessor-trend-data/blob/m...

Docker didn’t have a default way to run on multiple hosts, and so in the wake of docker’s explosive adoption there was a rush of different solutions offered for scheduling containers across a fleet. One of the first well-adopted solutions was actually called fleet - it was part of CoreOS, whose team went on to be very influential throughout the container revolution. This was in the systemd era, and was basically seen as a multi-host systemd. It was very cool and it worked great!

Figure out how to revive https://github.com/coreos/fleet as something native in systemd?

I guess what in trying to say is k8s is systemd distributed but more then. I see how in line fleet and systemd is though https://github.com/coreos/fleet/blob/master/Documentation/fleet-k8s-compared.md

What you describe is essentially the original CoreOS fleet[0] project. It's distributed systemd init files.

[0] https://github.com/coreos/fleet#fleet---a-distributed-init-s...

I find it ironic half of k8s mojo, etcd, came out of this project as well.