2023 July FBS Update!
Added 2023-07-03 06:08:27 +0000 UTCHello Everyone!
Yet another month has gone by. It seems like the days tick by faster and faster.
Feature Bounty System
This month we raised $500.09. $435.09 on Patreon and $65 from Paypal. We are now at $2590.14 toward our $3500 milestone goal. We increased our contributor count by 31 this month! Welcome to all the new users. We're inching closer and closer to the next milestone.
GearCity
There is not much news on the GearCity side of things. I had a good chat with Serhey about how we'll approach the model animations and the file format for the new vehicle designer system. I'm hoping we can hit the ground running with Milestone #2 and convert the handful of questioners of the new system.
AeroMogul
During the last update, I mentioned several speed improvements and issues. Unfortunately, I caught a few bugs in the system that increased the time processing workload by 40%. I also found a few problems with the 2nd leg flight code. So I had to refactor the 2nd leg code. I worked on more optimizations. Finally, I multithreaded the AI demand data and the passenger calculations. The results are about 7 seconds to cache demand grids for the AI. I only need to do this periodically, and the game can run this function in the background while the player plays. The system finds 30,000 route combos in 11 seconds. I can optimize this more as I implement more rules. Currently, airlines are looking at every combination, for example, international airports flying to foreign regionals. Finally, the passenger processing code does X single leg and Y second leg flights in 8 seconds. While that's more than 1.5 seconds, the multi-leg code works properly now, and it no longer costs much time to create routes. Even better, there is a slight possibility that I could expand this to 3-leg routes. It's much easier to do now, anyway.
I used an AMD Ryzen5 3600 for testing. This CPU was the third most popular used for GearCity last month. I also conducted the test in a Virtualbox virtual machine. So I expect about 10-20% better performance with bare metal use.
Hopefully, in the next 2-5 years, 8 or even 12 cores become the de facto standard. With those processors, the turn times should process even faster.
So that's it for this month's update. I will be working on some AeroMogul client-side code now. I hope to have AI company route visualization and results for the client by the next update. Hopefully, there aren't hiccups that prevent that progress.
Until next time!
Comments
Even new stuff will be around at good prices. Generally, the parts 2 generations behind are heavily discounted periodically. And if a vendor has particularly heavy inventory, they dump the last-generation stuff when the new generation is out. That's how I typically upgrade. But in development, it's a good idea, in my opinion, to use your target system minimum machines to assure it works well on it. Steam Hardware Survey shows a healthy split between 4, 6, and 8 cores machines, 4 and 6 on the decline and 8 and up gaining market share. This has been a trend since the start of the year. If we look back 4 years ago to 2019, 4 cores had over 50% market share, 2 cores 30%, and 6 cores half of what it is today. So it's safe to assume in 4 years, 8 cores will be the baseline standard that 4-cores were a few years ago. But there will be many higher core options considering how the chiplet has taken the industry by storm. As of right now, the game scales appropriately.
Eric Jones
2023-07-17 15:43:16 +0000 UTCBig thannks of course. I will def will not complain about formating when im doing a fairly poor job myself on that. Well im sure that with another year or 2 and new generation, used parts with 10+ cores will be available for a decent price. As long as it can bring time required for those actions down by a decent amount, thats already a really great outlook. Best of luck with this! But for real, the amount of different architectures and os's on the market already seems dizzying enough without even have to work with them myself. I really hope you manage to get some more recognition with this project.
Arunas Chlevickas
2023-07-16 19:37:53 +0000 UTCSorry for the formatting. Patreon's comment section is not good. > Have you tried it on newer gen intel chips with hybrid P/E cores on one die? I have not. Regretfully, I run VENT on a shoestring budget. And that means I've spent less than $300 on computer hardware, peripherals, and furniture per year. I mean heck, my keyboard is older than me. My most costly purchase was hard drives for the internal file server, followed by the Mac Mini only used for Mac ports, and then my Blackberry Passport to answer Q's when I am afk. GC was written on a Phenom 9550 with an AMD HD7770 in Windows XP64 until 2018, when its 3rd motherboard failed. I replaced it with a defective Ryzen5 1600. Last year when I started working on AeroMogul's client, I bit the bullet and bought a newer GPU (RX 6600XT), and I lucked into a new Ryzen5 3600 with a motherboard for $99.99 shortly thereafter. Anyway, I have a couple of Intel devices, but nothing new. I typically only purchase Intels in prebuilt machines. I use AMD for everything else. I would love to have one, though, along with Nvidia/Intel GPUs. If anything, for compatibility testing. But it's just not in the budget. As for the P/E cores, these have been around for a while in RISC CPUs. My Pinebook Pro, which I use to communicate when I am not in the office, has two small and four big cores. It's fairly common with ARM CPUs. I ran AM's server code on it for a few days until the ram constraints became an issue. And if we ever have the option for massive multiplayer, I'll likely rent massive ARM servers with many P/E cores. That said, ARM and Intel are using their E-cores a little differently. Intel overloads its CPUs with them, whereas ARM mainly uses them for idle tasks. I suspect Intel's E-Cores will be better for highly parallel tasks in AM than ARM's. But ARM CPUs are still much smaller, and they can squeeze more of them on a die than Intel or AMD with their chiplet designs. > Windows systems should schedule them by itself but i wonder how would that play into scallability just for the sake of curiosity. You are correct. The OS scheduler is in charge of distributing work to specific threads. So it's really how well the OS designs and optimizes the scheduler. AM's server creates more threads than the CPU can run simultaneously. For example, our networking has long-lived threads for network polling. These threads are used frequently but don't do much work. Nonetheless, we can't lock up the program polling. So these threads should be running on the E-cores. Whereas the P-cores handle the short burst threads and work that can't be paralleled too widely. And then there are what I call "all hands on deck" tasks, like calculating passenger routing. Where all cores get some action, as there is enough work to spread around. The P-cores are likely to finish their tasks before the E-Cores, so the OS should reschedule some work for the P-cores. I say should because I am 15 years removed from OS design, even though that was what I went to college for before I became a financial dropout. Programming wise, it's above my paygrade. I tell the compiler I want to use X amount of cores. It makes the binary requesting X cores. The OS and the CPU are supposed to handle the rest. I can further optimize it specific to the CPU, but the game will run on many different hardwares. > Also, Given all cores are the same, how much threads can it utilise and how much extra time can you even shave off with 4 or 8 extra threads? Sadly, I am limited to 6-cores here. I don't have any computer with more cores. Originally we planned on using the GPU to do a lot of these calculations, but my talks with a couple of publishers for startup funding fell through. So I couldn't hire the GPU Compute Wiz, and I don't have the time or talents to teach myself in a short amount of time. Anyway, I ran a quick benchmark for you: VCPU -- Cache Demand -- Initial AI Routes Creation -- Pax Routing 1vcpu -- 21s -- 12.2s -- 23.1s 4vcpu -- 8s -- 11.7s -- 9.6s 6vcpu --6s -- 11.4s -- 7.4s These are near worse-case scenarios right now. Cache and Initial AI Routes can run in the background while the player does other stuff in game. Pax Routing Happens on the end turn, so the player is sitting around waiting for it. Bare Metal testing in Windows, the Pax Routing is sub 5s. I don't recall the other numbers, but it should be similar percentages from virtual machine overhead. Note this isn't the full rule set, and I haven't purged the airport file of non-viable airports. I suspect the numbers may go down a little especially for route creation. I'll also probably make some datasets with smaller "data grids" to play on lower-end machines. Nonetheless, you can see that both the caching and the pax routing codes scale down with core counts. Edit: Should also add, at 6-cores, I am using full CPU and running Unity Editor, the Game Client, a Browser playing music, the host OS, and the overhead of a virtual machine and the OS running it. So I am leaving a little bit of performance on the table at 6 cores if I had an 8 or more core machine.
Eric Jones
2023-07-16 06:30:17 +0000 UTCSince you mentioned multithread scaling, Have you tried it on newer gen intel chips with hybrid P/E cores on one die? Windows systems should schedule them by itself but i wonder how would that play into scallability just for the sake of curiosity. Also, Given all cores are the same, how much threads can it utilise and how much extra time can you even shave off with 4 or 8 extra threads?
Arunas Chlevickas
2023-07-16 02:13:01 +0000 UTC
