Hacker News: markstock

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.

New comment by markstock in "Why is Japan still investing in custom floating point accelerators?"

markstock — Mon, 08 Sep 2025 17:59:20 +0000

Something doesn't add up here. The listed peak fp64 performance assumes one fp64 operation per clock per thread, yet there's very little description of how each PE performs 8 flops per cycle, only "threads are paired up such that one can take over processing when another one stalls...", classic latency-hiding. So the performance figures must assume that each PE has either an 8-wide SIMD unit (and 16-wide for fp32) or 8 separately schedulable execution units, neither of which seem likely given the supposed simplicity of the core (or 4 FMA EUs). Am I missing something?

New comment by markstock in "The demo scene is dying, but that's alright"

markstock — Mon, 08 Sep 2025 12:32:05 +0000

Exactly this. Whenever I talk about how I got started in computer art over 40 years ago, I always mention the fact that a screen back then was a one-way device: TV network to you. Basic home computers HAD to plug into the TV, and to a kid, this was magic and freedom.

New comment by markstock in "Show HN: An ncurses CUDA-based fluid simulation"

markstock — Mon, 01 Sep 2025 02:21:57 +0000

Yes, this appears to use Stam's Stable Fluids algorithm. Look for the phrases "semi-Lagrangian advection" and "pressure correction" to see the important functions. The 3d version seems to use trilinear interpolation, which is pretty diffusive.

New comment by markstock in "Google DeepMind team up to solve the Navier-Stokes million-dollar problem"

markstock — Thu, 26 Jun 2025 04:51:24 +0000

Um, no?

This is a fine collection of links - much to learn! - but the connection between flow and gravitation is (in my understanding) limited to both being Green's function solutions of a Poisson problem. https://en.wikipedia.org/wiki/Green%27s_function

There are n-body methods for both (gravitation and Lagrangian vortex particle methods), and I find the similarities and differences of those algorithms quite interesting.

But the Fedi paper misses that key connection: they're simply describing a source/sink in potential flow, not some newly discovered link.

New comment by markstock in "Writing N-body gravity simulations code in Python"

markstock — Tue, 13 May 2025 19:20:16 +0000

It is a fudge if you really are trying to simulate true point masses. Mathematically, it's solving for the force between fuzzy blobs of mass.

New comment by markstock in "Writing N-body gravity simulations code in Python"

markstock — Tue, 13 May 2025 13:49:55 +0000

Supercomputers will simulate trillions of masses. The HACC code, commonly used to verify the performance of these machines, uses a uniform grid (interpolation and a 3D FFT) and local corrections to compute the motion of ~8 trillion bodies.

New comment by markstock in "Writing N-body gravity simulations code in Python"

markstock — Tue, 13 May 2025 13:22:01 +0000

Yes, the author uses a globally-adaptive time stepper, which is only efficient for very small N. There are adaptive time step methods that are local, and those are used for large systems.

If you see bodies flung out after close passes, three solutions are available: reduce the time step, use a higher order time integrator, and (the most common method) add regularization. Regularization (often called "softening") removes the singularity by adding a constant to the squared distance. So 1 over zero becomes one over a small-ish and finite number.

New comment by markstock in "Ask HN: Why hasn’t AMD made a viable CUDA alternative?"

markstock — Wed, 02 Apr 2025 04:05:16 +0000

I can't recommend cards, but you are absolutely correct about porting CUDA to HIP: there was (is?) a hipify program in rocm that does most of the work.

New comment by markstock in "Charlie Javice convicted of defrauding JPMorgan in $175M startup sale"

markstock — Tue, 01 Apr 2025 13:42:35 +0000

The US Treasury has one, though. Not sure if that satisfies the above criteria.

New comment by markstock in "The Lost Art of Logarithms"

markstock — Fri, 14 Mar 2025 13:06:05 +0000

Here's one that starts with the concept of a straight line and builds all the way to string theory. It's a monumental book, and it still challenges me. Roger Penrose's The Road To Reality.

New comment by markstock in "Solarpunk"

markstock — Mon, 03 Mar 2025 01:26:23 +0000

If you love this aesthetic and the concepts beneath it, I highly recommend Paolo Soleri's Arcology: The City in the Image of Man.

New comment by markstock in "Boosting Computational Fluid Dynamics Performance with AMD MI300X"

markstock — Mon, 20 Jan 2025 19:53:44 +0000

I wasn't familiar with the "Wave32" term, but took "RDNA" to mean the smaller wavefront size. I've used both, and wave32 is still quite effective for CFD.