When I run a McCLIM application, according to `top' CPU usage is constantly above 95% or so, and the KDE System Monitor reports about 50% for CPU 1. Here is a typical `top' entry when running the CLIM Listener:
top - 09:52:31 up 3 min, 1 user, load average: 0.37, 0.23, 0.10 Tasks: 78 total, 2 running, 76 sleeping, 0 stopped, 0 zombie Cpu(s): 14.3% us, 36.0% sy, 0.0% ni, 49.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2075012k total, 301272k used, 1773740k free, 11244k buffers Swap: 2004420k total, 0k used, 2004420k free, 165556k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2728 paolo 25 0 1284m 37m 45m S 99.9 1.8 0:18.87 cmucl [...]
When only the CMUCL toplevel is running, it is below 1%. Why is CPU usage so high with McCLIM applications? Is it real or some sort of measuring artifact?
I use the latest McCLIM CVS sources with CMUCL Snapshot 2004-12 under Slackware Linux 10.0. My PC is a 2.8 GHz Pentium IV with 2 GB of RAM.
Paolo
Paolo Amoroso writes:
When I run a McCLIM application, according to `top' CPU usage is constantly above 95% or so, and the KDE System Monitor reports about 50% for CPU 1. Here is a typical `top' entry when running the CLIM Listener:
top - 09:52:31 up 3 min, 1 user, load average: 0.37, 0.23, 0.10 Tasks: 78 total, 2 running, 76 sleeping, 0 stopped, 0 zombie Cpu(s): 14.3% us, 36.0% sy, 0.0% ni, 49.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2075012k total, 301272k used, 1773740k free, 11244k buffers Swap: 2004420k total, 0k used, 2004420k free, 165556k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2728 paolo 25 0 1284m 37m 45m S 99.9 1.8 0:18.87 cmucl [...]
When only the CMUCL toplevel is running, it is below 1%. Why is CPU usage so high with McCLIM applications? Is it real or some sort of measuring artifact?
I use the latest McCLIM CVS sources with CMUCL Snapshot 2004-12 under Slackware Linux 10.0. My PC is a 2.8 GHz Pentium IV with 2 GB of RAM.
I think it has to do with CMUCL multi process implementation. I was told that if you start the idle loop, then this problem will go away.
Robert Strandh strandh@labri.fr writes:
Paolo Amoroso writes:
When I run a McCLIM application, according to `top' CPU usage is constantly above 95% or so, and the KDE System Monitor reports about
[...]
I think it has to do with CMUCL multi process implementation. I was told that if you start the idle loop, then this problem will go away.
This works. But the way the idle loop is started in CMUCL makes it difficult to deliver applications.
If I deliver a McCLIM application containing the CMUCL executable, a Lisp image, and a shell script that launches the executable with the image as an argument, the high CPU usage is still there. Since the multiprocessing initialization function does not return, the only way I know of invoking it is calling MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS interactively. But I can not expect users to do that: I would like to hide the Lisp toplevel to them.
It might be possible to change CMUCL so that it always starts the idle loop. If this is not done by default, there may be some stability issues. But this is probably best discussed in the CMUCL mailing list.
Paolo
Paolo Amoroso writes:
I think it has to do with CMUCL multi process implementation. I was told that if you start the idle loop, then this problem will go away.
This works. But the way the idle loop is started in CMUCL makes it difficult to deliver applications.
If I deliver a McCLIM application containing the CMUCL executable, a Lisp image, and a shell script that launches the executable with the image as an argument, the high CPU usage is still there. Since the multiprocessing initialization function does not return, the only way I know of invoking it is calling MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS interactively. But I can not expect users to do that: I would like to hide the Lisp toplevel to them.
I fully agree with you. I kept forgetting to do that so I had processes taking up 100% CPU on some of our servers. I therefore switched to SBCL that does not have this problem.
It might be possible to change CMUCL so that it always starts the idle loop. If this is not done by default, there may be some stability issues. But this is probably best discussed in the CMUCL mailing list.
That or the #lisp IRC channel.
Take care (and happy new year by the way),
Robert Strandh strandh@labri.fr writes:
I fully agree with you. I kept forgetting to do that so I had processes taking up 100% CPU on some of our servers. I therefore switched to SBCL that does not have this problem.
I don't mind SBCL. But, at least for delivery, I prefer CMUCL to extract every bit of additional performance. In the case of a graphical system like McCLIM, this does help.
Paolo
On 3. Jän 2005, at 18:37, Paolo Amoroso wrote:
Robert Strandh strandh@labri.fr writes:
I fully agree with you. I kept forgetting to do that so I had processes taking up 100% CPU on some of our servers. I therefore switched to SBCL that does not have this problem.
I don't mind SBCL. But, at least for delivery, I prefer CMUCL to extract every bit of additional performance. In the case of a graphical system like McCLIM, this does help.
The INSTALL.lisp file has this magic incantation in its #+cmu section that seems to take care of the problem:
(setf mp::*idle-process* mp::*initial-process*)
IIRC I got this from eclipse-the-window-manager, or perhaps from cl-http. Perhaps someone with more cmu-fu than me could comment if this has any side-effects?
Rudi
Rudi Schlatte rudi@constantly.at writes:
The INSTALL.lisp file has this magic incantation in its #+cmu section that seems to take care of the problem:
(setf mp::*idle-process* mp::*initial-process*)
This has apparently not effect: CPU usage is still above 95% with McCLIM.
Paolo
Paolo Amoroso writes:
Robert Strandh strandh@labri.fr writes:
I fully agree with you. I kept forgetting to do that so I had processes taking up 100% CPU on some of our servers. I therefore switched to SBCL that does not have this problem.
I don't mind SBCL. But, at least for delivery, I prefer CMUCL to extract every bit of additional performance. In the case of a graphical system like McCLIM, this does help.
Either way, I am sure the CMUCL maintainers would want McCLIM to run well on CMUCL. It would therefore be a good idea to ask them whether there is something that can be done to fix this problem.
-
Paolo Amoroso -
Robert Strandh -
Rudi Schlatte