Performance assistance / advice

Following some recent discussions (some on reddit which I still occasionally look at) I thought I would write a program to see how fast I can make Lisp for numeric code without explicitly vectorising or GPUising things.  I confess I'm doing it mostly as a distraction from the ongoing end of the world.

My vague aim is, if it actually turns out to be fast, is to may be submit something to one of the Lisp conferences saying 'here, Lisp is not, in fact, slow'.

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

I wrote some code which, very naïvely, evolves a system of gravitating particles. 'Very naively' means: calculate the accelerations of each particle based on all the other particles and then step positions and velocities.  This is quadratic in particle number and not how people integrate things like models of galaxies, but I don't care: I just wanted a well-defined algorithm.

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).  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.

The code is almost all portable and I've tried it in SBCL and LW.  SBCL is very quick, LW is somewhat slower but respectable.  It took me a long time to realise that LW *really* wants safety off if you want fast code (in the early history of it I did this but then I forgot and left the control variable set the wrong way).

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).  I'm sure a real person would look at actual operations in the assembly. On an M1 macbook air, partitioned 4 ways and with 4 workers I get

SBCL, unsafe: 	2.7E10 FLOPS
SBCL, safe: 	2.3E10 FLOPS
LW, unsafe:	1.9E10 FLOPS
LW, safe:	1.2E9 FLOPS

It's interesting that turning off safety on LW makes more than a ten fold difference for code like this: I was surprised by that.  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.)

I'm not sure if these rates are plausible or not: I think they probably are: The M1 seems to be clocked at 3.2GHz and assuming 4 cores the SBCL unsafe rate is 2.1 FLOP/cycle/core which, given it's a superscalar processor, is plausible.

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.

I'd quite like someone else to look at it to see

- where / if I've made mistakes;
- am I counting operations properly;
- what I could to to make LW quicker, if anything.

I'd also like opinions on whether the FLOPS I'm calculating actually are reasonable.

If anyone is interested please get in touch with me *off-list*, please.

But before you do: You will need to have quite recent versions of a bunch of my infrastructure code (more recent versions than are in Quicklisp I think): the whole thing is very much written in a language which is built on CL rather than in CL, and which has no documentation (things like the looping constructs do, but the macros which mediate particle access don't).  And of course it's never been compiled or run by anyone not me, so although it (now) tries to be at least a little less dependent on being me, it may not be.

--tim

PS since I wrote this LW 8.1 has come out: I don't have that yet, so the above numbers are still for 8.0.1


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html