Re: Performance assistance / advice
"Tim Bradshaw (as tfb at tfeb dot org)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
As a distant followup to this: C seems to win, by a depressingly large margin. I gave up and wrote a naive single-threaded C version of the Lisp code (so it just does everything in one big chunk rather than partitioning the arrays). It may still be wrong but it conserves energy and you can watch gravitational and kinetic energy being exchanged in the way you'd expect (it's gravitationally unbound, so the KE declines and gravitational energy increases as it flies apart) as the system evolves. So using a single M1 core it is about as fast as the best CL version using 4 cores. This is also borne out by the overall execution time: the C version, with one thread, will evolve a system the same size for the same number of steps as the Lisp one, with four threads. Assuming my counts are correct (and assuming a clock of 3.2GHz) this means that the Lisp one is retiring about two operations per core per clock and the C one about eight. I believe (based on random people writing this who seem to know what they're about, there is of course no useful information from Apple) that an M1 fast core has 4 floating point execution units. So that looks implausible at first blush: that's 2 ops / fp execution unit / clock. I think the answer is a combination of the float execution units being able to retire more than one instruction / cycle, instruction fusion (the C compiler certainly is generatin fused multiply-adds, but I also believe that the M1 can dynamically fuse instructions which appear as separate instructions in the code). Or perhaps I am just not counting correctly. The tiny bit of good news is that this is nothing to do with 'Lisp is slow': the Lisp code is not slower because 'it's Lisp': there's no runtime type checking, no GC, none of the other things which can actually make code slower in dynamic languages. Rather it is slower because the compiler is not generating such aggressive floating-point code. Which given the disparity in effort between clang and any Lisp compiler is ... not surprising. --tim I will be mostly away for a week and probably will not see replies until I get back. _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html