Re: LW compiler optimizations

I actually just did invent a separate thread to hold onto the WITH-SLEEP-DISABLED. But it isn’t a wasted thread.

Using Actors you can spawn a new thread and have it ASK for something - in this case an answer, after which the thread just exits.

But, unlike conventional thread programming, this new thread is actually useful - it becomes another message dispatch thread until an answer arrives later as a result of a :KILL message to the idler Actor. In the meantime, it is usefully dispatching messages to any other Actors in the system.

;; ----------------------------------------------------

(defun idler-beh (&optional cust)
  (alambda
   ((:kill)
    (become (idler-beh self))
    (send cust :ok))
   ((acust :hold)
    (become (idler-beh acust)))
   ))

(deflex* idler (create (idler-beh)))

(defun make-idler ()
  (mp:process-run-function "No-Sleep" ()
                           (lambda ()
                             (with-sleep-disabled
                                 (ask idler :hold)))
                           ))


> On Jan 15, 2025, at 11:40, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> 
> 
> 
>> On Jan 15, 2025, at 11:04, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
>> 
>>> My best Lisp timing was about 1.1 ns/MAC pair on AMD, versus 1.4 μs/MAC pair on M1.  That shows the two machines to be competitive. These numbers are close enough, in my mind, to consider them equal. Variations in cache configurations, background task loads, etc, might well make a ±20% variation in timings on any one machine. But my timings also indicate a realistic performance in live settings.
>> 
>> The measurements seem high for M1, I was consistently getting below 1ns timings per pair in Bradshaw’s code.
>> 
> 
> I tried several different possible looping constructs. DO was just as bad as LOOP. My best times so far come from DOTIMES. But this probably has a lot to do with what state the compiler reaches in my code versus Tims.
> 
> A seeming small change in Lisp structure can make a big change to overall timings. And while I used to be able to glance at a C expression and see mentally exactly what instructions would be issued, today’s processors are much more complex. And Lisp is even more removed from that level. Someone like Martin might be able to visualize the instructions issued from a Lisp expression, but I certainly cannot.
> 
> My biggest challenge is in getting a ton of compute work done in the time it takes for one sample buffer to fill. Sure you can stretch beyond with multiple-buffering, momentarily. But you have to catch up, or else eventual underflow will result.
> 
> I keep a watch on missed samples whenever I ask for another buffer. Underneath, at the C level, there is a ring of 4 buffers to be filled. Usually I see my *AUDIO-SLIP-COUNT* at 0. But lately, after prolonged data collection runs, over the course of hours, I see it showing 4096 samples. That translates to about 0.5s slip. I am still puzzling over that.
> 
> I think the slips may be happening as the processor tries to power down to idle. I used to have an intervention to prevent idling, but that requires a dedicated thread. And now that I’m fully Actor centric, I no longer have any dedicated threads for anything other than message dispatch duties. So I need to invent a do-nothing thread to just hold onto the WITH-SLEEP-DISABLED.
>