How Fast Is Go? Simulating Particles on a Smart TV

>Note that the best-case scenario is the elimination of the overheads above to 0, which is at most ~10% in these particular benchmarks. Thus, it's helpful to consider the proportion of GC overhead eliminated relative to that 10% (so, 7% reduction means 70% GC overhead reduction).

Wow. amazing to see of off-heap allocation can be that good

https://go.googlesource.com/proposal/+/refs/heads/master/des...

Let's bear in mind that Australians call their best friends Good Cunts, and try to take it the best possible way :D I don't even disagree with him, it's just too easy to do better.

The friction/damping term you've added is absolutely necessary to counteract the systematic energy gain from Euler integration, and with better integration, you need less / no unphysical damping, leading to more of that delicious chaotic behaviour we're all looking for.

You can even cheese this with infinite amount of computation if you wanted to do it braindead style (which is still super instructive!), by just repeating the step function with a scaled-down dt until the position components agree to within some tolerance.

The rest is an incredibly deep rabbithole, which I've been enjoying since decades :D

If you're doing semi-implicit Euler that's pretty good, per gaffer's article, semi-implicit Euler has the advantage of being symplectic, i.e. its an integration method that conserves the total energy of the system you are simulating (energy conservation! physicists love it!).

the particle motion in your videos looks reasonably natural, there's no obvious signs of particles seemingly gaining energy from nothing (apart from when they are perturbed by the mouse cursor), so as the resulting motion looks natural, what you are doing is fine and there's no actual problem you need to solve.

if instead of simulating independent particles you were trying to accurately simulate cloth or a deformable rigid body e.g. a metallic object crashing into something, where each node in your cloth / rigid body was a particle tethered to its neighbours, that might be a whole different can of worms and justify looking into RK4 or implicit Euler where you need to solve a big linear system of equations each timestep. but you're not doing that, so no need to overcomplicate things!

I did and don’t understand why the title is “simulating particles on a smart TV” if that is not what it is doing.

Yeah, that would also help with when the image is static with no interactions.

> and compute cost

It'd definitely be tricky to get the computational performance that you'd want out of it. I'd imagine it'd be pretty easy to accidentally bust caches.

To solve for that, you could double your frame size and store the prev/next in an alternating fashion. IE [n, p, n, p, n, p] That way when you xor you are always working with highly local memory sets. You'd want to keep the frame basically global to avoid allocating.

If you wanted to be super clever then you could probably SIMD this up doing something like [n, n, n, n, p, p, p, p]. I'm not sure how you'd turn that into RLE in SIMD. I'm not clever enough for that :D (but I'm sure someone has done it).

But as you said, complexity would definitely increase rather than decrease even though you could get much better compute time.

Every DataFrame library with a significant user base uses function chaining because that's the best workflow for such stuff. Also notebook support / magic cell comments for iterative EDA.

Python: polars-py, pandas, pySpark JVM: Spark R: R

Go can't compete with this even with SIMD support.