pinteresting

Can you think of a function where the input is valid, the output is NaN and nothing has gone wrong in the process?

I can't think of any, haven't experienced any, not heard of any examples of it, so you're welcome to break my ignorance on the subject.

Generally if you're seeing a NaN/Inf something has gone wrong, It's very difficult to gracefully recover from and if you tried I think you would lose both sanity and performance!

Regarding performance, the cost of a real division is about 3-4 orders worse performance than an if statement that is very consistent, but the usual way is to have fast/safe versions of functions, where you need performance and can deduce if something is always/never true, create/use the fast function but by default everything uses the slower/safer function.

If you know what a compiler will optimise, might optimise and can't optimise, you can get an intuition for what the generated code will be executing, but even ASM is not "full control" and often not super useful because what you think is happening will shuffled around again by the CPU. The execution time for the same asm will vary significantly depending on architecture.

If you have a good mental model of modern CPUs, in a simple loop, you can estimate what you think the bottlneck of the function will be, either by counting the micro ops or the number of stack / heap memory reads or memory allocations, etc, to estimate what is really happening to work out how you can optimise it, otherwise you're just shooting in the dark trying random combinations of flags or code not understanding why something worked or didn't work.

At least in C/C++ that model works.

In slow languages like python/javascript/etc, doing simple operations doesn't translate down to the very low levels at ALL. Generally if you imagine the worst possible way you can think of for how something will execute in a simple loop and multiply it by 10, it might be close.

I guess that's true. Calling an expensive function effectively in the body of a loop like in this example is going to be an issue in every language.

It is difficult to optimise because you need the compiler to evaluate and prove at compile time that both the loop cannot affect the result of the function call and the function call will not affect the loop.

It's a common and easy optimisation to simply move function calls like this out of the loop.

For the cost of 1 line of code I've regularly seen 10%, 100%, 1000% speed ups.

It's actually one of the most common optimisations to do in non-compiled / "slow" languages if you know how functions are evaluated, you see that the cost of a simple getter function call can be the most expensive part of a loop.

In my limited experience I find CSS examples always make things look simple, but then in reality I'm forced to do something stupid like this for a 400px canvas:

            left: 50%;
            margin-left: -205px;
            border: 0px;
            width: 410px;

Because when sized to 400px it always clips 10 pixels of the canvas.

There is more to latency than just the ping to the server.

The raw controller input latency / controller polling rate.

The time it takes for your packet to get to the server.

The number of packets per second you're sending to the serve (e.g. 100pps).

The server processing time per frame.

The server frame rate.

The time it takes for the packet to get back.

The frame rate of the client machine.

Whether Vsync is enabled (more latency).

The time it takes to transfer a frame of rgb data to the monitor.

The monitor frame rate and processing time per frame.

The pixel response time of the pixels on the monitor.

If we're doing cloud gaming. we also need to add latency stages for encoding and decoding video and how long it takes to download each frame of video.

By simulating everything client side you remove a ton of stages in this latency pipeline.

That's not correct. In compiled languages, if for example denominator can be computed at compile time, it will almost certainly be optimized to use tricks, the easiest one is to just convert it to a multiply.

A division instruction can take a variable length of cycles to solve depending on the complexity of the division, it has terrible throughput and can be 100x slower than something like an addition, and that's on modern architectures!

Did you ever notice how a calculator can sometimes take a visible amount of time to compute something, and sometimes it was instant? Some instructions are more expensive than others!

If you could sandbox part of the screen to say this thing is standalone and cannot perform any networking abilities and is cut off from everything else on the page that would be great.

The browser could recognise that tag and you get a safe space for people to copy/paste/interact with online web tools.

I'm pretty sure you can do this with WASM right now, but the browser doesn't inform the user that this is a safe space.

Faster per watt I agree. Per clock, they could be somewhat similar with caveats. Per Core, the clock speeds that can be achieved with intel are much higher (even if it throttles). I think both are good enough for 90% of the population.

I don't see anyone building an external compute/accelerator platform around an ARM Mac ecosystem. It's a niche market as is and the direction has always been to integrate functions like this onto the chip / package directly. I think the latter is certainly an opportunity apple will choose as they will be able to claim their new processors have a special sauce that intel does not have and charge an apple premium for it.

Are you suggesting plugging in a dongle that has a CPU on it? I'm very confused if true. As the bandwidth between RAM and CPU is ~50GB/s, any external dongle would not be able to communicate with the system RAM without a huge slowdown, so the dongle would need it's own RAM too, how this would communicate with a GPU is questionable again and this is already a weird crazy expensive dongle.

I think this is the part that will make 3rd party developers give on on the Mac. Mac ports are given the least love as is, mostly because apple will break your application on such a regular basis it's not worth the cost to port/support, but this change adds so much more burden to the developer, I think most will wait a few years before making a commitment unless apple throws money as them.