microprocessor-trend-data
nomad-driver-nspawn
Our great sponsors
| microprocessor-trend-data | nomad-driver-nspawn | |
|---|---|---|
| 5 | 1 | |
| 463 | 50 | |
| - | - | |
| 1.8 | 4.8 | |
| about 2 years ago | 10 days ago | |
| Gnuplot | Go | |
| GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
microprocessor-trend-data
- DCS Newsletter - DCS 2.8 Multithreading | SATAL 2023
-
Semiconductor Engineering: "Chip Design Shifts As Fundamental Laws Run Out Of Steam"
And the creator of that graph has updated it: https://github.com/karlrupp/microprocessor-trend-data
-
Is it realistic at this time in the near future (aka within 5-10 years) that we could see 1000 players in a single match of Fortnite or Battlefield? What is holding this back? People's machines or the infrastructure of most countries?
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.
-
We Don’t Use Docker (We Don’t Need It)
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...
nomad-driver-nspawn
-
We Don’t Use Docker (We Don’t Need It)
> Now imagine if only you could schedule to run systemd units using Nomad
With some tweaks to your unit files this is actually possible. Nomad has the concept of custom task drivers you can implement to make it schedule any kind of workload you like. I am maintaining a task driver which allows you to run systemd-nspawn containers with Nomad [1].
Using this task driver you can deploy your systemd units running inside a systemd-nspawn container into a Nomad cluster. If this sounds interesting to you I have written a how-to blog-post about this [2]
[1]: https://github.com/JanMa/nomad-driver-nspawn
What are some alternatives?
parsemail - Hanami fork of https://github.com/DusanKasan/parsemail
s6-overlay - s6 overlay for containers (includes execline, s6-linux-utils & a custom init)
caxa - 📦 Package Node.js applications into executable binaries 📦
litestream - Streaming replication for SQLite.
bocker - Docker implemented in around 100 lines of bash
fleet