(But this last example will typically fail to show anything interesting, as most implementations either ignore declarations or compute modulo MOST-POSITIVE-FIXNUM.)
Even fixnum addition with automatic promotion to bignums is not really associative, if you care about consing:
> > > I haven't been complaining about the situation before simply > > > because I think nothing is going to happen to it anyway.
> > This will become a self-fullfilling prophecy. There are so > > many requirements and good suggestions for enhancements for > > lisps, especially for CL, that there is no way that we lisp > > vendors can or will move our products toward requirement sets > > that do not match our customer base (or what we perceive to be > > our potential future customer base). If you don't assert > > yourself as a potential future customner, or if we don't find > > out about you through marketing search efforts, then how can > > anything possibly happen to move CL toward your goals?
> It looks like you are reading C.L.L.
Yes, I do, and have listened in for many years.
> Isn't this enough?
Sometimes it is, and sometimes it isn't.
As an example of times when listening to c.l.l directly affects the product, I was watching a thread a year or two ago about multiple- value-returns, and at some point in the conversation I asked myself why the first few values returned couldn't be returned in registers (in the same way arguments are passed in registers). As a result, all architectures except for the sparc (whose register-windows architecture makes this problematic) will now return up to the same number of values as they can pass as arguments. This makes code smaller, faster, and allows tail-call merging.
I will only describe times when c.l.l is not appropriate for technical interaction: Many times, by the time a suggestion gets to c.l.l, it has been been transformed from an "It would be nice if ..." type of comment to a "Why doesn't this product do this ridiculously obvious thing ...?" I would much rather answer an individual customer, even with a potentially negative answer that includes a time scale or a "we'll look into it" or a "we're already working on it" than to try to sort through the many frustrations that individual may have had silently. We are not mind readers, and rely on user's suggestions to help us to know what is wanted.
> And yes! I am registred as a "customer" in your databases.
I looked through our SPR database (i.e. Software Problem Reports, the database that logs interactions with any customer, including linux users, that send mail to the bugs mailing list). At first I failed to find your name. But when I did an exhaustive textual search, I found you in two sprs, in both of which you had been quoted on a news or mailing group. Now, there may have been other emails to us, but we are not mind readers; if you don't tell us what your problems are with the product, how will we know? (Of course, I would love to hear "I don't have any problems with it", but I suspect that that is not the case :-)
> Now answer this. How many times did a thread like "why doesn't CL > provide a common FFI?" show up in this (and related newsgroups?)
Of course I haven't logged all of the newsgroup proceedings, so I will venture a qualitative guess and say "many times". I would have also asked you what your point was, but it is clear that the point is coming up next:
> Second question.
> Why don't Franz and Harlequin (and Digitool) come up with a common FFI > interface and be done with it? It will not be an ANSI standard but it > will be an "industry standard"?
I can't speak for Harlequin or Digitool, and I'll even take off my Franz hat for this one:
From previous definitions in this thread about what constitutes an "industry standard" (or "de facto standard"), I personally don't like them; they are usually more trouble than a formal standard and provide less benefits.
I should qualify this by adding that de facto standards are appropriate where a formal standard is non-existant or has failed. And although the CL standard is not perfect, I don't think it has failed. It hasn't provided a FFI yet, but it has only been through one iteration, and I presume others are possible, if there is enough interest.
> > > Currently the Lisp people seem to write software that > > > has much lower requirements (regarding these problematic-for-me > > > aspects) than the software me and my colleagues write and thus > > > the Lisp compiler vendors don't have reason to improve their > > > products into this direction.
> > I think it is unduly judgemental to characterize those requirements > > as "lower"; I would prefer to call them "different". As lisp vendors > > (as is the case for other vendors) we try to satisfy as many > > requirements as it makes business sense for us to satisfy. But > > if you don't state those requirements, we can't incorporate > > them into our thinking.
> Most likely, the requirements you try to satisfy are not those that > will expand the CL market as a whole. This is marketing short > sightedness. (Unless, of course, Franz is thinking to get out of the > CL market in the future).
No, I think you'll see us fully immersed in the CL market for a long time.
> PS. IMHO, the CLIM case is an example of *bad cooperation* among > vendors.
Interesting statement. Well, from what I know about CLIM's history, I would characterize it as a "de facto" or "industry" standard. If you believe CLIM to be a Bad Thing, then perhaps what you believe about it that is bad can be attributed to the de facto standardization process.
-- 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)
[I was somewhat vague at some points, I'll try to clarify at the same time I comment on your response, for which I thank you.]
| The reasons below do seem like a tall order, especially for one | who is not any CL vendor's customer :-) In reality, I can't
True :) I have just started to consider CL as an alternative for Scheme just because it's another potential source for suitable implementations. Although I mentioned Scheme as my preferred Lispish language (to which you commented (*)), it too has some weak points or points that I don't like. OTOH, actually (with my current knowledge of CL) the only big point why I don't like CL is its separate namespaces for variables and functions. So basically, if I find some great CL implementation first, then I would probably lean on CL as my primary language. On the other hand, if I find some suitable Scheme implementation first, then Scheme might turn out to become my primary language. In practise, I think that I will eventually apply Scheme for some applications and CL for others. Currently the situation is simply that I know Scheme better (and so do my colleagues, so I have better chances to push Scheme for 'real' projects) and Scheme implementations have suited better for my personal work in which I have been able to use some Lispish language, so I have ended up using the available Schemes instead of becoming a customer of any CL vendor (or user of some free implementation).
| I do suggest that you use those CLs that you have installed and | actually do some experimenting. However, I must first discuss
I'll try to do that.
| This will become a self-fullfilling prophecy. There are so | many requirements and good suggestions for enhancements for | lisps, especially for CL, that there is no way that we lisp | vendors can or will move our products toward requirement sets | that do not match our customer base (or what we perceive to be | our potential future customer base). If you don't assert | yourself as a potential future customner, or if we don't find | out about you through marketing search efforts, then how can | anything possibly happen to move CL toward your goals?
I'll comment on this below. (**)
| > Currently the Lisp people seem to write software that | > has much lower requirements (regarding these problematic-for-me | | I think it is unduly judgemental to characterize those requirements | as "lower"; I would prefer to call them "different". As lisp vendors
I know, when I first wrote that sentence it didn't say _at all_ what I meant so I tried to fix it with that adjustion in parens but it didn't really make it better :) Different them shall be.
| (as is the case for other vendors) we try to satisfy as many | requirements as it makes business sense for us to satisfy. But | if you don't state those requirements, we can't incorporate | them into our thinking.
(**) I know that you would satisfy everyone if you just could (don't we all :), but like you say, you have to think business-wise too. I'm just very sceptic about the number of other Lisp developers or potential Lisp developers with as high performance or other requirements than I have. And this leads to the suspicion that satisfying those requirements doesn't make business sense to you and thus the situation won't change.
If I 'forced' our development team to use Lisp (and thus become a CL vendor's customer) for some project with, say, high performance requirements, then I would have to have some guarantee that it will succeed from this language (plus implementation) choice's part. And naturally you can't guarantee (of course, feel free to say I'm wrong about this :) that you'll improve, say, some optimizations during our short project time (our projects are usually not very long-term ones excluding few exceptions) to the extend we would need them to be.
So I cannot do this (of course, I cannot do it because of other reasons too; I was somewhat exaggerating above, don't take that literally), but what I _can_ do is that I start using Lisp in my personal projects and suitable single-person project-team projects for our company that don't need to be on the bleeding edge in terms of performance or some other problematic aspect. Then I can gradually move into more and more demanding stuff. The only problem is that although this would be an ideal way to gradually start providing feedback for you or some other commercial Lisp vendor, I cannot afford to buy a commercial Lisp lisence for my personal 'hacks' just to be able to provide feedback for you. [I can always try to make our company buy ACL or similar in some phase whether or not it will be used for any real work or by anyone else but me ;)] For now, I continue using Scheme (except when I feel adventurous, I'll do that mentioned experimenting with cmucl or acl).
The possibilities for Scheme just got new light when I received a very interesting mail from Jeffrey Mark Siskind, the author of Stalin. He told me that he has been using Scheme for audio and video processing for a long time and is developing Stalin, which has zero-overhead FFI, possibility to make it support multithreading and it should generate pretty much equivalent floating point code (in terms of performance) as one can do by writing C directly. I'll know more after I get the latest development version he promised and experiment with it. Yes, it's a Scheme->C compiler (although he mentioned that there are plans for a native code backend), but it's a promising step in this gradual movement towards using Lisp/Scheme in applications with more and more "different" :) requirements.
| > every day and do some minor stuff with Scheme. I _would_ like to | > use Scheme for almost all programming, including multimedia ... (*) | OK, I am forewarned that CL is not your language of choice.
| only supports this on NT and Windows). I may get it wrong, | but our multiprocessing team tells me that the problem on | Linux is that it uses a `clone'-based implementation, instead of | moving toward Posix-compliance at the implementation level, | and that this causes problems for our own special needs for | OS-threads support.
Hmm, I cannot comment based on that information. Have you considered asking help from the developers of Posix-thread interface or kernel developers? What you said about that clone-based implementation really needs a bit more clarification -- after all, it's simply how _kernel_ exposes generic functionality for threads and it should be transparent to the user of Posix-compliant threads implemented as a library. Of course, that library may still have some problems with Posix-compliance, but I'm sure that the developers are willing to try to fix such problems that affect you. And if it turns out that these problems simply cannot be fixed because of some limitation in the kernel's clone()-based interface, then the issue should be brought into attention of kernel developers. Posix-threads are, after all, the only sensible way to use threads at application level, so if they cannot be implemented properly, then the situation must be fixed.
| Yes, but if it is an interpreter, then you won't get the kinds | of optimizations you are asking for (unless the implementation | introduces a compiler as well).
True, it is an interpreter and cannot provide such optimizations. This far it has been the best Scheme-implementation for non-speed-critical programs, though.
| There is nothing about CL which precludes such efficient | compilation. Show me some C++ code with attending disassembled | output, and I could likely get to the same range of execution | speed as any C++ compiler. Note, however, that this is much
I'll do that. I will have to reproduce the assembly output of that mentioned IDCT routine so that I can compare it to what Stalin + {pgcc, egcs} can do.
| easier to accomplish on RISC architectures, because of the | different nature of the x87/Pentium stack-based floating-point | architecture.
I know. Exactly that's why our performance requirements may be harder to achieve with a compiler that is not well tuned for the x86 architecture (which _some_ C++ compilers are _beginning_ to be). x86 is the primary target for most of the software we've been making, so we cannot make that RISC excuse -- either some compiler does good enough job or we'll write the speed-critical parts by hand.
| You can, although it is not documented. In your ACL-5.0beta/linux, | set the variable comp::*hack-compiler-output* to a list of functions | which you want to hack in lisp pseudo-assembler code; then when | you compile the function, follow the directions at the break prompt | and experiment to your heart's content. | | This hacking can be done on all architectures, and although | it is not recommended for normal code generation, it can be | used to experiment with.
Sounds like a nice feature. I didn't expect something like this or inline-assembly of MCL that Rainer Joswig mentioned. I'll definitely try it.
| > coding (slow) wrappers. I have understood that at least cmucl | > and Allegro CL have this kind of FFI. Am I right? | | Yes, of course, but perhaps Foreign Functions is not the | best way to go if you need such speed. Hacking the assembler | code as mentioned above might help.
FFI is still needed for interfacing to GUI toolkits and such. Naturally not _all_ of our code is insanely speed-critical :)
| Some wrapper libraries are available, and in the past many | individual CL users created and maintained their own. I think | that the new trend is to use a C/C++ to lisp translator to read | the .h files and to create such wrapper libraries | automatically.
Do you have some translator in mind? Perhaps even such that has 'back ends' for generating wrappers for different Lisp vendors' FFIs?
| But I think, from the rest of your post, that this isn't really | what you want anyway; if you are looking for blazing speed at | a low level, it shouldn't
In article <35E32DFF.32997...@IntelliMarket.Com>, Kelly Murray
<k...@IntelliMarket.Com> wrote: > One needs to look at what are the key strengths of a product/language > (e.g. LISP), and what type of market/customer cares the most > about those strenghs. > And look honestly at its weaknesses, and avoid trying to sell/compete > to customers that value those weaknesses. > Numeric/floating point is a particularly weak aspect of CL. > So is the relatively large disk and memory footprint, > and slow startup times.
Why should there be no progress?
> What applications have very large footprints/data sets > and/or keep applications running so startup time is not relevant, > and don't run on lowest-end hardware?
You are talking about the typical PC/Mac productivity application (Xpress, Freehand, Word, Excel, Photoshop, Cyberstudio, FrameMaker, Illustrator, AutoCAD, ...)?
I guess MCL starts faster than most of those. ACL actually starts pretty fast on a Unix box, too.
We have seen an incredible speed up lately. One of our customers has a large network of graphics systems (SUNs, Scitex, Macs, SGIs, ...). Typical transfer rates (not those on sundays where few were working) from a server three years ago were 300kb/sec. Currently they have copy rates from Ethershare servers to Macs of 8MB/sec (Switches everywhere, UW2 SCSI disks, 100 BaseT, IP, ...). 100MB size print jobs will be spooled in a few seconds. Who cares about start up speed of a 3 MB app versus startup speed of a 10 MB app? You can get laptops with >200 MIPS and >100 MB RAM for around $3000. What will you do with fast networks (and ultra-fast networks soon) and really fast computers? Be prepared to have demand for network server applications that either work in the intranet with very complex data or are able to handle large crowds in the Internet providing sophisticated services.
A question is, who will give you the tools to handle the complexity and will help you to come with cool apps on the market in time? What tool will let you develop in your language and will make sure that you are not slowed down by stupid problems (low level bugs, speed traps, debugging nightmares, ...). The customer really often will not care - the solution counts.
My current bet is on CL/CLIM/CL-HTTP. Well, I could be wrong... ;-) A good OODB is still missing.
> How about another hint, who requires high productivity > from their developers/programmers?
In article <z9XD1.2$Sm5.176...@burlma1-snr1.gtei.net>, Barry Margolin <bar...@bbnplanet.com> wrote:
>Lisp is probably one of the easiest languages to interpret (in many ways, >the internal representation of source code is similar to threaded languages >like Forth). Its main problem has been that it has a large runtime >environment that often needs to be initialized before it can start >interpreting the application.
There can be pretty small Lisps, though. The run-time env doesn't have to be large.
Anyway, the ease of implementing Lisp is an important point. I can't think of any other "language" with more implementations.
Indeed, even confining myself to Common Lisp, at work I have a choice between 2 C implementations (gcc and one from Sun) but 4 Common Lisps, and more if I wanted them.
Raymond Toy <t...@rtp.ericsson.se> writes: > CMUCL can for some functions produce code as good as C/C++. Using a > straight-forward implementation of the code from Oppenheim and > Schafer, a 64K-point complex radix-2 FFT in CMUCL takes 0.33 sec. > Matlab takes 0.16 sec. Matlab may be using more sophisticated > algorithms than my simple FFT. Perhaps a radix-8, radix-4 algorithm > would produce similar results as Matlab. Then the IDCT could be as > fast as C. Maybe.
AFAIK, and I may be wrong, the core of Matlab is written in FORTRAN.
Hannu Koivisto <az...@iki.fi.ns> writes: > | Some wrapper libraries are available, and in the past many > | individual CL users created and maintained their own. I think > | that the new trend is to use a C/C++ to lisp translator to read > | the .h files and to create such wrapper libraries > | automatically.
> Do you have some translator in mind? Perhaps even such that > has 'back ends' for generating wrappers for different Lisp > vendors' FFIs?
There are several points to start from, although most that I'm aware of are for Scheme rather than CL:
- One of the IMHO most versatile Generators is SWIG (the Simplified Wrapper and Interface Generator), which currently supports wrapping C/C++/Obj-C Libs for Perl, Python, Tcl and Guile (GNU's SCM-based Scheme interpreter) at the least. I think it would be _very_ useful, to adapt this to support the FFI's of current CLs.
The only problem that I see with this adaption, is that GUILE -- like most Scheme interpreters nowadays -- uses Boehm Conservative GC, which simplifies interfacing to C/C++ at the cost of less-than-optimal GC performance, whereas most CLs don't.
OTOH there is much to be gained, as SWIG really makes wrapping C libs very unproblematic, and is easily adaptable, with a very supportive and cooperative author, David Beazley. For further information, see http://www.swig.org/
- Many Scheme implementations include their own wrapper generators, like e.g. MzScheme, as do many modern functional languages nowadays.
- If speed is even less of an issue, going through CORBA is another course of action open. ILU at ftp://ftp.parc.xerox.com/pub/ilu/ilu.html supports Common Lisp (ACL I think), and there is work beign done at http://www.gnome.org/ (with support from RedHat) for a small, fast implementation of a CORBA 2.0 ORB, which will support GUILE at the least.
Regs, Pierre.
-- Pierre Mai <d...@cs.tu-berlin.de> http://home.pages.de/~trillian/ "Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
I have snipped out a large portion of your post, for which I agree and have no further comment.
Hannu Koivisto <az...@iki.fi.ns> writes: > I know that you would satisfy everyone if you just could (don't > we all :), but like you say, you have to think business-wise > too. I'm just very sceptic about the number of other Lisp > developers or potential Lisp developers with as high performance > or other requirements than I have. And this leads to the > suspicion that satisfying those requirements doesn't make > business sense to you and thus the situation won't > change.
Those suspicions are unfounded in fact. Lisp is very much in the high-performance game, and while implementations aren't as far as they could be, they are progressing.
> If I 'forced' our development team to use Lisp (and thus > become a CL vendor's customer) for some project with, say, high > performance requirements, then I would have to have some > guarantee that it will succeed from this language (plus > implementation) choice's part.
This is correct; there can be no guarantees (except, I suppose, for contractual ones, where the consequences are spelled out) for _any_ language. This includes C++ (Along with lisp-to-C++ conversion success stories, I have also heard horror stories where projects fail simply because the programming wouldn't scale due to the size/complexity of the software).
> And naturally you can't guarantee > (of course, feel free to say I'm wrong about this :) that you'll > improve, say, some optimizations during our short project time > (our projects are usually not very long-term ones excluding few > exceptions) to the extend we would need them to be.
Well, one thing about lisps and other dynamic languages that you'll need to get used to: it is incredibly easy to patch them. And, given a responsive support team, you can get solutions to your problems in days or weeks, instead of months or years.
> ... I cannot afford to buy a commercial Lisp > lisence for my personal 'hacks' just to be able to provide > feedback for you.
This is exactly why we lisp vendors provide free implementations.
> The possibilities for Scheme just got new light when I received > a very interesting mail from Jeffrey Mark Siskind, the author of > Stalin. He told me that he has been using Scheme for audio and > video processing for a long time and is developing Stalin, which > has zero-overhead FFI, possibility to make it support > multithreading and it should generate pretty much equivalent > floating point code (in terms of performance) as one can do by > writing C directly. I'll know more after I get the latest > development version he promised and experiment with it. Yes, > it's a Scheme->C compiler (although he mentioned that there are > plans for a native code backend), but it's a promising step in > this gradual movement towards using Lisp/Scheme in applications > with more and more "different" :) requirements.
This is good; it represents a shattering of a myth (that lisp doesn't do numbers fast) in at least one person's mind. Hopefully you'll be successful with this package.
> | only supports this on NT and Windows). I may get it wrong, > | but our multiprocessing team tells me that the problem on > | Linux is that it uses a `clone'-based implementation, instead of > | moving toward Posix-compliance at the implementation level, > | and that this causes problems for our own special needs for > | OS-threads support.
> ... What you said about that > clone-based implementation really needs a bit more clarification
In resonding to some personal mail, our multiprocessing expert said:
The "every thread has its own pid in Linux" is the major problem. Signals are a big deal, as are thread exiting protocols and interaction with exit(). As long as this situation continues, it almost doesn't matter that Linux POSIX thread "wrapping" exists - a significant portion of our code has to be rewritten to deal with this behavior.
It is heartening to hear that Linux is moving toward Posix compliance. We'll see what happens.
> | easier to accomplish on RISC architectures, because of the > | different nature of the x87/Pentium stack-based floating-point > | architecture.
> I know. Exactly that's why our performance requirements may be > harder to achieve with a compiler that is not well tuned for the > x86 architecture (which _some_ C++ compilers are _beginning_ to > be). x86 is the primary target for most of the software we've > been making, so we cannot make that RISC excuse -- either some > compiler does good enough job or we'll write the speed-critical > parts by hand.
You've hit the nail on the head: it really is "that RISC excuse" (although it's really "that x86 excuse", because the 68k floating point hardware didn't have this problem ...) The floating point code is written to assume that float registers can be identified and operated on in random-access fashion, rather than on a stack-based fashion. I assume that there is specialized code generation in those compilers that you allude to, which specifically generate stack-based floating-point operations. The x87/486/Pentium) floating hardware has only 8 registers arranged on a stack-access basis, and if compilers want to compile specifically for them, they must also deal specifically with overflow/spill code that doesn't have to be dealt with for random-access code generation. We currently punt on the situation by holding the stack fast and generating instructions to simulate random-access. It is, presumably, slightly slower. So far nobody has complained. Maybe you'll be the first :-)
Now if you were on an Alpha, (or even a 68K), we could easily hold our own in code genberation for floating point.
> | > coding (slow) wrappers. I have understood that at least cmucl > | > and Allegro CL have this kind of FFI. Am I right? > | > | Yes, of course, but perhaps Foreign Functions is not the > | best way to go if you need such speed. Hacking the assembler > | code as mentioned above might help.
> FFI is still needed for interfacing to GUI toolkits and > such. Naturally not _all_ of our code is insanely speed-critical :)
Thanks; this was a point I had missed on your previous post.
> | Some wrapper libraries are available, and in the past many > | individual CL users created and maintained their own. I think > | that the new trend is to use a C/C++ to lisp translator to read > | the .h files and to create such wrapper libraries > | automatically.
> Do you have some translator in mind? Perhaps even such that > has 'back ends' for generating wrappers for different Lisp > vendors' FFIs?
There is a free one at ftp.franz.com/pub/cbind/5.0.beta/* There are versions that will run on SGI, Sparc, or Windows, but I think you can actually send other architectures' files through if you set up the predefined macros correctly. And certainly you should be able to use the output in any 5.0.beta, including Linux.
I am also told that the cbind package will be included in the 5.0 distribution.
> Thanks for the interesting information,
Thanks for the interest.
> -- > Hannu Koivisto | What you see is all you get. > NOYB | - Brian Kernighan > -------------------------------------------------------------
-- 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)
In article <dh37lzx316l....@iolla.dcs.ed.ac.uk>, Juliusz Chroboczek <j...@dcs.ed.ac.uk> wrote:
>In article <6rsk17$...@pravda.cc.gatech.edu>, > ly...@cc.gatech.edu (Lyman S. Taylor) writes:
>LST> Ha! MCL can remove the recursion from the "naive" fibonacci. :-) >LST> [ Although, much more of a special case due to the fact numbers are >LST> involved. ]
>I have some trouble believing that. Doing that requires knowing that >addition is associative --- which is only true of bignums.
Note that Common Lisp permits implementations to reorder argument processing based on the mathematical associativity rules, even though the computer operations are not necessarily associative. But this only applies to multiple arguments to the same function, e.g. (+ a b c), and not multiple function calls, i.e. (+ a (+ b c)) cannot be implemented as (+ (+ a b) c) unless they're guaranteed to be equivalent.
In any case, a typical fibonacci function is likely to be defined only for integers, so the optimization LST described should be valid.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Cambridge, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> Duane Rettig <du...@franz.com> writes: > > Marco Antoniotti <marc...@galileo.parades.rm.cnr.it> writes: > > PS. IMHO, the CLIM case is an example of *bad cooperation* among > > vendors. >Interesting statement. Well, from what I know about CLIM's history, I >would characterize it as a "de facto" or "industry" standard. If you >believe CLIM to be a Bad Thing, then perhaps what you believe about it >that is bad can be attributed to the de facto standardization process.
The biggest problem with CLIM is the lack of a public domain reference implementation.
IMHO, CLOS took off quickly because enough of it could be provided by PCL for potential users to try it out. Once they were hooked, they would want to buy a higher performance/better featured implementation from a commercial vendor.
I don't care if a PD CLIM is slow, ugly and a memory hog, it would make proof of concept work easier for me.
Robert Swindells ------------------------------------- Robert Swindells - GenRad Ltd r...@genrad.co.uk - Work r...@fdy2.demon.co.uk - Home
It would be very interesting and useful if the various vendors (at least Franz and Harlequin) could provide a "free" version of CLIM 2.1 for Linux to go along with the "free" CL implementation. Perhaps they just cannot spare the resources to maintain such a port. But this would be a partial solution to the PD reference version mentioned below.
> > > Marco Antoniotti <marc...@galileo.parades.rm.cnr.it> writes:
> > > PS. IMHO, the CLIM case is an example of *bad cooperation* among > > > vendors.
> >Interesting statement. Well, from what I know about CLIM's history, I > >would characterize it as a "de facto" or "industry" standard. If you > >believe CLIM to be a Bad Thing, then perhaps what you believe about it > >that is bad can be attributed to the de facto standardization process.
> The biggest problem with CLIM is the lack of a public domain reference > implementation.
> IMHO, CLOS took off quickly because enough of it could be provided by > PCL for potential users to try it out. Once they were hooked, they > would want to buy a higher performance/better featured implementation > from a commercial vendor.
> I don't care if a PD CLIM is slow, ugly and a memory hog, it would make > proof of concept work easier for me.
> Robert Swindells > ------------------------------------- > Robert Swindells - GenRad Ltd > r...@genrad.co.uk - Work > r...@fdy2.demon.co.uk - Home
* Barry Margolin <bar...@bbnplanet.com> | Note that Common Lisp permits implementations to reorder argument | processing based on the mathematical associativity rules, even though the | computer operations are not necessarily associative.
I thought Common Lisp had strict left-to-right evaluation rules, as per 3.1.2.1.2.3 Function Forms. where does the standard say what you say?
#:Erik -- http://www.naggum.no/spam.html is about my spam protection scheme and how to guarantee that you reach me. in brief: if you reply to a news article of mine, be sure to include an In-Reply-To or References header with the message-ID of that message in it. otherwise, you need to read that page.
In article <4ww7vbmuh....@beta.franz.com>, Duane Rettig <du...@franz.com> wrote: > Those suspicions are unfounded in fact. Lisp is very much in > the high-performance game, and while implementations aren't as > far as they could be, they are progressing.
Minus supporting threads on multiple processors for SMP machines (SMP Linux PCs, SUNs, ...).
In article <3113247040185...@naggum.no>, Erik Naggum <cle...@naggum.no> wrote:
>* Barry Margolin <bar...@bbnplanet.com> >| Note that Common Lisp permits implementations to reorder argument >| processing based on the mathematical associativity rules, even though the >| computer operations are not necessarily associative.
> I thought Common Lisp had strict left-to-right evaluation rules, as per > 3.1.2.1.2.3 Function Forms. where does the standard say what you say?
The above wasn't referring to evaluation of argument forms (which is left-to-right, as you say), but to how the function processes the arguments that were passed to it.
-- Barry Margolin, bar...@bbnplanet.com GTE Internetworking, Powered by BBN, Cambridge, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
> | Note that Common Lisp permits implementations to reorder argument > | processing based on the mathematical associativity rules, even though the > | computer operations are not necessarily associative. > I thought Common Lisp had strict left-to-right evaluation rules, as per > 3.1.2.1.2.3 Function Forms. where does the standard say what you say?
It does. You need to evaluate the args left-to-right, but you can *process* them in a different order. For instance if I had:
(+ 1 1.0 1 1.0)
I can arrange to do the integer addition, a coercion and then two FP additions, rather than coercion, fp-add, coercion, fp-add, fp-add.
* Barry Margolin <bar...@bbnplanet.com> | The above wasn't referring to evaluation of argument forms (which is | left-to-right, as you say), but to how the function processes the | arguments that were passed to it. | | See | <http://www.harlequin.com/education/books/HyperSpec/Body/sec_12-1-1-1....> | for the standard's wording.
oh, OK, it's the fine line between "argument" and "parameter", again. 12.1.1.1 is very clear. thanks for the pointer.
#:Erik -- http://www.naggum.no/spam.html is about my spam protection scheme and how to guarantee that you reach me. in brief: if you reply to a news article of mine, be sure to include an In-Reply-To or References header with the message-ID of that message in it. otherwise, you need to read that page.
* Barry Margolin <bar...@bbnplanet.com> | The above wasn't referring to evaluation of argument forms (which is | left-to-right, as you say), but to how the function processes the | arguments that were passed to it. | | See | <http://www.harlequin.com/education/books/HyperSpec/Body/sec_12-1-1-1....> | for the standard's wording.
oh, OK, it's the fine line between "argument" and "parameter", again. 12.1.1.1 is very clear. thanks for the pointer.
#:Erik -- http://www.naggum.no/spam.html is about my spam protection scheme and how to guarantee that you reach me. in brief: if you reply to a news article of mine, be sure to include an In-Reply-To or References header with the message-ID of that message in it. otherwise, you need to read that page.
>>>>> "Raymond" == Raymond Toy <t...@rtp.ericsson.se> writes:
Raymond> CMUCL can for some functions produce code as good as C/C++. Using a Raymond> straight-forward implementation of the code from Oppenheim and Raymond> Schafer, a 64K-point complex radix-2 FFT in CMUCL takes 0.33 sec. Raymond> Matlab takes 0.16 sec. Matlab may be using more sophisticated Raymond> algorithms than my simple FFT. Perhaps a radix-8, radix-4 algorithm Raymond> would produce similar results as Matlab. Then the IDCT could be as Raymond> fast as C. Maybe.
Just wanted to post a correction that just occurred to me. In the matlab test that I did, I essentially timed fft(ones(65536,1)). However, if I try something like fft(ones(65536,1)*(1+j)), I get 0.33 sec, the same as CMUCL. I guess that, with the previous call, matlab realized that the data was real and used a simpler and shorter real transform instead to get the desired complex-valued transform. The correct comparison, of course, is the complex-valued transform since that's what the Lisp version assumed.
So with this result, I see no reason at all why Lisp needs to be slower than Fortran or C.
