Hello Everybody, I am using Franz Allegro Common Lisp version 5.0 and every time i execute my program it saturate my processor to 100% and i can't use any other software at that time. Does anybody have any idea how to low the use of processor and let him use instead the percentage of processor that i determine in advance, i'm using now Windows 2000 and i try it before on Windows NT 4.0 and it's the same. i tried also in the process administration of windows to determine the priority of lisp and to reduce it to the low.
On Mon, 22 May 2000 15:11:49 +0200, "Patrick Jarjoui"
<patrick.jarj...@insa-rouen.fr> wrote: >Hello Everybody, > I am using Franz Allegro Common Lisp version 5.0 and every time >i execute my program it saturate my processor to 100% and i can't use any >other >software at that time. Does anybody have any idea how to low the use >of processor and let him use instead the percentage of processor that i >determine in advance, i'm using now Windows 2000 and i try it before on >Windows NT 4.0 and it's the same. i tried also in the process administration >of windows to determine the priority of lisp and to reduce it to the low.
There's an api for that (setthreadpriority or something similar). Take a look at msdn.
//----------------------------------------------- // Fernando Rodriguez Romero // // frr at mindless dot com //------------------------------------------------
> On Mon, 22 May 2000 15:11:49 +0200, "Patrick Jarjoui" > <patrick.jarj...@insa-rouen.fr> wrote:
> >Hello Everybody, > > I am using Franz Allegro Common Lisp version 5.0 and every time > >i execute my program it saturate my processor to 100% and i can't use any > >other > >software at that time. Does anybody have any idea how to low the use > >of processor and let him use instead the percentage of processor that i > >determine in advance, i'm using now Windows 2000 and i try it before on > >Windows NT 4.0 and it's the same. i tried also in the process administration > >of windows to determine the priority of lisp and to reduce it to the low.
> There's an api for that (setthreadpriority or something similar). > Take a look at msdn.
SetThreadPriority sets the priority of the thread relatively to the process priority. if you want to change the priority class of a whole process you should rather use SetPriorityClass.
> Hello Everybody, > I am using Franz Allegro Common Lisp version 5.0 and every time > i execute my program it saturate my processor to 100% and i can't use any > other > software at that time. Does anybody have any idea how to low the use > of processor and let him use instead the percentage of processor
AllegroCL is not doing this. I can pretty much guarantee this as we use it all the time on NT and in very heavy thread mode and this is never an issue. The single best way to fix this is to determine where your program has an infinite loop in it and fix that.
/Jon
-- Jon Anthony Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari
> > Hello Everybody, > > I am using Franz Allegro Common Lisp version 5.0 and every time > > i execute my program it saturate my processor to 100% and i can't use any > > other > > software at that time. Does anybody have any idea how to low the use > > of processor and let him use instead the percentage of processor
> AllegroCL is not doing this. I can pretty much guarantee this as we use > it > all the time on NT and in very heavy thread mode and this is never an > issue. > The single best way to fix this is to determine where your program has > an > infinite loop in it and fix that.
> /Jon
> -- > Jon Anthony > Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383 > "Nightmares - Ha! The way my life's been going lately, > Who'd notice?" -- Londo Mollari
> okay. here's the deal. NT is not the greatest thing in the world > about managing processes. In fact, just yesterday I was compiling a > huge system on NT with ACL, and even though the computer is pretty > powerful, it comes to a halt.
> My guess is not that it's a processor issue, but a memory issue. > Depending on what you're running (or compiling), you may simply be > using up one of the computer's vital resources (i.e. memory) and so > it's hard for other processes to really be effective.
> I've never tried to re-prioritize processes on NT. On UNIX it's > pretty simple (i.e. with the `nice' and `renice' commands). I'd look > around for a utility, as one might exist. I just don't think it'll > have much to do with Allegro CL.
"Patrick Jarjoui" <patrick.jarj...@insa-rouen.fr> wrote: >Hello, > But i have only one processor on my computer and i have >no infinite loop.
You could try to modify the "performance boost for the foreground application" property (see Control Panel|System|Performance) . However I am afraid the WIndows NT processes scheduler is not very clever at detecting processes that are (too) greedy for CPU time. -- Francis Leboutte f...@algo.be www.algo.be +32-(0)4.388.39.19
* Patrick Jarjoui wrote: > Well i'm using a 524 MB for Memory on a Pentium II > 450 MHZ isn't that enough to execute a simulation built in > CLOS on FRANZ Allegro COMMON LISP?
Do you have enough memory? It's much more likely to be memory starved than processor-time starved.
My experience (from Unix) is that on a modern CPU (probably anything faster than 100MHz? maybe slower than that as well), that the OS can schedule computationally-intensive processes with little noticeable impact on the responsiveness of the machine to user input (obviously asking it to do things that take significant CPU time takes longer, but typing at something or general GUI stuff is not noticeably impacted).
For instance I'm typing this at a machine which has two Lisps both executing (loop while t), and getting about 95% cpu between them. I'm not noticing any impact except that when emacs GCs it takes a little time. Someone else is also typing stuff at an emacs on the machine.
I'd expect that NT should be pretty much as good as Unix is in this respect (windows 9x will be worse, its process management seems to be pretty deficient). Perhaps it's spectacularly worse in some way, but I'd doubt it -- process scheduling is not exactly new technology.
*However* if whatever you are doing uses enough virtual memory that it drives the machine into significant paging, then you *definitely* will notice it becoming slow. So I'd look hard at the amount of virtual memory you're using.
* "Patrick Jarjoui" <patrick.jarj...@insa-rouen.fr> | Well i'm using a 524 MB for Memory on a Pentium II 450 MHZ isn't | that enough to execute a simulation built in CLOS on FRANZ Allegro | COMMON LISP?
Yes, it is. Does that make you think it could be your own code?
#:erik -- If this is not what you expected, please alter your expectations.
Tim Bradshaw <t...@cley.com> wrote: >* Patrick Jarjoui wrote: >> Well i'm using a 524 MB for Memory on a Pentium II >> 450 MHZ isn't that enough to execute a simulation built in >> CLOS on FRANZ Allegro COMMON LISP?
>Do you have enough memory? It's much more likely to be memory starved >than processor-time starved.
>My experience (from Unix) is that on a modern CPU (probably anything >faster than 100MHz? maybe slower than that as well), that the OS can >schedule computationally-intensive processes with little noticeable >impact on the responsiveness of the machine to user input (obviously >asking it to do things that take significant CPU time takes longer, >but typing at something or general GUI stuff is not noticeably >impacted).
It is also what I remember from my (short) experience with a ACL on SUN machine.
>For instance I'm typing this at a machine which has two Lisps both >executing (loop while t), and getting about 95% cpu between them. I'm >not noticing any impact except that when emacs GCs it takes a little >time. Someone else is also typing stuff at an emacs on the machine.
>I'd expect that NT should be pretty much as good as Unix is in this >respect (windows 9x will be worse, its process management seems to be >pretty deficient). Perhaps it's spectacularly worse in some way, but >I'd doubt it -- process scheduling is not exactly new technology.
Yes. But with ACL on NT , instead of (loop while t) you would have to do
(loop while t do (process-pending-events))
to get some acceptable responsiveness from the applications (ACL included).
>*However* if whatever you are doing uses enough virtual memory that it >drives the machine into significant paging, then you *definitely* will >notice it becoming slow. So I'd look hard at the amount of virtual >memory you're using.
>--tim
-- Francis Leboutte f...@algo.be www.algo.be +32-(0)4.388.39.19
* Francis Leboutte wrote: > Yes. > But with ACL on NT , instead of (loop while t) you would have to do > (loop while t > do > (process-pending-events)) > to get some acceptable responsiveness from the applications (ACL included).
What? Are you saying that a process on NT can simply block other processes from running without (very) special privileges? That seems extraordinary to me.
> > Yes. > > But with ACL on NT , instead of (loop while t) you would have to do
> > (loop while t > > do > > (process-pending-events))
> > to get some acceptable responsiveness from the applications (ACL included).
> What? Are you saying that a process on NT can simply block other > processes from running without (very) special privileges? That seems > extraordinary to me.
I tried (loop while t) on a machine I have handy, and got good response from other programs. The listener I did the loop in, OTOH, didn't respond at all, so I had to kill it. NT4.0, I believe, Harlequin LispWorks 4.1.0, Pentium III 500MHz, not sure about memory.
Martin -- "Plus I remember being impressed with Ada because you could write an infinite loop without a faked up condition. The idea being that in Ada the typical infinite loop would normally be terminated by detonation." -Larry Wall
> Hello, > But i have only one processor on my computer and i have > no infinite loop.
> Patrick
> i have no infinite loop.
Obviously you do have an infinite loop, otherwise the Lisp process would not be taking up all the CPU. Since this is not an intrinsic problem with ACL, there must be something in your application doing this (or NT has gone wacko, which is also highly likely). A rather less likely (but still possible) situation is that something in your application is breaking ACL so that it then goes into an infinite loop. If you have any FF code in your app, this may be a primary possibility.
/Jon
-- Jon Anthony Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari
> * Patrick Jarjoui wrote: > > Well i'm using a 524 MB for Memory on a Pentium II > > 450 MHZ isn't that enough to execute a simulation built in > > CLOS on FRANZ Allegro COMMON LISP?
> Do you have enough memory? It's much more likely to be memory starved > than processor-time starved.
This can definitely cause NT to flake out.
> For instance I'm typing this at a machine which has two Lisps both > executing (loop while t), and getting about 95% cpu between them. I'm > not noticing any impact except that when emacs GCs it takes a little > time. Someone else is also typing stuff at an emacs on the machine.
> I'd expect that NT should be pretty much as good as Unix is in this > respect (windows 9x will be worse, its process management seems to be > pretty deficient). Perhaps it's spectacularly worse in some way, but > I'd doubt it -- process scheduling is not exactly new technology.
While this is a completely reasonable expectation, NT is actually very bad at this once it gets loaded. It becomes unusable if there is a lot of processing and RAM is short. Even so, you need to have something taking up all the CPU (_typically_ an infinite loop), which may well be the base bug which is only presenting itself by killing NT.
/Jon
-- Jon Anthony Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari
okay. here's the deal. NT is not the greatest thing in the world about managing processes. In fact, just yesterday I was compiling a huge system on NT with ACL, and even though the computer is pretty powerful, it comes to a halt.
My guess is not that it's a processor issue, but a memory issue. Depending on what you're running (or compiling), you may simply be using up one of the computer's vital resources (i.e. memory) and so it's hard for other processes to really be effective.
I've never tried to re-prioritize processes on NT. On UNIX it's pretty simple (i.e. with the `nice' and `renice' commands). I'd look around for a utility, as one might exist. I just don't think it'll have much to do with Allegro CL.
Tim Bradshaw <t...@cley.com> wrote: >* Francis Leboutte wrote:
>> Yes. >> But with ACL on NT , instead of (loop while t) you would have to do
>> (loop while t >> do >> (process-pending-events))
>> to get some acceptable responsiveness from the applications (ACL included).
>What? Are you saying that a process on NT can simply block other >processes from running without (very) special privileges? That seems >extraordinary to me.
Well it's not uncommon for Microsoft to make extraordinary things. I vaguely remember having red that an application has to be programmed "correctly" for the NT (win95 ?) scheduler makes its job appropriately (has to respect some rules which maybe ACL doesn't).
I am not too surprised by what is related by Patrick Jarjoui. Usually when I recompile an application (ACL/NT) , I take advantage of this to make some phone calls or play with my dog - which is fine for me ; for example opening a new message window in Eudora takes about 5 seconds at that time. It is why I said that the NT scheduler is not very clever about "too" greedy processes.
>--tim
-- Francis Leboutte f...@algo.be www.algo.be +32-(0)4.388.39.19
Hello everybody, there's no infinite loopthat's for sure i check it out only loop with a specific condition but as i'm programming an object oriented package designated for simulation it creates a huge number of object so it execute garbage collector 20 times before the processor go down and it didn't even attend the half (228 MB) of full memory wich i increase it 524 MB. So i'm thinking if i reduce the percentage of using the processor from 100% to for example 70% so the PC won't go down and it'll use the rest of the memory instead to complete his work, or else in my case you must reboot your Windows system cause your pc is dead. I try it on a small number of objects and it works so the problem is in lisp itself or in windows and that is for sure or you must change your processor to a higher on your PC and we don't have that much money to do that.
Thanks for your advices
Patrick
"Erik Naggum" <e...@naggum.no> a écrit dans le message news: 3168085010519...@naggum.no...
> * "Patrick Jarjoui" <patrick.jarj...@insa-rouen.fr> > | Well i'm using a 524 MB for Memory on a Pentium II 450 MHZ isn't > | that enough to execute a simulation built in CLOS on FRANZ Allegro > | COMMON LISP?
> Yes, it is. Does that make you think it could be your own code?
> #:erik > -- > If this is not what you expected, please alter your expectations.
Patrick Jarjoui wrote: > Hello everybody, > there's no infinite loopthat's for sure i check it out > only loop with a specific condition but as i'm programming an > object oriented package designated for simulation it creates a > huge number of object so it execute garbage collector 20 > times before the processor go down and it didn't even attend the > half (228 MB) of full memory wich i increase it 524 MB. > So i'm thinking if i reduce the percentage of using the processor > from 100% to for example 70% so the PC won't go down and it'll > use the rest of the memory instead to complete his work, or else in > my case you must reboot your Windows system cause your pc is dead. > I try it on a small number of objects and it works so the problem > is in lisp itself or in windows and that is for sure or you must change > your processor to a higher on your PC and we don't have that much > money to do that.
Well, if you are having ACL taking 100% CPU, it is obviously not a question of running out of memory: in that case the hard disk would be continuously paging, with the CPU load at perhaps 15 %.
One question that comes to my mind is, has anybody bothered optimizing your garbage collector settings? I once managed to reach a 8-fold speedup on ACL 4.3.2 on a particular application by tweaking the oldspace/newspace sizes etc.
If you haven't investigated that, the results of (sys:gsgc-parameters) and (cl:room t) might be interesting.
* Patrick Jarjoui wrote: > Hello everybody, > there's no infinite loopthat's for sure i check it out > only loop with a specific condition but as i'm programming an > object oriented package designated for simulation it creates a > huge number of object so it execute garbage collector 20 > times before the processor go down and it didn't even attend the > half (228 MB) of full memory wich i increase it 524 MB. > So i'm thinking if i reduce the percentage of using the processor > from 100% to for example 70% so the PC won't go down and it'll > use the rest of the memory instead to complete his work, or else in > my case you must reboot your Windows system cause your pc is dead. > I try it on a small number of objects and it works so the problem > is in lisp itself or in windows and that is for sure or you must change > your processor to a higher on your PC and we don't have that much > money to do that.
Do you have 524Mb of *real* memory in the machine? How much memory is Lisp using? This sounds like an absolutely classic paging problem. If it is then getting a faster processor will make essentially no difference at all as it will be spending 9x% of its time waiting for the disk.
* Tim Bradshaw <t...@cley.com> | Do you have 524Mb of *real* memory in the machine? How much memory is | Lisp using?
Well, it is actually fairly hard to make Allegro CL use more than about 400M of old-space memory if you want reasonable new-space performance, even when using very strong words to drive home the point in a machine with more than enough physical memory and 4G of swap space just for kicks. I have seen ACL give up the proverbial ghost fighting battles with memory beyond 512M, which coincides with the fixnum capacity.
#:Erik -- If this is not what you expected, please alter your expectations.
On Wed, 24 May 2000 14:11:49 +0200, "Patrick Jarjoui"
<patrick.jarj...@insa-rouen.fr> wrote: >Hello everybody, > there's no infinite loopthat's for sure i check it out >only loop with a specific condition but as i'm programming an >object oriented package designated for simulation it creates a >huge number of object so it execute garbage collector 20 >times before the processor go down and it didn't even attend the >half (228 MB) of full memory wich i increase it 524 MB.
I would be intersting if some experienced lisper could post some general guidelines for writting efficient Lisp code. Most textbooks seam to insist on elegant code only, but you can't just forget about performance... So? O:-)
//----------------------------------------------- // Fernando Rodriguez Romero // // frr at mindless dot com //------------------------------------------------
Tim Bradshaw <t...@cley.com> writes: > * Francis Leboutte wrote:
> > Yes. > > But with ACL on NT , instead of (loop while t) you would have to do
> > (loop while t > > do > > (process-pending-events))
> > to get some acceptable responsiveness from the applications (ACL included).
> What? Are you saying that a process on NT can simply block other > processes from running without (very) special privileges? That seems > extraordinary to me.
in my experience with running background simulations under NT at work and comparing this to running them in the background under linux at home (and other unix machines in general like sun sparc or hp boxen), i find that NT is fairly bad at multi-tasking.
in NT, to get decent user interaction, you have to crank up the foreground priority bonus. this starves the background simulation for cpu cycles. the windows widget for adjusting priorities is very crude and doesn't give hardly any options -- it's just focused task vs all the others and three levels of bonus to active window. the programming API might be a bit better, but i don't know.
look at the target audience for NT, corporate ms-office users, i suspect microsoft thinks multi-tasking is equivalent to not having to kill one application before starting another. they don't expect the unfocused application to want to consume any cpu. they certainly haven't optimized for background tasks.
this is subjective and not quantified, but my impression is that NT fairly sucks in this regard. win9x is merely worse.
"Patrick Jarjoui" <patrick.jarj...@insa-rouen.fr> writes: > Hello everybody, > there's no infinite loopthat's for sure i check it out > only loop with a specific condition but as i'm programming an > object oriented package designated for simulation it creates a > huge number of object so it execute garbage collector 20 > times before the processor go down and it didn't even attend the > half (228 MB) of full memory wich i increase it 524 MB.
Sounds like GC death.
If your objects are long-lived, (which I assume they are because of the number of GCs), you should cons them in a more permanent space and avoid having the generational GC copy them back and forth. This is especially true if you create these huge objects all at once before starting the `meat' of your simulation.
Read Franz's documentation on tuning the GC. You should be able to fix this problem with a little experimentation.
Francis Leboutte <f.lebou...@algo.be> writes: > Tim Bradshaw <t...@cley.com> wrote:
> >* Francis Leboutte wrote:
> >> Yes. > >> But with ACL on NT , instead of (loop while t) you would have to do
> >> (loop while t > >> do > >> (process-pending-events))
> >> to get some acceptable responsiveness from the applications (ACL included).
> >What? Are you saying that a process on NT can simply block other > >processes from running without (very) special privileges? That seems > >extraordinary to me.
> Well it's not uncommon for Microsoft to make extraordinary things. I > vaguely remember having red that an application has to be programmed > "correctly" for the NT (win95 ?) scheduler makes its job appropriately (has > to respect some rules which maybe ACL doesn't).
I don't want to be the local apologist for Microsoft, but NT isn't *that* broken. NT does have pre-emptive processing, so it isn't necessary to explicitly relinquish your timeslice.
Of course, if you *do* explicitly relinquish your timeslice, you will make the machine that much more responsive.
I believe that the ACL scheduler on NT attempts to do the right thing by relinquishing the processor when all lisp threads are waiting, but neither the ACL scheduler nor the NT scheduler can read your mind. When you execute code like (loop while t), there is no easy way to tell that you are simply spinning your wheels (halting problem, anyone?), so as far as the ACL scheduler is concerned, the thread executing that code is doing `work', and will therefore take up processor time.
> I am not too surprised by what is related by Patrick Jarjoui. Usually when > I recompile an application (ACL/NT) , I take advantage of this to make some > phone calls or play with my dog - which is fine for me ; for example > opening a new message window in Eudora takes about 5 seconds at that time. > It is why I said that the NT scheduler is not very clever about "too" > greedy processes.
NT is probably making the simple assumption that ACL and Eudora are equally important to you, so each gets about half the resources of CPU time and memory. Of course, when Eudora wants to create a window, it is going to request a good chunk of memory and probably page stuff, etc.
You can tell NT to give the foreground process a priority boost, though. This can often make the machine much more responsive even if a `background' process is taking up all the spare CPU cycles.
