Re: Performance assistance / advice

Just a few more thoughts on below, not necessarily exactly on topic.

On 11 Mar 2025, at 16:52, Tim Bradshaw (as tfb at tfeb dot org) <[email protected]> wrote:

The answer seems to be: (a) pretty fast, I think, and (b) not fast enough in LW.

Lisp is actually an interesting case when we are talking about performance in the context of dynamically typed languages. It can be argued, that Lisp family of languages belongs to the same group as Javascript and Python, and Lisp is significantly faster than either, from my experience. Given that typically performance of the dynamic languages is such a low bar, people ended comparing Lisps to statically typed languages, possibly even for it just to have some competition, so the discourse ended up as ‘lisp is slow’ even though the comparison turned into apples to oranges.

But even among statically typed languages, like C# and Java, Lisps are sufficiently fast, maybe not necessarily without type optimisations but it is doable. So Lisp is indeed fast, not like handcrafted assembly or C fast, but fast enough in many cases, unless you are very constrained by the compute resources and need to get every percent of performance out.

This can quite easily be parallelised on a shared-memory machine for large particle numbers (it would be harder on a shared-nothing system since you need to copy the particle state everywhere), and it works very well: it gets basically linear speedup up to the number of fast cores on an M1 machine (which I think is 4).

This is correct, there are 4 performance cores and 4 efficiency ones on M1, the efficiency ones are about half the throughput of the performance ones, so you could think of the CPU as having 6 performance cores. This might not work well for this particular task out of the box though as you would have to share the load unevenly among the cores but if you had to, you could balance it out and it should work.

I'm using lparallel: it would be trivial to do the same using LW's native multiprocessing but I wanted something simple & portable between implementations.

I think the multiprocessing libraries for Lisp simply macroexpand their thread abstractions into the underlying Lisp multiprocessing infrastructure, so you are probably using FLI under the hood anyway when testing on LW.

I'm defining 'quick' by just counting float operations in the source (perhaps wrongly) and then computing the total number from that (again, perhaps wrongly).

That is how I do it. I think that is the correct way because you typically have no idea what machine code your script will be compiled to, so counting the operations on the source level removes the underlying platform ambiguities.

One thing I also discovered was that the machine will throttle itself if it gets too hot, so you need to be careful how you measure things.)

This is a fairly well known thing from the early day of the M1 platform and there have been simple DIY solutions to work around that (at least on macbook Air). I tried that and it worked, plenty of guides for this around, this is one is from the top of the search list on youtube, for example:

Fixing Apple's GOOD Engineering - M1 MacBook Air thermal pads

youtu.be

On the other hand I'm not sure how much scientific (as opposed to machine learning) code isn't now vectorised: the last time I was involved with big scientific systems it largely was not, but that was 7 years ago.

Python is often used for numerical computing nowadays (including machine learning), but not in its dynamic form, so to speak, but leveraging foreign libraries, and those do in fact vectorise and GPUise a lot under the hood. Not very sure how it is done in other languages commonly used in academic environment (R, for example) but not vectorising the code is leaving performance on the table these days.

Also need to note that gcc can be quite capable to vectorise scalar C code automatically, surprisingly well sometimes, so even if the scientific computing code is not explicitly vectorised it still is likely to end up as simd optimised after compilation, at least partially.