totm aug 2023 What funny/interesting thing happened in your life today?

[AlamoVampire]

Coyotes are getting bolder in my area thanks to needles construction. Im used to seeing 1 or 2 at a time in my neighborhood but a few minutes ago i saw a pack 8-10 deep of em. Looked healthy and well fed but it worries me nonetheless. Neighbor hood has families that have outdoor dogs/cats. 011801192025 new page!

Edited January 19 by AlamoVampire

[SunlitZelkova]

13 hours ago, AlamoVampire said:

Coyotes are getting bolder in my area thanks to needles construction. Im used to seeing 1 or 2 at a time in my neighborhood but a few minutes ago i saw a pack 8-10 deep of em. Looked healthy and well fed but it worries me nonetheless. Neighbor hood has families that have outdoor dogs/cats. 011801192025 new page!

I’ve seen one or two coyotes in my neighborhood on and off for at least five years, but on account of it literally being on the border between suburbia and farmland, with a large forest to the north, rather than construction.

In most of my sightings they cross the street late at night, once I encountered one on the other side of a pond while out on a walk. We observed each other in stillness before I turned around and went back the way I came. I like going close to animals on the assumption there’s no harm in it but at that time I had no idea what the ROE with coyotes was. I’m quite lucky it didn’t get bad because the coyote was in a position where he/she would have had nowhere to escape had I approached.

They aren’t really a bother from what I can tell, but I do feel bad for the people who have outdoor cats (my sister’s friend being one of them).

[AlamoVampire]

I just learned that mickey mouses ears are spherical. No matter what angle you view them from in the animations they are circles. The only way this is possible is if they are spheres. Google mickey mouse. 221101242025

[Ultimate Steve]

Today, I spent all day optimizing the wrong thing!

So I've been working on a multiplayer game in Python (visuals using Pygame) as an opportunity to learn stuff I haven't really had to learn thus far. This game involves an n-body integrator. It also involves separate "server" and "client" threads which share data over the network, and the host of the game will run both of them on the same machine (this has been the only configuration for testing thus far) and the players will run just the client (once I get around to actually testing with 2 connected machines).

A minor focus early in development was trying to optimize the integrator to see how high of an "n" I could get. Python isn't exactly the most performant language, and the n body problem isn't known for scaling up pretty well. So I really didn't find it at all alarming when I got extremely low frames per second at an "n" of 200.

Today I decided I was unsatisfied with that and I decided to rewrite the integrator with vectorization in hopes that it would improve performance. After I finished, I saw no perceptible difference in performance, much to my annoyance.

That did get me more closely looking at all of the planets flying around, and they appeared to jitter. Sure enough, after running some performance tests, there were a few sections of the integrator that usually ran well but sometimes took 100x as long to run as usual.

After way too long trying to figure out if there was something going wrong with my vector math or my list-matrix conversion, I learned that Python's "threading" library doesn't actually utilize multiple CPU cores like I thought it did. So sometimes the threads were stepping over each other in some very big ways as I had not done any time management/prioritization at all. The integrator didn't take that long to run, it started running, got interrupted for 20-80ms by the client, and then finished running.

So I disabled the client for the time being to focus on optimizing the server, and voila! Instead of a tickrate so slow I could count each individual tick, I was getting an average of 164 ticks per second!

But the print statements were visibly coming in way too slow for it to actually be 164 ticks per second (printing every tenth or hundredth tick I don't remember, but it was easy to tell). (note: I have not redone collision detection yet so this is not a perfect comparison)

The only part of that loop that was not inside the performance timer was the part responsible for serializing the data and sending it to the network.

So I ran the benchmarks, stared in disbelief, added some more prints because surely it couldn't be that bad, and - 

Jsonpickle (the library I am using for arbitrary serialization) was taking 50 milliseconds to serialize ~1700 bytes of data into a packet 133 kilobytes in size.

All of that dramatic slowdown at higher planet counts? That wasn't the n body integrator choking due to nonlinear scaling (ok maybe it was with the earlier non vectorized version, I haven't actually tested it), that was the array of objects containing all of the planet data getting linearly bigger, taking longer to serialize. It looks like I'll need a new serializer. I used jsonpickle because it handles literally anything you throw at it (in this case a list of custom objects with a lot of attributes of various types, in addition to some other minor data) and only needs one line of code on each end. If there's not another drop in replacement that can also handle all of that, with that simplicity of use, but significantly faster, I'll probably need to do all of that myself.

On one hand, yay! I found the problems! On the other hand, I spent all day optimizing something that didn't need it, all of the threading stuff will need a serious rethink, and I might have to get to write my own serializer.

 

Edit: Upon closer inspection, each individual planet is at least 85 bytes by itself, and all 200 would be 17,000 bytes. I am not sure why Python is reporting the size of the planets array as 1600 bytes. So I apologize for the jsonpickle size slander. It is more of a factor of 8 size increase (likely less because overhead) than a factor of 80 increase. The factor of 8 might just be partially due to going to a string. So throwing that much data around might actually be expected.

So now I have two jobs, firstly, make my own (likely binary and not string based) serializer and deserializer, as jsonpickle's time (if not size) is still atrocious and I'm nearly certain I can do better in that regard. Secondly, figure out how to send less data per frame as to not max out slower internet connections. I have some ideas:

1. The client might not actually need all of the data (though if I rip it out, it will be more difficult to put it back in if it turns out I need it later once I add actual features and actual gameplay)
2. The client definitely doesn't need all of the data every frame (currently I'm sending the color, radius, mass, and name 60 times per second, those don't change often). I could just send the important data (velocity, position) and then update the rest of it when it changes (hard) or just update 1% of the worlds each frame (easier but less good).
3. The client really doesn't need that much precision as the server handles all of the math. 8 bytes each for x/y position/velocity adds up especially when I start adding non planet objects like ships, projectiles, etc. The server will still do the math with 64 bit floats (that might not be strictly necessary but I don't want to deal with making sure all of the math libraries accept the other non standard floats), but the results may be transmitted as a smaller (4 byte? 3 byte?), less precise data value for display to the players, converted back to float on the other end for ease of use. Easily cuts packet size in at least half.

Edited 6 hours ago by Ultimate Steve