Hacker News: markstock

New comment by markstock in "Neo Radar: A browser-based orbital mechanics engine with 41k real asteroids"

markstock — Thu, 23 Jul 2026 01:48:54 +0000

Please don't call this "full N-body dynamics" if only the outer planets are involved in the integration.

New comment by markstock in "85.3 GFlops: Optimizing FP32 Matrix Multiplication on a Single AMD Zen 3 Core"

markstock — Tue, 21 Jul 2026 13:18:59 +0000

My go-to rule that's held since 2008 has been that a GPU can do about 10x the math that a similarly-priced CPU running properly optimized code can.

My 5070Ti can realize about 20 TF/s while a 12-core Zen5 can do 2.

New comment by markstock in "Do we just want slaves?"

markstock — Tue, 21 Jul 2026 12:43:32 +0000

There have been polls. The AI hate thing is almost exclusively a USA thing.

New comment by markstock in "Getting Creative with Perlin Noise Fields"

markstock — Tue, 16 Jun 2026 13:35:22 +0000

Generative artist here: the beautiful thing about this exploration is that these techniques can be applied to ANY vector field, whether they originate in random noise or global simulations.

The reason these add so much visual interest to a simple noise function is that each pixels color now relies on many more of the random values. Generative art blossoms with this extra computational effort.

New comment by markstock in "Navier-Stokes fluid simulation explained with Godot game engine"

markstock — Fri, 05 Jun 2026 03:14:10 +0000

Yes, I do 4th order interpolation (M4') on the GPU. This paper is for 3rd order, though, but the methods may extend.

I suppose because the fetches are generally to similar memory regions, there may not be a substantial performance improvement due to L1 and L2 hits on recent GPUs.

New comment by markstock in "Navier-Stokes fluid simulation explained with Godot game engine"

markstock — Fri, 05 Jun 2026 02:43:45 +0000

I should add that this is a major "tell" for detecting when an app uses the Stable Fluids method: obvious mass loss (and very viscous, energy-dissipating flow).

New comment by markstock in "WSL 2 is getting faster Windows file system access"

markstock — Fri, 05 Jun 2026 02:35:45 +0000

People who run WSL are not normal users. The filesystem problems make Windows+WSL feel like a Trabant when you're used to a Porsche.

New comment by markstock in "WSL 2 is getting faster Windows file system access"

markstock — Fri, 05 Jun 2026 02:33:08 +0000

Because Windows is the operating system of Not Getting Fired. Fear is a stronger motivator than creativity or productivity.

New comment by markstock in "WSL 2 is getting faster Windows file system access"

markstock — Fri, 05 Jun 2026 02:29:25 +0000

On the other side, I am a lifelong Linux user, and even with advanced LLMs, trying to get Microsoft Windows to behave sanely takes hours every month for years on end (thanks, day job). Things Linux figured out in 2003 are still magic or completely undoable on Windows.

New comment by markstock in "Navier-Stokes fluid simulation explained with Godot game engine"

markstock — Sat, 30 May 2026 17:07:00 +0000

Before you go adding vorticity confinement, consider performing a higher-order backward advection scheme (Runge-Kutta 2nd or similar), and using a higher-order interpolation method (triangle-shaped cloud instead of bilinear).

In my implementations I use 4th order for both and vortices stick around a lot longer.

New comment by markstock in "Navier-Stokes fluid simulation explained with Godot game engine"

markstock — Sat, 30 May 2026 17:03:39 +0000

You are correct: Stable Fluids extends to 3d relatively easily.

New comment by markstock in "Navier-Stokes fluid simulation explained with Godot game engine"

markstock — Sat, 30 May 2026 17:02:24 +0000

One of the nice aspects of Stable Fluids is that you don't need to iterate the pressure correction terms to convergence. Just run a fixed number of Jacobi or Gauss-Seidel sweeps and keep performance consistent. The only drawback of this is some mass loss in areas, which for the present purposes is acceptable.

New comment by markstock in "Some Unusual Trees"

markstock — Sat, 04 Apr 2026 20:01:32 +0000

Then you want Foundations of Multidimensional and Metric Data Structures by Samet. Unless you already have it, then enjoy some pretty (organic) trees.

New comment by markstock in "Functional Flocking Quadtree in ClojureScript"

markstock — Tue, 23 Dec 2025 15:14:20 +0000

Sure, I usually measure performance of methods like these in terms of FLOP/s; getting 50-65% of theoretical peak FLOP/s for any given CPU or GPU hardware is close to ideal.

New comment by markstock in "Functional Flocking Quadtree in ClojureScript"

markstock — Mon, 22 Dec 2025 14:50:45 +0000

Quadtrees and octrees are themselves quite deep research areas. If the acceleration data structures interest you, I highly recommend Hanan Samet's book "Foundations of Multidimensional and Metric Data Structures". It's from 2006, but is basically the bible for the field.

New comment by markstock in "Functional Flocking Quadtree in ClojureScript"

markstock — Mon, 22 Dec 2025 14:47:43 +0000

Note that even without an acceleration structure ("direct summation" in N-body research terminology), a CUDA program or GLSL shader program can exceed 60 fps with 10,000 to 20,000 particles. And a parallel, C/C++/fortran vectorized CPU code can do the same with over 5 thousand.

New comment by markstock in "Functional Flocking Quadtree in ClojureScript"

markstock — Mon, 22 Dec 2025 14:45:18 +0000

The general algorithm used here (of computing attraction and repulsion forces between pairs of particles) is very similar to that used in simulations of many interesting phenomena in physics. Start with Smoothed Particle Hydrodynamics (https://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamic...) and then check out Lagrangian Vortex Particle Methods and other N-Body problems (https://en.wikipedia.org/wiki/N-body_problem).

And the algorithms to solve these quickly is another deep area of research.

New comment by markstock in "Functional Flocking Quadtree in ClojureScript"

markstock — Mon, 22 Dec 2025 14:40:20 +0000

Thank you - I was just about to point out some of that.

The reason that the flocks are tight is because the separation "force" is normally computed as a repulsion between a target boid and all other nearby boids individually, not vs. the center of mass of all nearby boids.

New comment by markstock in "Cities obey the laws of living things"

markstock — Tue, 09 Sep 2025 22:13:27 +0000

Just a few volumes from my bookshelf related to this:

Network Analysis in Geography, Haggett and Chorley

Cities and Complexity, Batty

Urban Grids, Busquets et al

New comment by markstock in "Cities obey the laws of living things"

markstock — Tue, 09 Sep 2025 22:07:34 +0000

Let's be a little more clear: these are not "laws" as much as they are scaling relationships, this is not "new math" (see Ziph and others), and central planning has always had an impact on city development. Nevertheless, I appreciate this line of inquiry.