Raf Cavallaro wheezed these wise words:
> Of the existing Lisp implimentations that run on 32 bit Windows platforms
> (i.e., 95 and NT), which produces the fastest code? I guess I'm asking for a
> comparison of code generated by Harlequin's LispWorks for Windows, and
> Franz's Allegro Common Lisp for Windows. Do either compare favorably with a
> decent C compiler (MS or Borland)?
I've not compared them on performance terms, but on features. I chose
LWW for features like threads, SQL, and delivery - all for a modest
price. When you compare a Lisp with C, what languages features are you
concerned about? In some respects, just being able to do a thing is
enough, esp if C can't do it at all. OTOH, there may be some areas
where both languages can compete, and yet C can outperform Lisp.
One of these areas might be I/O, but in that case you might be happy
to call C code in a DLL. I've done this myself, and found that a few
key functions in C can make a huge difference, while the rest of an
app can be written in Lisp. I often process text files, so this
approach works perfectly. The same C functions can be re-used again
and again, because they're general utilities that do things like skip
characters in a set (like whitespace), or collect characters until a
character in a set of delimiters is found.
As far as SQL is concerned, most of the work is done outside the app,
so the language isn't a big issue as far as performance is concerned.
If your code depended on things like ODBC, or external components,
then you probably wouldn't be asking this question. However, that's
just a guess - I don't know. As far as the quality of the code
produced by the LWW and ACL compilers, I'm as curious as you are! It's
just that it didn't matter to me, as the full ACL system was too
expensive for my modest budget.
So, I don't choose between C and Lisp. I use both when and where it
seems appropriate. The demands that each programmer makes on their
tools will vary, making this a hard question to answer. I can't assume
much about your demands without a few more details, but if you're
generating code at runtime, then C won't compete well with Lisp, no
matter what the performance of the code may be. OTOH, even when I used
Basic (well over 15 years ago), I've been writing code that generates
code in lower level languages. It used to be assembly, generated in
Basic and then C, but for the last 10+ years it's been C code
generated in Lisp.
--
Please note: my email address is munged
You can never browse enough
Martin Rodgers wrote in message ...
> It used to be assembly, generated in
>Basic and then C, but for the last 10+ years it's been C code
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>generated in Lisp.
^^^^^^^^^^^^^^^^^^^^^^
Martin, a couple of questions:
1. I understand how you would generate C code using Lisp, but how do you
invoke your compiler from LWW, or do you just compile the C code "by hand,"
and link it in later?
2. I'm hoping to automate the process as much as possible, since I'll be
running a genetic algorithm. I'd like the generated functions to be compiled
(given the sheer number of runs and the potential complexity of each). Maybe
I should just write a C DLL of processor intensive primitives, and let the
automatically generated functions call those primitives, instead of
generating Lisp code which is then compiled and run.
Any thoughts are greatly appreciated.
Sincerely,
Raf
In article <··········@news-central.tiac.net>, "Raf Cavallaro"
<·······@pop.tiac.net> wrote:
> 1. I understand how you would generate C code using Lisp, but how do you
> invoke your compiler from LWW, or do you just compile the C code "by hand,"
> and link it in later?
LWW has a DDE interface.
> 2. I'm hoping to automate the process as much as possible, since I'll be
> running a genetic algorithm. I'd like the generated functions to be compiled
> (given the sheer number of runs and the potential complexity of each). Maybe
> I should just write a C DLL of processor intensive primitives, and let the
> automatically generated functions call those primitives, instead of
> generating Lisp code which is then compiled and run.
>
> Any thoughts are greatly appreciated.
This is the way some people are using Common Lisp.
Write your code in a Lisp-like language, compile it
to whatever you like (for DSPs, C , ...) and maybe load the
result into Lisp via the FFI.
But first, I would look whether I can generate Lisp code with
proper type declarations and feed it to the Lisp compiler
using highest optimization. If you identify a potential
performance leak, you may want to contact your vendor.
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> LWW has a DDE interface.
It has a rather wonderful DDE interface. However, if it's your own
code that you want to communicate with, it would be better to use
sockets. On NT machines, pipes would be even better.
Still, it depends on how your programs talk to each other. If they
talk in frequent short bursts, then DDE will probably perform badly
compared with sockets or pipes. DDE has always looked to me like a
kludged IPC method that worked for a 16bit event driven model. In a
Win32 preemptive multitasking environment, we can do much better.
LWW now has an _excellent_ sockets interface. So does ACL/PC. Maybe
the fact that so many people use sockets, on so many different
platforms, makes me a little biased. ;) While DDE is an ugly kludge so
typical of Win16...Yet another reason to appreciate sockets.
And there're all the existing programs and tools that use sockets. Of
course, if you really do wish to talk using DDE, like if you must talk
to a Windows app that only supoorts DDE, then that's the only option.
My experience of DDE is mainly in C, which is very painful. Again,
this makes me biased. In Lisp, there are far fewer objections.
--
Please note: my email address is munged
You can never browse enough