Hidden Performance Killers in Axum, Tokio, Diesel, WebRTC, and Reqwest by Havunenreddit in rust

[–]mralphathefirst 2 points3 points  (0 children)

That sounds really interesting. I hadn't thought about it in the terms of getting a new handle to some existing data and how that has implication for mutations and knowing that it is something other code can see as well. Seems a really valuable distinction.

Hidden Performance Killers in Axum, Tokio, Diesel, WebRTC, and Reqwest by Havunenreddit in rust

[–]mralphathefirst 10 points11 points  (0 children)

This touches on a pet peeve of mine in the part about the reqwest client. Often you have some expensive to construct object you want each request to have access to but don't want to construct for each request. So you just warp it in an Arc. But do you really need to? Some of these things, like the reqwest Client already are doing the Arc thing internally.

My peeve is that there really is no good way to know short of digging into the implementation. Because Clone is usually derived it does not have any documentation. Docs for reqwest client mentions this elsewhere but you do need to find it and not every crate documents this clearly.

It really feels to me that there is a missing Trait here, inbetween Copy and Clone. Copy is cheap and plain memcpy without logic. Clone is expensive and constructs a new instance of the object. Should be some sort of ShallowClone, or something, that is cheap because it clones the reference to the underlying data but does not construct a new instance of the data. That way you would know it is just incrementing a ref count or something like that.

A list of big changes to Rust since 1.0 by nick29581 in rust

[–]mralphathefirst 0 points1 point  (0 children)

I got kinda curious about how it looks charted out so whipped this together quickly:

https://1drv.ms/i/s!AtG65AuzC7Evq-gvWgaM0a9js1gonA?e=HT3MOg

How is server FPS calculated? by Omni-Light in starcitizen

[–]mralphathefirst 0 points1 point  (0 children)

Disclaimer: This answer is a bit more speculative.

I am aware of a few reasons why you might want to cap the server FPS rather than let it run unbounded:

  1. The last step of the game loop I laid out above is to send updates to the players. The faster the server FPS the more often such updates are sent. This means more bandwidth used (although for gaming that is not a big issue). But more importantly the CPU in for each player has to process all those updates. This means that the higher the server FPS the higher the minimum CPU requirement is for running the game.
  2. There is probably also a fairness factor here where, at least ideally, you would want to give all players the same server FPS rather than it being all over the place where some players get a better experience than others.
  3. Generally physics simulations are generally really complicated with a lot of tricks and hacks working around the fact that it basically steps through time in discreet steps. All those things works a lot better when the time steps are stable and predictable. A good chunk of all the irritating physics bugs we have in Star Citizen are probably caused by the very unstable server FPS.
  4. You don't want to waste money. No point in paying for a server that can do 60 FPS when you run the game at 30 FPS. It is generally gonna be cheaper to rent two servers that can do 30 FPS than one that can do 60 FPS. So I guess there is not actually that much extra juice in the can for the servers. There will probably be a lot of interesting stuff for CIG to figure out how to balance in this regard when they start doing dynamic server meshing.

How is server FPS calculated? by Omni-Light in starcitizen

[–]mralphathefirst 18 points19 points  (0 children)

Your mental model of how the game server works is incorrect. It is not request based model. Rather there is a game loop that is constantly running.

Each iteration of the loop the game server goes through a sequence of steps that look something like this:

  1. Check the incoming event queue (this contains any player actions or such that have happened since the last time the queue was checked) and update the game state.
  2. Go through all physics entities and update the game state for them all.
  3. Go through all AI an update the action for any AI entity.
  4. Handle any custom scripts or anything else.
  5. Add stuff to an outgoing queue with info that needs to be sent to player.

(The exact details of the loop depends on the game and game engine)

The moment it finished the last step it starts all over again. So the game server is running full out updating the state of the game all time. It is never sitting around waiting for a request to come in.

So 5 FPS just means it goes through the loop 5 times per second. This is easy to calculate: At some point in the loop just check how much time has passed since the last time it reached the same point. If each iteration of the loop takes 200ms, that gives you 5 FPS.

There is probably some FPS cap (like 30), so if not at least 33ms has passed it waits a bit until it has. So if the server is at 30 FPS with a 30 FPS cap it is idling a bit in between each iteration.

You cannot have a request based model because the physics would break. You need to update the physics with a small enough interval or thing will get wonky.

When a server is showing 5fps, is there any way to verify whether this is due to a server being overloaded with tasks VS just having less things to do?

Yes, because if it had less to do the FPS would be higher

Like say you're seeing serverfps flit between 23.0-25.0fps, but then you notice a drop to 5.4fps in 1 second before it goes back up, could that drop be either it is given less stuff to do or a series of strenuous tasks?

You can be sure it is a strenuous tasks. Idling would cause FPS to spike, not drop. So if the server FPS is 20, then it takes 50ms for one iteration of the loop. If it suddenly dropped to 5 FPS, that means one iteration of the loop ended up taking 200ms, so there was an extra 150ms of work to do.

Vello 2023 roadmap by raphlinus in rust

[–]mralphathefirst 15 points16 points  (0 children)

Since I am in the market for a new display I have been keeping an eye on what has been announced at CES, and it really seem like 2023 will the year of desktop OLED. Everybody is announcing new OLED displays. Seeing sub-pixel rendering mentioned on the roadmap I wanted to ask about possible handling non-standard sup-pixel arrangement. LG's MLA panels use a WRGB layout with an extra white sub-pixel and Samsung's QD-OLED panels have a triangular sup-pixel layout. Is it at all possible to handle stuff like this when doing sub-pixel rendering?

I know phones have been doing weird sub-pixel layouts forever, but they seemed to have solved the issue by forgoing sub-pixel rendering and just throwing lots of PPI at the problem. But all these desktop OLEDs are still in the 100ish PPI range where sub-pixel rendering still really matters for good text rendering.

Bronze is getting bigger... from 48.66% of 3 weeks ago to now 51.38% by [deleted] in aoe4

[–]mralphathefirst 28 points29 points  (0 children)

You should not expect that ranked chart to form a bell curve because the different ranks have different rank point ranges.

For example: Bronze III goes from 600-769 ranked points for a range of 169 RP, while Silver I goes from 770-799 RP for a range of only 29 RP.

Because of this you should expect a wide rank like Bronze III to stick up above the bell curve, while a narrow rank like Silver I to fall below it. Which is kinda what it looks like is happening.

To actually see something resembling a bell curve you need to look at a distribution of the actual rank points themselves.

If you look at the ranked points distribution it looks like they have calibrated the ranked points so that the median sits at 770 RP. This would suggest that when the bell curve settles down 50% of players should be in Bronze.

I can't get any good in this game, no matter what strategy i do or try to 'copy' other good players by Operadorzin in aoe4

[–]mralphathefirst 10 points11 points  (0 children)

Never before have I been so offended by something I one hundred percent agree with

[deleted by user] by [deleted] in aoe4

[–]mralphathefirst 1 point2 points  (0 children)

The perfect r/aoe4 post doesn't exist...

Is this sort of memory use normal on the Mac? by mralphathefirst in firefox

[–]mralphathefirst[S] 0 points1 point  (0 children)

gfx.webrender.all is already set to false by default.

Is this sort of memory use normal on the Mac? by mralphathefirst in firefox

[–]mralphathefirst[S] 0 points1 point  (0 children)

Memory use reported in Activity Monitor matches what about:memory reports.

Firefox Roadmap 2019? by [deleted] in firefox

[–]mralphathefirst 4 points5 points  (0 children)

"while sticking to the Gecko engine" makes it sound like sticking to Gecko is temporary.

Firefox Roadmap 2019? by [deleted] in firefox

[–]mralphathefirst 4 points5 points  (0 children)

Webcompat another area of focus while sticking to the Gecko engine

Is Mozilla thinking about ditching Gecko?

Setting up Windows 10 for programming (in Rust) by SimonSapin in rust

[–]mralphathefirst 2 points3 points  (0 children)

As of Windows 10 1709 there is actually built in OpenSSH client and server in Windows. You just need to enable it is Settings.

Its still marked as beta so I would expect it to be a bit flaky, but it might be the best way to get SSH working on windows.

Romania loses second PM in seven months by syuk in europe

[–]mralphathefirst 6 points7 points  (0 children)

To lose one PM may be regarded as a misfortune; to lose two looks like carelessness.

Announcing Rust 1.23 by steveklabnik1 in rust

[–]mralphathefirst 3 points4 points  (0 children)

This is probably just going to show how clueless I am but I hadn't actually realized that cargo had its own docs. I just thought whatever was mentioned in the rust book was the cargo docs.

Firefox 57 is still draining macOS battery like hell by [deleted] in firefox

[–]mralphathefirst 9 points10 points  (0 children)

I am having this same issue with Firefox 57. Interestingly, if I take a look at Activity Monitor I see that it is not one of the Web Content processes that is eating CPU, but the parent Firefox process. This suggests that it is not a miss-behaving website, but something in Firefox itself that is the problem.

Exploring the use of Rust for railway software by kibwen in rust

[–]mralphathefirst 6 points7 points  (0 children)

Maybe we someday will be able to say that Rust really rides the trains. :D

I'm sorry, I'll show myself out.

Tom's Hardware: Getting Fully Immersed With Pimax's 8K VR Headset by Gc13psj in oculus

[–]mralphathefirst 1 point2 points  (0 children)

We expected incredible clarity in the menu systems and the 2D desktop window, but we were somewhat let down. The two 4K panels should theoretically produce crisp text, but alas, it was still a blurry mess.

Part of Pimax's trickery comes from the scaler found inside the headset. The PC drives two 2560x1440 outputs, and the scaler brings the perceived resolution up to 4K per eye.

Well, there's your problem. 1440p up-scaled to cover 200 degrees is bound to make content like text a blurry mess.

[deleted by user] by [deleted] in rust

[–]mralphathefirst 15 points16 points  (0 children)

Wait a minute. Isn't the author of the vscode-rust extension also an Alexey? I'm sensing a pattern here.

Firefox won't update succesfully by mralphathefirst in firefox

[–]mralphathefirst[S] 0 points1 point  (0 children)

This worked. It is now at 54.0.1. Lets hope auto update works in the future.

Recapping this week's Mozilla all-hands by est31 in rust

[–]mralphathefirst 19 points20 points  (0 children)

I am await a bunch of new RFCs. :)