[Openmcl-devel] native threads

Tim McNerney mc at media.mit.edu
Fri Jan 5 10:32:01 PST 2024


This is one of the deviant and brilliant features of CCL: "look ma, no 
interpreter." Every other Lisp has to fastidiously maintain equivalent 
semantics between *eval* and the compiler.  This was more of a burden 
when not-yet-standardized Lisp semantics were a moving target, like 
around when lexical closures were introduced. Before CCL there was Coral 
Software's ObjectLogo, which used the same strategy.  The trick there 
was to present to the Logo REPL /user/, the /appearance/ that their code 
was interpreted (in the grand tradition of Logos not having a 
compiler).  For example, when an error was recognized at compile-time, 
the error /message/ was reported at run time.

On 1/5/24 1:15 PM, Tim Bradshaw wrote:
> I didn't know that: thanks.
>
> However in this case it looks mostly like the SBCL GC is doing better: 
> CCL is spending 85% of the time in GC, SBCL somewhat less (about 65%).
>
> I am trying to think of a case where a microbenchmark like this tells 
> you anything useful about real programs.  But I can't.
>
> --tim
>
>> On 5 Jan 2024, at 17:55, Ron Garret <ron at flownet.com> wrote:
>>
>>  CCL compiles everything.  The SBCL compiler is just better.
>>
>>> On Jan 5, 2024, at 9:11 AM, Tim Bradshaw <tfb at tfeb.org> wrote:
>>>
>>> You realise that SBCL is almost certainly compiling this and CCL is 
>>> almost certainly not?
>>>
>>> --tim
>>>
>>>> On 5 Jan 2024, at 14:29, Taoufik Dachraoui 
>>>> <dachraoui.taoufik at gmail.com> wrote:
>>>>
>>>> 
>>>> It looks like it is not because of the threads:
>>>>
>>>> taoufik at Ankbot:~/workspace/ccl/actor$ sbcl
>>>> This is SBCL 2.3.11, an implementation of ANSI Common Lisp.
>>>> More information about SBCL is available at <http://www.sbcl.org/>.
>>>>
>>>> SBCL is free software, provided as is, with absolutely no warranty.
>>>> It is mostly in the public domain; some portions are provided under
>>>> BSD-style licenses.  See the CREDITS and COPYING files in the
>>>> distribution for more information.
>>>> * (time (reduce #'+ (loop for i from 0 upto 100000000 collect i)))
>>>> Evaluation took:
>>>>   1.836 seconds of real time
>>>>   1.835223 seconds of total run time (1.351394 user, 0.483829 system)
>>>>   [ Real times consist of 1.184 seconds GC time, and 0.652 seconds 
>>>> non-GC time. ]
>>>>   [ Run times consist of 1.184 seconds GC time, and 0.652 seconds 
>>>> non-GC time. ]
>>>>   99.95% CPU
>>>>   3,876,850,246 processor cycles
>>>>   1,600,427,200 bytes consed
>>>>
>>>> 5000000050000000
>>>> * taoufik at Ankbot:~/workspace/ccl/actor$ ccl
>>>> Clozure Common Lisp Version 1.12.1 (v1.12.1-22-g6b1f1d3a) LinuxX8664
>>>>
>>>> For more information about CCL, please see http://ccl.clozure.com.
>>>>
>>>> CCL is free software.  It is distributed under the terms of the Apache
>>>> Licence, Version 2.0.
>>>> ? (time (reduce #'+ (loop for i from 0 upto 100000000 collect i)))
>>>> (REDUCE #'+ (LOOP FOR I FROM 0 UPTO 100000000 COLLECT I))
>>>> took 13,091,079 microseconds (13.091079 seconds) to run.
>>>>      11,036,666 microseconds (11.036666 seconds, 84.31%) of which 
>>>> was spent in GC.
>>>> During that period, and with 24 available CPU cores,
>>>>      12,734,283 microseconds (12.734283 seconds) were spent in user 
>>>> mode
>>>>         336,005 microseconds ( 0.336005 seconds) were spent in 
>>>> system mode
>>>>  1,600,000,032 bytes of memory allocated.
>>>>  397,400 minor page faults, 0 major page faults, 0 swaps.
>>>> 5000000050000000
>>>> ?
>>>>
>>>> On Fri, Jan 5, 2024 at 3:10 PM Taoufik Dachraoui 
>>>> <dachraoui.taoufik at gmail.com> wrote:
>>>>
>>>>     Hi
>>>>
>>>>     In my current implementation of a classical actor model
>>>>     I found that using ccl processes is much slower than sbcl threads
>>>>
>>>>     to create a thread I use ccl:process-run-function, is there
>>>>     another way to
>>>>     create native threads that are much faster; I do not need the
>>>>     ccl scheduling,
>>>>     I want to create threads that are scheduled by the OS, I think
>>>>     that the ccl
>>>>     scheduler is the reason why my ccl tests are much slower than
>>>>     the tests run
>>>>     with sbcl
>>>>
>>>>     Regards
>>>>     -- 
>>>>     Taoufik Dachraoui
>>>>
>>>>
>>>>
>>>> -- 
>>>> Taoufik Dachraoui
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20240105/5efed383/attachment-0001.htm>


More information about the Openmcl-devel mailing list