Erik Naggum wrote: > Well, suppose you have a stream that produces about 50 M/s, your > maximal GC delay is 100 ms, and your processing ability is above 50 > M/s, you can set up output buffers of about 5 M, which you would > fill before starting actual output and which would drain during GC, > coupled with an input buffer that would fill up during GC and be > drained faster than new input is filling it.
This would not work if real-time output synchronization is needed (e.g., displaying a video stream). Maybe an option is to set up two processes, one would prepare the buffers (e.g., subsequent video frames) and the other performs the synchronized output of the buffer.
* Martin Cracauer | Well, if it's real-time, you may get into conflict with the Garbage | Collector.
This is a persistent myth. Real time does not mean zero latency. With stream data, non-zero latency translates to buffering. You don't want to saturate the processor, anyway, so you have time to catch up after a GC.
| There are no "real" problems with Common Lisp reaching what I'd call | "raw machine speed". Minor problems are that the declarations in | Lisp are ugly and hard to write, so that you loose some of Lisp's | advantage.
So use Common Lisp to its advantage and write macros to help with the type declarations, then.
| Using objects from classes in the classical sense in Lisp (CLOS) is | a lot slower than C++ or Objective-C, but for raw speed you don't | want that anyway.
Another persistent myth. Properly declared, CLOS is not at a disadvantage compared to C++, which does a lot of unnecessary copying due to its lack of garbage collection. It takes more time than C++ aficionados are willing to admit.
If CMUCL still uses PCL, it should be noted that a native CLOS is much, much more efficient than PCL.
#:Erik -- If this is not what you expected, please alter your expectations.
Robert Monfera <monf...@fisec.com> writes: > This would not work if real-time output synchronization is needed > (e.g., displaying a video stream). Maybe an option is to set up two > processes, one would prepare the buffers (e.g., subsequent video > frames) and the other performs the synchronized output of the > buffer.
Even this won't work in all cases unless you have some guarantees from the operating system (i.e. a real-time OS), no matter how big your buffers.
"Bruce Tobin" <bto...@columbus.rr.com> writes: > Throwing in type declarations and function-specific optimization hints is a > lot of work. In my experience just throwing a
> (declare (optimize (speed 3) (safety 0)))
> at the top of the file will do the trick. Try it with your code and see.
At Franz Inc., we tend to recommend against the wholesale use of the specific (speed 3) (safety 0) combination, because it may cause correct code to run incorrectly. Specifically, two extra optimizations it causes are: - Declared fixnums remain fixnums when adding or subtracting, which tends to eliminate the overflow check. Thus, what should be an overflow into a bignum becomes a wrap around to a large fixnum of the opposite sign. Care must be given that fixnums will never get large enough to overflow. - Interrupt checks are not made. This causes lisp code never to relinquish a tight loop in a multiprocessing situation, and thus may cause the lisp to appear to hang or become unresponsive.
Instead, we recommend a
(declaim (optimize (speed 3) (safety 1)))
at the top, with selected declarations of (safety 0) at local contours which have been thought out and the above cases eliminated or mitigated.
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Throwing in type declarations and function-specific optimization hints is a lot of work. In my experience just throwing a
(declare (optimize (speed 3) (safety 0)))
at the top of the file will do the trick. Try it with your code and see. It may be that because one of your integer counters is being multiplied with a floating point, you will need to add a specific declaration for that one. Usually ACL does a decent job of type inferencing when the (speed 3) switch is on, but the float multiplication may confuse it enough that an explicit type declaration is required for that variable.
Erik Naggum <e...@naggum.net> writes: >* Martin Cracauer
> If CMUCL still uses PCL, it should be noted that a native CLOS is > much, much more efficient than PCL.
Last time I spoke to Jim Veitch - at that time at Franz - he told me they were still using PCL for Allegro as well. The difference is that they profiled common applications and tuned the methods lookup mechanism (especially the hashing) to those. The assumptions Gregor Kiczales made at the time he wrote PCL were different, maybe even not based on measured data at all. CMUCL uses the original mechanism and hence is slower than it needs to be.
The whole discussion is a little besides the point. I didn't say that a CLOS program is slower than a C++ program (although there's a bigger chance that this is the case than for a non-CLOS CL applications versus a C app). What I said is that CLOS objects are meant to be used for larger-scale abstractions than C++ objects and when you use them for fine-graded purposes, your hash-based lookup taking methods combinations into account will not be able to meet the speed of C++'s simple function calls (can even be inlined) or at most using one pointer indirection through a method (not class) pointer stored in a C++ object. It goes without saying that C++'s design quickly leads to slowness through increased space requirements, but it is not sure whether your applications hits it, while it is sure that the initial function call speed benefit is there.
That is, BTW, what Dylan's paradigm of classes that may be sealed is about - give the user one class mechanism where he can express both paradigms (CLOS flexibility vs. closed-app speed) in a single mechanism and can change existing classes from one of them to the other without changing much code, especially without forcing the user to re-wrap his method's code into a different way to organize methods. And without the C++ style bloating the RAM amount of *every* object where for many it doesn't pay off because these objects don't have methods calls othen enough for the direct function benefit, but are called frequently enough to trash caches or cause paging.
The whole point is moot anyway when people start requiring using CORBA over XML-based RPC and at the same time force the use of some OO patterns where local iteration over collections of remote objects takes place. Just heard the war story of a case in that line. You will be able to beat that by speed in every language once you beat down the stupidness.
Erik Naggum <e...@naggum.net> writes: >* Martin Cracauer >| Well, if it's real-time, you may get into conflict with the Garbage >| Collector. > This is a persistent myth. Real time does not mean zero latency. > With stream data, non-zero latency translates to buffering. You > don't want to saturate the processor, anyway, so you have time to > catch up after a GC.
That only applies when the playback may be some time behind the availability of the unfiltered stream of video or audio.
It doesn't work that way when you produce contents that must be synchronized with real events, i.e. audio for computer games can't build buffers, the action of the player is supposed to be spiced with a BOOM or whatever immediately.
>| Using objects from classes in the classical sense in Lisp (CLOS) is >| a lot slower than C++ or Objective-C, but for raw speed you don't >| want that anyway. > Another persistent myth. Properly declared, CLOS is not at a > disadvantage compared to C++, which does a lot of unnecessary > copying due to its lack of garbage collection. It takes more time > than C++ aficionados are willing to admit.
In practice, C++ programs tend to do a lot of unneeded copying, but I have to rate all of them into pilot errors, where programms use objects in a way that copies them, while a copy-free mechanism would be available to the programmer. The problem here is that C++ has too many complex rules of that kind for even a good programmer to take into account and that compilers don't warn about it (whereas existing Lisp compilers warn very well about consing).
* Robert Monfera <monf...@fisec.com> | This would not work if real-time output synchronization is needed | (e.g., displaying a video stream).
I said "which would drain during GC" about the output buffers. That's what solves the constant output bandwidth problem.
I'm insulted that you think I answered his question without considering constant data flow on the output side. Perhaps you didn't even read what I suggested? I have to hope so.
#:Erik -- If this is not what you expected, please alter your expectations.
* Colin Walters <walt...@cis.ohio-state.edu> | Even this won't work in all cases unless you have some guarantees from | the operating system (i.e. a real-time OS), no matter how big your | buffers.
Oh, I see, the point of this exercise is to prove it impossible, not to actually solve any problems. My mistake. I thought were were in constructive mode, but it is apparently important to find ways to make things _not_ work. I'll chip in with "Even that won't work if the power cord isn't connected. How does Lisp solve _that_, huh?"
#:Erik -- If this is not what you expected, please alter your expectations.
Erik Naggum <e...@naggum.net> writes: >* Colin Walters <walt...@cis.ohio-state.edu> >| Even this won't work in all cases unless you have some guarantees from >| the operating system (i.e. a real-time OS), no matter how big your >| buffers. > Oh, I see, the point of this exercise is to prove it impossible, not > to actually solve any problems. My mistake. I thought were were in > constructive mode, but it is apparently important to find ways to > make things _not_ work. I'll chip in with "Even that won't work if > the power cord isn't connected. How does Lisp solve _that_, huh?"
For sound, that's easy, you can make a lot of noise by dropping CLtL2 on the floor, much better than that lean C standard you only get as softcover.
* Martin Cracauer | That only applies when the playback may be some time behind the | availability of the unfiltered stream of video or audio.
So you want hardware solutions. Using software will out of necessity take non-zero time for non-zero efforts.
| It doesn't work that way when you produce contents that must be | synchronized with real events, i.e. audio for computer games can't | build buffers, the action of the player is supposed to be spiced | with a BOOM or whatever immediately.
I'm so glad we're in this negative mood where the purpose of this whole crappy exercise is to find ways Lisp will fail. Is it any wonder Lisp has a bad reputation? Even Lispers you'd think would have an interest in finding ways to solve the goddamn problems waste their time finding cases where they think it won't work. I have to wonder: Are you this bad an engineer?
| In practice, C++ programs tend to do a lot of unneeded copying, but I | have to rate all of them into pilot errors, where programms use | objects in a way that copies them, while a copy-free mechanism would | be available to the programmer.
And now, apologia for C++!? Christ. C++'s lack of GC has one very important consequence: It has to has to have an ownership protocol for its allocated objects. Ownership protocols are very interesting because the are extremely complex. Since the likelihood that they could be mastered by the kind of people who choose C++ is so close to zero only number theorists would find anything in that space, the easy way out is to create a new object with known owners and let the owner of the original take care of it. Writing C++ is bad enough, but copy-free C++ is a lot harder than consing-free Lisp.
#:Erik -- If this is not what you expected, please alter your expectations.
* Erik Naggum wrote: > Oh, I see, the point of this exercise is to prove it impossible, not > to actually solve any problems. My mistake. I thought were were in > constructive mode, but it is apparently important to find ways to > make things _not_ work. I'll chip in with "Even that won't work if > the power cord isn't connected. How does Lisp solve _that_, huh?"
I thought that WITH-POWER-ON was meant to do that? But yeah, to do it *right* you probably you really need something like Scheme's CALL-WITH-POWER-ON (CALL/PO) but I think that implementing that really means you can never stack-allocate protons, which is a real problem, since it basically means all your programs are radioactive. Of course in C++ they just bracket things with power->on() and power->off(), I have no idea what happens if they get an error, presumably they just end up violating energy conservation all over the place, but they don't seem to care about that.
Erik Naggum <e...@naggum.net> writes: >* Martin Cracauer >| That only applies when the playback may be some time behind the >| availability of the unfiltered stream of video or audio. > So you want hardware solutions. Using software will out of > necessity take non-zero time for non-zero efforts.
Non-zero delay is not the point, but a constant stream of data with at most such a delay that the human doesn't recognize it.
For audio, the time the sound travels trough the air is already non-neglectable. Still, existing Garbage Collectors in commonly available Common Lisp implementations may introduce pauses that are much longer than this. This may not even be the GC's direct fault, i.e. the operating system may have pages swapped out that aren't used by the working loop, but are swapped back in to scan them for GC-able or object-pointing material.
>| It doesn't work that way when you produce contents that must be >| synchronized with real events, i.e. audio for computer games can't >| build buffers, the action of the player is supposed to be spiced >| with a BOOM or whatever immediately. > I'm so glad we're in this negative mood where the purpose of this > whole crappy exercise is to find ways Lisp will fail. Is it any > wonder Lisp has a bad reputation? Even Lispers you'd think would > have an interest in finding ways to solve the goddamn problems waste > their time finding cases where they think it won't work. I have to > wonder: Are you this bad an engineer?
Well, I'm not an a negative mood, but feel free to differ.
This discussion is quite clear in what we think Lisp might have problems with - a very limited set of applications - and anyone not getting that is too stupid to write working software anyway, so why bother?
I know of at least one Lisp system without GC and whatever Harlequin came up with probably isn't stupid as well, so the whole discussion isn't against Lisp per se.
>| In practice, C++ programs tend to do a lot of unneeded copying, but I >| have to rate all of them into pilot errors, where programms use >| objects in a way that copies them, while a copy-free mechanism would >| be available to the programmer. > And now, apologia for C++!? Christ. C++'s lack of GC has one very > important consequence: It has to has to have an ownership protocol > for its allocated objects. Ownership protocols are very interesting > because the are extremely complex. Since the likelihood that they > could be mastered by the kind of people who choose C++ is so close > to zero only number theorists would find anything in that space, the > easy way out is to create a new object with known owners and let the > owner of the original take care of it. Writing C++ is bad enough, > but copy-free C++ is a lot harder than consing-free Lisp.
Didn't we we just express the same thing?
If you look over Bjarne Stroustrup's C++ page, you will notice that the 7th external link paragraph is to Boehm's GC, so at least the clever C++ people seem to be more aware of the problem than their language spec might imply.
Erik Naggum <e...@naggum.net> writes: > * Colin Walters <walt...@cis.ohio-state.edu> > | Even this won't work in all cases unless you have some guarantees from > | the operating system (i.e. a real-time OS), no matter how big your > | buffers.
> Oh, I see, the point of this exercise is to prove it impossible, not > to actually solve any problems.
No. I was trying to point out that the real problem doesn't isn't with Lisp; it is fact that a non-real-time OS could sometimes (for example) swap out one of the processes the above poster suggested using, and then maybe the original poster would blame Lisp for being slow, when in fact it isn't.
Tim wrote: > I thought that WITH-POWER-ON was meant to do that? But yeah, to do it > *right* you probably you really need something like Scheme's > CALL-WITH-POWER-ON (CALL/PO) but I think that implementing that really > means you can never stack-allocate protons, which is a real problem, > since it basically means all your programs are radioactive.
Did hear the report this morning on the radio that BNFL is currently gearing up to accept 40 tonnes of SIOD code on which the testing certification was falsified...
I didn't catch the implications of draining / filling during GC - it relies on a secondary heavyweight process (maybe a second Lisp image).
Presumably the auxiliary processing can be very simple, e.g., outputting an array of bytes representing a bitmapped image. GC does not make a synchronized input/output much more difficult at all.
> > I want to use lisp to deal with processing a stream of video. Do you > > think that's ridiculous, or can I process data with lisp almost as > > quickly as a lower level language?
> Actually, I don't really know how fast your program must run.
> In my opinion, it is not ridiculous at all to expect good speeds with > lisp programs, provided that you follow some implementation-dependent > optimization techniques. I recommend CMU/CL which seems to permit the > best speeds. > The techniques for optimization are often easy to apply, even if there > are many cases where I simply get lost (problems in understanding CMU/CL > documentation).
> For instance, I developped with 4 comrades a small OpenGL subset in > Common Lisp, using CMU/CL. We finally managed to get 1/4 of the speed of > MesaGL in average, with the possibility to go up to 1/2 (university > project in limited time). We really enjoyed using Common Lisp which > gives so many convenient features and gives you a better view over your > programs. This also permits more advanced optimizations.
> But if you really need high speed, maybe you should consider assembly > code only for the time-consuming functions. Notice that you really can > call such speedy functions from CMU Common Lisp, allying convenience of > the language with optimal execution speeds. That is what companies > (Naughty Dog, Nichimen) tend to do when they need terrific speeds for 3d > engines, for instance...
> I hope I helped you, I'd really like to know if you will manage to make > it in Common Lisp and how. My knowledge in CMU/CL optimization > techniques needs to be completed...
> -- > ---------------------------------------------- > Jonathan BAILLEUL (baill...@emi.u-bordeaux.fr) > Maitrise Informatique, Universite Bordeaux I > Currently attending Berkeley Summer Session Courses CS61a/CS3
Can you please spell out CMUCL and point me at where I can download it from for Windows?
In article <8kh5af$2o...@counter.bik-gmbh.de>, craca...@counter.bik-gmbh.de (Martin Cracauer) wrote:
> Richard James Panturis Giuly <n...@spam.com> writes:
> >I want to use lisp to deal with processing a stream of video. Do you > >think that's ridiculous, or can I process data with lisp almost as > >quickly as a lower level language?
> Well, if it's real-time, you may get into conflict with the Garbage > Collector.
> Looking at your previous posting, the first thing you need is to turn > on maximum warning level on your C compiler. The second thing to do > is to compile your code on CMUCL, even if your final version should > run on a different Lisp. CMUCL compiler emit a lot of message that > help you to make your code fast.
> * Martin Cracauer > | Well, if it's real-time, you may get into conflict with the Garbage > | Collector.
> This is a persistent myth. Real time does not mean zero latency. > With stream data, non-zero latency translates to buffering. You > don't want to saturate the processor, anyway, so you have time to > catch up after a GC.
> | There are no "real" problems with Common Lisp reaching what I'd call > | "raw machine speed". Minor problems are that the declarations in > | Lisp are ugly and hard to write, so that you loose some of Lisp's > | advantage.
> So use Common Lisp to its advantage and write macros to help with > the type declarations, then.
> | Using objects from classes in the classical sense in Lisp (CLOS) is > | a lot slower than C++ or Objective-C, but for raw speed you don't > | want that anyway.
> Another persistent myth. Properly declared, CLOS is not at a > disadvantage compared to C++, which does a lot of unnecessary > copying due to its lack of garbage collection. It takes more time > than C++ aficionados are willing to admit.
> If CMUCL still uses PCL, it should be noted that a native CLOS is > much, much more efficient than PCL.
> #:Erik > -- > If this is not what you expected, please alter your expectations.
* k...@compuserve.com | So what free or under $200 lisp for Windows would you recommend?
I wouldn't -- I recommend paying people in relative proportion to the values they provide me, and "free" means I don't get any value, and under USD 200 means you're moving in the mass market. I don't.
I recommend Franz Inc's Allegro CL Lite for Windows, which is a trial edition (a full-featured "demo" version), and which you get free of charge, but can't use for any money-making endeavors.
#:Erik -- If this is not what you expected, please alter your expectations.
k...@compuserve.com writes: > So what free or under $200 lisp for Windows would you recommend?
Depedns on your preferecnes. Corman Lisp is priced exactly $200 for commercial use, and free for non-profit use. It also has some kind of IDE, COM interface and ability to write inline assembler code. Allegro CL Lite is a version of full-blown ACL with nice Delphi-like GUI builder, but with limited heap size, though it is sufficient for educational purposes. Xanalys' LispWorks Personal ed. is a trial of their commercial product, with limitation on heap size and usage time. It has Emacs-like IDE, so if you are into The Only True Editor you may like it. CLISP is free in GPL sense, but don't expect from it any bells and whistles of the commercial versions. It also can't compile to native code, unlike the previous options.
In article <3172431287769...@naggum.net>, Erik Naggum <e...@naggum.net> wrote:
> Another persistent myth. Properly declared, CLOS is not at a > disadvantage compared to C++, which does a lot of unnecessary > copying due to its lack of garbage collection. It takes more time > than C++ aficionados are willing to admit.
That's Erik, the language bigot, talking out of his arse again. It seems he knows just enough about C++ to think he's an expert, but not enough to comment intelligently about it.
<cs61a...@cory.eecs.berkeley.edu> wrote: > For instance, I developped with 4 comrades a small OpenGL subset in > Common Lisp, using CMU/CL. We finally managed to get 1/4 of the speed of
What about adding a page with some info about your project to the CLiki site?
