> But why the Auto CAD,
> a program that mostly needs
> fast work is wtitted in LISP...???
>
> Thanks, Robert...!!!
Abstract from "On using Common Lisp for Scientific Computing" by
"Nicolas Neuss"
Lisp is a very flexible and powerful language, but up to now it has not
been used intensively for applications in scientific computing. The
main reason is the prejudice that Lisp is slow. While this prej- udice
may have been true in early stages of Lisp's history, it is not really
true today. Furthermore, the virtues of Lisp are becoming more and more
important. In this contribution, we support this point of view: first,
by comparing the eAEciency of BLAS routines written in C and Common
Lisp and second, by discussing the recently developed toolbox Femlisp
for solving partial differential equations with finite element methods
and multigrid.
For the rest of the article, see
http://www.iwr.uni-heidelberg.de/~Nicolas.Neuss/publications.html
Eric Lavigne wrote:
> Lisp is a very flexible and powerful language, but up to now it has not
> been used intensively for applications in scientific computing. The
> main reason is the prejudice that Lisp is slow. While this prej- udice
> may have been true in early stages of Lisp's history, it is not really
> true today. Furthermore, the virtues of Lisp are becoming more and more
> important. In this contribution, we support this point of view: first,
> by comparing the eAEciency of BLAS routines written in C and Common
> Lisp and second,
Reimplementing BLAS in Lisp and C is a pretty stupid benchmark, IMHO. People
are not likely to do this in real programs when they're interested in
performance - they'll use BLAS.
Also, is it me or has he reversed the order of the inner loops in the
on-line "dynamic" C implementation, making it much slower?
If you change the C to the C++:
for (int i=0; i<100; i++)
for (int pos1=n; pos1<(n-1)*n; pos1+=n)
for (int pos2=pos1+1; pos2<pos1+n-1; pos2++)
{
double s=u[pos2];
for (int k=0; k<9; k++)
s += stencil_values[k]*u[pos2+stencil_shift[k]];
u[pos2] = s;
}
then it is just as "dynamic" and fast as the Lisp but shorter and simpler.
> by discussing the recently developed toolbox Femlisp
> for solving partial differential equations with finite element methods
> and multigrid.
From the FEMLisp FAQ:
"Femlisp is still very slow for several standard problems"
> For the rest of the article, see
> http://www.iwr.uni-heidelberg.de/~Nicolas.Neuss/publications.html
I'd much rather see benchmarks showing how much simpler Lisp code can be,
e.g. interfacing to BLAS. His Lisp code is much longer than the C:
$ wc *.c ../lisp/*.lisp
30 71 598 stencil-dynamic.c
21 52 447 stencil-static.c
59 277 2227 ../lisp/codegen.lisp
Lisp would probably do well on the same set of tasks as OCaml, so it would
be interesting to port the complete examples from the end of my OCaml book
to Lisp.
Also, is it worth mentioning Stalin?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Jon Harrop <······@jdh30.plus.com> writes:
> Eric Lavigne wrote:
>> Lisp is a very flexible and powerful language, but up to now it has not
>> been used intensively for applications in scientific computing. The
>> main reason is the prejudice that Lisp is slow. While this prej- udice
>> may have been true in early stages of Lisp's history, it is not really
>> true today. Furthermore, the virtues of Lisp are becoming more and more
>> important. In this contribution, we support this point of view: first,
>> by comparing the eAEciency of BLAS routines written in C and Common
>> Lisp and second,
>
> Reimplementing BLAS in Lisp and C is a pretty stupid benchmark,
> IMHO. People are not likely to do this in real programs when they're
> interested in performance - they'll use BLAS.
Right. But in this sense, for people interested in performance, all
computer languages have the same speed (at least for large datasets). Does
not sound very useful to me.
> Also, is it me or has he reversed the order of the inner loops in the
> on-line "dynamic" C implementation, making it much slower?
>
> If you change the C to the C++:
>
> for (int i=0; i<100; i++)
> for (int pos1=n; pos1<(n-1)*n; pos1+=n)
> for (int pos2=pos1+1; pos2<pos1+n-1; pos2++)
> {
> double s=u[pos2];
> for (int k=0; k<9; k++)
> s += stencil_values[k]*u[pos2+stencil_shift[k]];
> u[pos2] = s;
> }
You are right. As much as I remember, I tested both orders and this was
the faster version at that time. But it is incorrect, you are right, and
testing it now again I see that the other order results in the dynamic C
version being only 12% faster than the static C or Lisp version. I fear we
have to search for another test doing even more work locally to really see
the benefit of static code.
I'll put a correction and disclaimer on the web.
> Lisp would probably do well on the same set of tasks as OCaml, so it would
> be interesting to port the complete examples from the end of my OCaml book
> to Lisp.
Alternatively, what about writing something equivalent or better than
Femlisp in OCaml? I would be very happy being able to compare performance
on real PDE problems.
> Also, is it worth mentioning Stalin?
Yes. Did you try it already?
Nicolas.
Nicolas Neuss wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
> > Reimplementing BLAS in Lisp and C is a pretty stupid benchmark,
> > IMHO. People are not likely to do this in real programs when they're
> > interested in performance - they'll use BLAS.
>
> Right. But in this sense, for people interested in performance, all
> computer languages have the same speed (at least for large datasets). Does
> not sound very useful to me.
For trivial problems like computing a dot product, yes. You can code
them very efficiently in a low-level language. But that is not an
accurate reflection of modern scientific computing where the use of
ever-more sophisticated data structures and algorithms continues to
improve performance at the cost of code complexity and development
time. This is where FPLs win, IMHO.
So I'd rather see benchmarks that use trees, hash tables, graphs and so
on.
> > Lisp would probably do well on the same set of tasks as OCaml, so it would
> > be interesting to port the complete examples from the end of my OCaml book
> > to Lisp.
>
> Alternatively, what about writing something equivalent or better than
> Femlisp in OCaml? I would be very happy being able to compare performance
> on real PDE problems.
Which of Lisp's capabilities does FEMLisp leverage?
> > Also, is it worth mentioning Stalin?
>
> Yes. Did you try it already?
Yes. Compilers like Stalin and MLton should be very useful for
long-running programs that are too intrinsically complicated to be
tractable in sucky languages like C++.
Cheers,
Jon.
"Dr Jon D Harrop" <···@ffconsultancy.com> writes:
> Nicolas Neuss wrote:
>> Jon Harrop <······@jdh30.plus.com> writes:
>> > Reimplementing BLAS in Lisp and C is a pretty stupid benchmark,
>> > IMHO. People are not likely to do this in real programs when they're
>> > interested in performance - they'll use BLAS.
>>
>> Right. But in this sense, for people interested in performance, all
>> computer languages have the same speed (at least for large datasets). Does
>> not sound very useful to me.
>
> For trivial problems like computing a dot product, yes. You can code
> them very efficiently in a low-level language. But that is not an
> accurate reflection of modern scientific computing where the use of
> ever-more sophisticated data structures and algorithms continues to
> improve performance at the cost of code complexity and development
> time. This is where FPLs win, IMHO.
I mostly agree. However, we are not yet there for many applications in
scientific computing, i.e., the performance still depends often mainly on
the performance of external libraries like BLAS, LAPACK, ATLAS, UMFPACK,
etc.
> So I'd rather see benchmarks that use trees, hash tables, graphs and so
> on.
Your ray tracer uses those, I presume?
>> > Lisp would probably do well on the same set of tasks as OCaml, so it would
>> > be interesting to port the complete examples from the end of my OCaml book
>> > to Lisp.
>>
>> Alternatively, what about writing something equivalent or better than
>> Femlisp in OCaml? I would be very happy being able to compare performance
>> on real PDE problems.
>
> Which of Lisp's capabilities does FEMLisp leverage?
Oh, it uses a lot of Lisp's built-in operators:-) But weren't we talking in
particular about comparing the performance of Common Lisp versus OCaml for
large problems in the domain of partial differential equations?
>> > Also, is it worth mentioning Stalin?
>>
>> Yes. Did you try it already?
>
> Yes. Compilers like Stalin and MLton should be very useful for
> long-running programs that are too intrinsically complicated to be
> tractable in sucky languages like C++.
I tried Stalin sometime before 2000 with no success (it did not even
compile). I did not try it again, so the situation may have improved.
Nicolas.
Nicolas Neuss wrote:
> "Dr Jon D Harrop" <···@ffconsultancy.com> writes:
>> For trivial problems like computing a dot product, yes. You can code
>> them very efficiently in a low-level language. But that is not an
>> accurate reflection of modern scientific computing where the use of
>> ever-more sophisticated data structures and algorithms continues to
>> improve performance at the cost of code complexity and development
>> time. This is where FPLs win, IMHO.
>
> I mostly agree. However, we are not yet there for many applications in
> scientific computing, i.e., the performance still depends often mainly on
> the performance of external libraries like BLAS, LAPACK, ATLAS, UMFPACK,
> etc.
Yes. The performance of BLAS rewritten in Lisp is highly unlikely to be an
issue. The overhead of using BLAS from Lisp might be much more interesting.
>> So I'd rather see benchmarks that use trees, hash tables, graphs and so
>> on.
>
> Your ray tracer uses those, I presume?
The scene is represented hierarchically as a tree in the ray tracer.
The "n"th-nearest neighbour example from my book uses sets represented as
immutable balanced binary trees to represent a graph. People have ported it
to using concurrent trees, hash tables and other data structures to improve
performance at the cost of code complexity.
>> Which of Lisp's capabilities does FEMLisp leverage?
>
> Oh, it uses a lot of Lisp's built-in operators:-) But weren't we talking
> in particular about comparing the performance of Common Lisp versus OCaml
> for large problems in the domain of partial differential equations?
I've never done any work with PDEs so that doesn't turn me on. I'm
interested to know why scientists use Lisp, particularly in terms of
performance.
>> Yes. Compilers like Stalin and MLton should be very useful for
>> long-running programs that are too intrinsically complicated to be
>> tractable in sucky languages like C++.
>
> I tried Stalin sometime before 2000 with no success (it did not even
> compile). I did not try it again, so the situation may have improved.
I installed the Debian package and it worked perfectly.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Jon Harrop <······@jdh30.plus.com> writes:
>>> Which of Lisp's capabilities does FEMLisp leverage?
>>
>> Oh, it uses a lot of Lisp's built-in operators:-) But weren't we talking
>> in particular about comparing the performance of Common Lisp versus OCaml
>> for large problems in the domain of partial differential equations?
>
> I've never done any work with PDEs so that doesn't turn me on. I'm
> interested to know why scientists use Lisp, particularly in terms of
> performance.
Hmm, I had hoped you would not only expect others to redo what you have
already done (ray tracer, "complete examples in my book"), but also take
challenges in the other direction.
Maybe, it is also not so difficult for you. You have already found out
earlier in this thread that I am a lousy Lisp programmer, because my Lisp
stencil program is five times longer than the static C one. So the 20,000
lines of code for the core of Femlisp translate into only 4,000 lines of C
code. Since Ocaml surely is more concise than C by a factor of 2, your
OCaml program would have a length of only 2,000 lines which looks like a
reasonable project. At least, I suspect that the "complete examples" in
your book which you suggested us to port to Lisp have a comparable number
of lines.
But maybe you know of some already existing PDE solver in OCaml? If yes,
you could speak with its author and I would probably agree to make such a
comparison with him. I think of the following setting: a third person
giving us a reasonably simple and interesting PDE problem which we try to
solve from both sides.
Nicolas.
Nicolas Neuss wrote:
> Hmm, I had hoped you would not only expect others to redo what you have
> already done (ray tracer, "complete examples in my book"), but also take
> challenges in the other direction.
>
> Maybe, it is also not so difficult for you. You have already found out
> earlier in this thread that I am a lousy Lisp programmer, because my Lisp
> stencil program is five times longer than the static C one. So the 20,000
> lines of code for the core of Femlisp translate into only 4,000 lines of C
> code. Since Ocaml surely is more concise than C by a factor of 2, your
> OCaml program would have a length of only 2,000 lines which looks like a
> reasonable project. At least, I suspect that the "complete examples" in
> your book which you suggested us to port to Lisp have a comparable number
> of lines.
Well, to port my ray tracer you must read 50 lines of OCaml code but for me
to port FEMLisp I must read 20,000 lines of Lisp. That doesn't seem
entirely fair! ;-)
Do you have a small PDE solver (say <200 LOC) that I could port instead?
> But maybe you know of some already existing PDE solver in OCaml? If yes,
> you could speak with its author and I would probably agree to make such a
> comparison with him. I think of the following setting: a third person
> giving us a reasonably simple and interesting PDE problem which we try to
> solve from both sides.
I've just Googled for OCaml PDE solvers and there are some out there.
However, I am not qualified to say how comparable they are to FEMLisp in
terms of capability.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Jon Harrop <······@jdh30.plus.com> writes:
> Nicolas Neuss wrote:
>> Hmm, I had hoped you would not only expect others to redo what you have
>> already done (ray tracer, "complete examples in my book"), but also take
>> challenges in the other direction.
>>
>> Maybe, it is also not so difficult for you. You have already found out
>> earlier in this thread that I am a lousy Lisp programmer, because my Lisp
>> stencil program is five times longer than the static C one. So the 20,000
>> lines of code for the core of Femlisp translate into only 4,000 lines of C
>> code. Since Ocaml surely is more concise than C by a factor of 2, your
>> OCaml program would have a length of only 2,000 lines which looks like a
>> reasonable project. At least, I suspect that the "complete examples" in
>> your book which you suggested us to port to Lisp have a comparable number
>> of lines.
>
> Well, to port my ray tracer you must read 50 lines of OCaml code but for
> me to port FEMLisp I must read 20,000 lines of Lisp. That doesn't seem
> entirely fair! ;-)
I believe it is about as fair as your length comparison of my Lisp and C
code...
> Do you have a small PDE solver (say <200 LOC) that I could port instead?
There is an article about a Matlab FEM program with 50 lines. However, I
like this approach as little as your ray tracing, because the program is
written in a very uninspiring and restricted way and does not allow for
extension. I'm sure that we could easily reproduce it both in OCaml and
Lisp (solving the system with an external direct solver, equivalent to
Matlab solving). But the benefit would be nothing; even the computational
effort would probably be dominated by the external solver.
>> But maybe you know of some already existing PDE solver in OCaml? If yes,
>> you could speak with its author and I would probably agree to make such a
>> comparison with him. I think of the following setting: a third person
>> giving us a reasonably simple and interesting PDE problem which we try to
>> solve from both sides.
>
> I've just Googled for OCaml PDE solvers and there are some out there.
> However, I am not qualified to say how comparable they are to FEMLisp in
> terms of capability.
Do you have any links?
Nicolas.
Nicolas Neuss wrote:
> Jon Harrop <······@jdh30.plus.com> writes:
>> Well, to port my ray tracer you must read 50 lines of OCaml code but for
>> me to port FEMLisp I must read 20,000 lines of Lisp. That doesn't seem
>> entirely fair! ;-)
>
> I believe it is about as fair as your length comparison of my Lisp and C
> code...
Your Lisp is only 2-3x longer, not 400x!
>> Do you have a small PDE solver (say <200 LOC) that I could port instead?
>
> There is an article about a Matlab FEM program with 50 lines. However, I
> like this approach as little as your ray tracing,
Meow.
> because the program is
> written in a very uninspiring and restricted way and does not allow for
> extension. I'm sure that we could easily reproduce it both in OCaml and
> Lisp (solving the system with an external direct solver, equivalent to
> Matlab solving). But the benefit would be nothing; even the computational
> effort would probably be dominated by the external solver.
Ok. If you want to get good performance and extensibility then I'd go for a
language with a whole-program optimising compiler like Stalin Scheme or
MLton SML. Abstraction can be costly in OCaml and Lisp.
>> I've just Googled for OCaml PDE solvers and there are some out there.
>> However, I am not qualified to say how comparable they are to FEMLisp in
>> terms of capability.
>
> Do you have any links?
Not yet. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Jon Harrop <······@jdh30.plus.com> writes:
> as Neuss wrote:
>
>> There is an article about a Matlab FEM program with 50 lines. However, I
>> like this approach as little as your ray tracing,
>
> Meow.
>
>> because the program is
>> written in a very uninspiring and restricted way and does not allow for
>> extension. I'm sure that we could easily reproduce it both in OCaml and
>> Lisp (solving the system with an external direct solver, equivalent to
>> Matlab solving). But the benefit would be nothing; even the computational
>> effort would probably be dominated by the external solver.
>
> Ok. If you want to get good performance and extensibility then I'd go for a
> language with a whole-program optimising compiler like Stalin Scheme or
> MLton SML. Abstraction can be costly in OCaml and Lisp.
Your power of deduction is remarkable. I would like to add that with
sufficient thrust, also frogs fly really fine.
Bye, Nicolas.
> Ok. If you want to get good performance and extensibility then I'd go for a
> language with a whole-program optimising compiler like Stalin Scheme or
> MLton SML. Abstraction can be costly in OCaml and Lisp.
>
I decided to try SML after reading this, but so far it doesn't seem
like you describe. In CL, it is costly to have abstraction in the sense
that if you don't specify the type of a variable then your program will
be slower. In SML, it seems like you don't have the choice to leave the
type unspecified. For example, if I want to write a trivial function
that just computes the average of two numbers...
fun ave(x,y) = (x+y)/2.0;
Sure, I didn't write that x and y need to be real, but the compiler
tells me that I am not allowed to use it with integers:
ave(1,1);
stdIn:23.1-23.10 Error: operator and operand don't agree [literal]
operator domain: real * real
operand: int * int
in expression:
aveR (1,1)
I think even C would let me get away with this and automatically cast
the integer to a real, but not SML. So how do I get such abstractions
in SML without paying the performance cost that I see in Lisp? Or are
you just saying that it's better to accept the lack of abstraction in
SML because the performance penalty of abstraction isn't worth it?
Eric Lavigne wrote:
> So how do I get such abstractions in SML without paying the performance
> cost that I see in Lisp?
By using abstractions that can be optimised away at compile time.
Specifically with the numeric tower, the compiler often can't tell whether a
given value will be a float, rational or int at compile time, so it must
insert lots of run-time checks and use generic functions. This can be
useful (e.g. arbitrary-precision reals in Mathematica) but most of the time
it is a useless hindrance, IMHO.
There are many other abstractions that can be resolved at compile time,
particularly HOFs, hierarchical sum types, objects and so on.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> You are right. As much as I remember, I tested both orders and this was
> the faster version at that time. But it is incorrect, you are right, and
> testing it now again I see that the other order results in the dynamic C
> version being only 12% faster than the static C or Lisp version. I fear
^^^^^^
slower
> we have to search for another test doing even more work locally to really
> see the benefit of static code.
>
> I'll put a correction and disclaimer on the web.
OK, here is the new version (which should be used automatically to update
the main IWR website later this day):
http://sit.iwr.uni-heidelberg.de/~neuss/publications.html
Note that the code given in the article was correct from the beginning.
(And I am quite sure that I used the correct version also for the benchmark
I reported there. The larger difference in execution times should be
reproducible using older hardware and C compilers.)
Nicolas.
Nicolas Neuss wrote:
> Note that the code given in the article was correct from the beginning.
Yes.
> (And I am quite sure that I used the correct version also for the benchmark
> I reported there. The larger difference in execution times should be
> reproducible using older hardware and C compilers.)
If you're going to use modern hardware then I think you should also use
modern compiler flags. I used:
g++ -O3 -ffast-math -march=athlon-tbird -funroll-all-loops ...
which made a big difference. I'll retime it on my AMD64...
Cheers,
Jon.
Nicolas Neuss <··················@iwr.uni-heidelberg.de> writes:
> OK, here is the new version (which should be used automatically to update
> the main IWR website later this day):
>
> http://sit.iwr.uni-heidelberg.de/~neuss/publications.html
OK, I changed the code now in such a way which should make the effect more
visible on modern architectures. Namely, I changed it in such a way that
the whole field should fit into the level 1 cache. Then I obtain for the
code in:
C_static: http://sit.iwr.uni-heidelberg.de/~neuss/misc/stencil_static.cc
C_dynamic: http://sit.iwr.uni-heidelberg.de/~neuss/misc/stencil_dynamic.cc
Lisp: http://sit.iwr.uni-heidelberg.de/~neuss/misc/stencil.lisp
the following results:
On my Laptop (Celeron, 1.5 GHz):
C_static: 2 sec
C_dynamic: 2.7 sec
CMUCL (dynamic): 2 sec
This means that Lisp is about 25% faster than a C program with equivalent
functionality.
On an AMD-Opteron 64bit machine I even see that SBCL/64 gives 1.3 secs,
while C_static gives 2 secs and C_dynamic gives 3.4 secs. I guess that I
should use other options besides -O3 on this architecture (suggestions?).
If someone could check this on other machines (especially newer ones) I
would be interested in the results.
Nicolas
Nicolas Neuss <··················@iwr.uni-heidelberg.de> wrote:
> OK, I changed the code now in such a way which should make the effect more
> visible on modern architectures. Namely, I changed it in such a way that the
> whole field should fit into the level 1 cache. Then I obtain for the code
> in:
>
> C_static: http://sit.iwr.uni-heidelberg.de/~neuss/misc/stencil_static.cc
> C_dynamic: http://sit.iwr.uni-heidelberg.de/~neuss/misc/stencil_dynamic.cc
> Lisp: http://sit.iwr.uni-heidelberg.de/~neuss/misc/stencil.lisp
>
> the following results:
>
> On my Laptop (Celeron, 1.5 GHz):
>
> C_static: 2 sec
> C_dynamic: 2.7 sec
> CMUCL (dynamic): 2 sec
>
> This means that Lisp is about 25% faster than a C program with equivalent
> functionality.
If I understand you well, this comparison is unfair. You're comparing
lisp code generated and compiled on the fly (so this is not really dynamic)
with really dynamic C code, so obvisouly the Lisp version will run faster.
A fair comparison would be between your Lisp code and a C++ template'd
version. Otherwise, you're not comparing performance, but expressiveness of
the 2 languages.
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna <······@lrde.epita.fr> writes:
>> This means that Lisp is about 25% faster than a C program with equivalent
>> functionality.
>
> If I understand you well, this comparison is unfair. You're comparing
> lisp code generated and compiled on the fly (so this is not really dynamic)
> with really dynamic C code, so obvisouly the Lisp version will run faster.
>
> A fair comparison would be between your Lisp code and a C++ template'd
> version. Otherwise, you're not comparing performance, but expressiveness of
> the 2 languages.
There are applications (e.g. in image processing or the numerical solution
of pdes) where such stencils cannot be determined at compile time
(e.g. when they appear as a user input or are computed at runtime). So
using templates does not work! Compiling code externally and linking it
dynamically would work, but is not in the C/C++ standard as much as I know.
I only want to say that there are certain applications where Lisp is faster
than C/C++ due to its different feature set. I think that this is a true
assertion.
Nicolas.
Nicolas Neuss <··················@iwr.uni-heidelberg.de> wrote:
> There are applications (e.g. in image processing or the numerical solution
> of pdes) where such stencils cannot be determined at compile time (e.g. when
> they appear as a user input or are computed at runtime). So using templates
> does not work! Compiling code externally and linking it dynamically would
> work, but is not in the C/C++ standard as much as I know.
OK, so replace templates by JIT compilation (even if it's obviously
easier in Lisp).
> I only want to say that there are certain applications where Lisp is faster
> than C/C++ due to its different feature set. I think that this is a true
> assertion.
I still disagree on the way you say it. You can't compare those
numbers. You can't say Lisp is faster. What you can say is that Lisp is better
at letting you express things in such a way that the resulting code will be
fast.
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna <······@lrde.epita.fr> writes:
> Nicolas Neuss <··················@iwr.uni-heidelberg.de> wrote:
>
>> There are applications (e.g. in image processing or the numerical
>> solution of pdes) where such stencils cannot be determined at compile
>> time (e.g. when they appear as a user input or are computed at
>> runtime). So using templates does not work! Compiling code externally
>> and linking it dynamically would work, but is not in the C/C++ standard
>> as much as I know.
>
> OK, so replace templates by JIT compilation (even if it's
> obviously easier in Lisp).
If you mean "JIT under complete user control" I agree. Otherwise, I could
imaginge that one could construct situations where automatic JIT would fail
to give optimal results.
>> I only want to say that there are certain applications where Lisp is
>> faster than C/C++ due to its different feature set. I think that this
>> is a true assertion.
>
> I still disagree on the way you say it. You can't compare those
> numbers. You can't say Lisp is faster. What you can say is that Lisp is
> better at letting you express things in such a way that the resulting
> code will be fast.
That's what I mean. And there are situations where C/C++ cannot express
things in such a way that the resulting code is optimally fast.
Nicolas.
Didier Verna <······@lrde.epita.fr> writes:
> Nicolas Neuss <··················@iwr.uni-heidelberg.de> wrote:
>
> > There are applications (e.g. in image processing or the numerical
> > solution of pdes) where such stencils cannot be determined at
> > compile time (e.g. when they appear as a user input or are
> > computed at runtime). So using templates does not work! Compiling
> > code externally and linking it dynamically would work, but is not
> > in the C/C++ standard as much as I know.
>
> OK, so replace templates by JIT compilation (even if it's obviously
> easier in Lisp).
>
>
> > I only want to say that there are certain applications where Lisp is faster
> > than C/C++ due to its different feature set. I think that this is a true
> > assertion.
>
> I still disagree on the way you say it. You can't compare
> those numbers. You can't say Lisp is faster. What you can say is
> that Lisp is better at letting you express things in such a way that
> the resulting code will be fast.
The whole point of making language comparisons is that different
features of the languages exhibit different strengths and
weaknesses. If you manage to implement the problem in an identically
equivalent way in the different languages, you are not comparing
languages anymore, but compiler performance. (Which, of course, will
always be a factor.)
Bj�rn
Bj�rn Lindberg wrote:
> The whole point of making language comparisons is that different
> features of the languages exhibit different strengths and
> weaknesses. If you manage to implement the problem in an identically
> equivalent way in the different languages, you are not comparing
> languages anymore, but compiler performance. (Which, of course, will
> always be a factor.)
That doesn't make sense. It is not possible to implement a problem in an
"identically equivalent way" such that you are comparing compiler
performance and not languages.
Different languages can have different performance characteristics. Some
languages are designed to be fast while others are designed to be general.
Even if you have different programs written in different languages that give
identical assembler output and have the same run-time environments, you can
still look at properties of the languages, e.g. verbosity.
So I can't see how your statement can be useful. Indeed, I strived to get
the ray tracer implemented "equivalently" in different languages and I
think the results are even more enlightening as a consequence.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
·····@runa.se (Bj�rn Lindberg) wrote:
> Didier Verna <······@lrde.epita.fr> writes:
>> I still disagree on the way you say it. You can't compare those
>> numbers. You can't say Lisp is faster. What you can say is that Lisp is
>> better at letting you express things in such a way that the resulting code
>> will be fast.
>
> The whole point of making language comparisons is that different features of
> the languages exhibit different strengths and weaknesses. If you manage to
> implement the problem in an identically equivalent way in the different
> languages, you are not comparing languages anymore, but compiler
> performance. (Which, of course, will always be a factor.)
I agree, and that's exactly the point: I don't think it has ever been
very clear in this thread what was at comparison: [language] expressiveness,
[compiler] performance, etc. That's why I wanted to emphasize on the
importance of formulation. Let me explain a bit further why I think this is
important.
In my lab, I work with people having a very strong and advanced
background in C++ template meta-programming. They have developped a static OO
paradigm and used it in a generic image processing library. So they have the
ability to express things in an OO fashion and at the same time get the
performance of dedicated code because everything is resolved at compile-time.
I'd like to convince them they would be better at using Lisp. However,
I can't fight directly at the language expressiveness level. Why ? Because,
admittedly, they had a hard time expressing what they wanted with C++
templates (you should see the code), but this work is /behind/ them. So now
that they have it, I don't see how I could convince them to start again.
However, if I can show them first (that's done actually) that at the
low level (compiler performance for instance), equivalent code can run as fast
in Lisp or even faster, there I'm getting their attention. And only then, I
can show them that with Lisp, they could express their concepts in a simpler
and more extensible way (and for that matter, get dedicated code at compile
time, just equivalent to what they have in their static C++ code, hence
running at least as fast), and only then I have a chance to win the battle.
So the moral is that sometimes, comparing laguages expressiveness is
not the most important or top priority thing.
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Jon Harrop wrote:
> Lisp would probably do well on the same set of tasks as OCaml, so it would
> be interesting to port the complete examples from the end of my OCaml book
> to Lisp.
>
> Also, is it worth mentioning Stalin?
It is worth to mentioning Bigloo however.
When refering to Stalin one may not forget that Stalin has no obvious
public support from the developers. I mean with Bigloo you get
documentaion and feedback from the developers of Bigloo. With Stalin I
am not sure on this. Some have mentioned Bigloo ist bad internet
representation. However, I for one like Bigloo its cheerleading on the
homepage.
If I had money I would donate it to the following Phd project for a
period of 4 to 5 years: can anyone show me whether a climate model or
any other processor intense complex task which takes some months or
years on a workstation on processor times can become written in
CommonLisp, Scheme, or OCaml without any huge bottlenecks in
performance.
And to extend the PhD project: a climate model in OCaml for example:
can it solve more complex tasks than a model written in old Fortran.
What I have gathered thus far: a lot of time in climate models is still
spent waiting for the results in a multi processor farm.
Schneewittchen
Förster vom Silberwald wrote:
>
> If I had money I would donate it to the following Phd project for a
> period of 4 to 5 years: can anyone show me whether a climate model or
> any other processor intense complex task which takes some months or
> years on a workstation on processor times can become written in
> CommonLisp, Scheme, or OCaml without any huge bottlenecks in
> performance.
Allow me to point you at the Supercomputer Toolkit:
http://repository.readscheme.org/ ftp/papers/berlinsurati-pepm94.pdf
``The Supercomputer Toolkit compiler performs partial evaluation
of data-independent programs expressed in the Scheme
dialect of Lisp by using the symbolic execution technique described
in previously published work by Berlin.''
Jacob Katzemelson at Technion has apparently used the Supercomputer
Toolkit to
run weather prediction models:
``Conservative estimates performed for a typical mesoscale forecast
over the eastern Mediterranean (for 36 hour) suggest that were the
Toolkit constructed from ALPHA processors, 10 processors would do the
prediction in only about 13 minutes. A 36 hours simulation with full
physics for the whole earth will require 2 hours for 80 ALPHA
processors.''
Eric Lavigne wrote:
>>But why the Auto CAD,
>>a program that mostly needs
>>fast work is wtitted in LISP...???
>>
>>Thanks, Robert...!!!
>
>
> Abstract from "On using Common Lisp for Scientific Computing" by
> "Nicolas Neuss"
>
> Lisp is a very flexible and powerful language, but up to now it has not
> been used intensively for applications in scientific computing. The
> main reason is the prejudice that Lisp is slow. While this prej- udice
> may have been true in early stages of Lisp's history, it is not really
> true today. Furthermore, the virtues of Lisp are becoming more and more
> important. In this contribution, we support this point of view: first,
> by comparing the eAEciency of BLAS routines written in C and Common
> Lisp and second, by discussing the recently developed toolbox Femlisp
> for solving partial differential equations with finite element methods
> and multigrid.
>
> For the rest of the article, see
> http://www.iwr.uni-heidelberg.de/~Nicolas.Neuss/publications.html
>
It was actually somewhat surprising to see that it was only
60% slower than c in the worst cases.
It'd be interesting to see how it performs with current
versions of CMUCL and SBCL, since that paper appears to be 4
years old.
QCD Apprentice <··············@gmail.com> wrote:
> It was actually somewhat surprising to see that it was only 60% slower than
> c in the worst cases. It'd be interesting to see how it performs with
> current versions of CMUCL and SBCL, since that paper appears to be 4 years
> old.
For equivalent code, you can now get _identical_ performance in some
cases, and quite often a degradation not exceeding 10% from Lisp. I hope to
show that in a upcoming submission to the ECOOP workshop (deadline coming fast
though ;-).
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
i have worked at AutoDesk the software is written i C++ att least rund
year 2000.
But it have Script that you can write in VisualLisp (formare AutoLisp)
witch is a subset of LISP or VBA Scripts.
Under AutoCad you olso can develop in C++ creating moduls called ARX
(Autocad Resource eXtension)
Later software tex. Autodesk Inventor don't use LISP anymore only VBA
(VisualBasic for Application).
Maby in history it was made i LISP but i never have seen any LISP code
just older C kod and newer code written in C++.
AndersPE wrote:
> i have worked at AutoDesk the software is written i C++ att least rund
> year 2000.
> But it have Script that you can write in VisualLisp (formare AutoLisp)
> witch is a subset of LISP or VBA Scripts.
>
> Under AutoCad you olso can develop in C++ creating moduls called ARX
> (Autocad Resource eXtension)
>
> Later software tex. Autodesk Inventor don't use LISP anymore only VBA
> (VisualBasic for Application).
>
> Maby in history it was made i LISP but i never have seen any LISP code
> just older C kod and newer code written in C++.
AutoDesk don't seem to really understand lisp, although they
implemented it in AutoCAD. I think they took it from elsewhere (slisp?)
a long time ago.
The variant they have implemented is slow and not very suitable for
implementing bits of AutoCAD itself.
The variant in Solidworks DWG editor, which is use quite often, is even
worse, a simple infinite recursive loop crashes it.
Search this group for information on
(declaim (optimize speed))
(declare (fixnum i j) (double-float x y z))
(disassemble ...)
From: Ken Tilton
Subject: Re: Myht LISP is slow...!!!
Date:
Message-ID: <EefUf.7$q05.3@fe12.lga>
Robert Bralic wrote:
> But why the Auto CAD,
> a program that mostly needs
> fast work is wtitted in LISP...???
>
> Thanks, Robert...!!!
>
>
I see you, too, are abusing caffeine. Double shots of Medaglia d'Oro had
me... well, back to Maxwell House until the symptoms clear.
ken
--
Cells: http://common-lisp.net/project/cells/
"And I will know my song well before I start singing." - Bob Dylan
Robert Bralic wrote:
> But why the Auto CAD,
> a program that mostly needs
> fast work is wtitted in LISP...???
I forget, what does "myth" mean?
--
Jens Axel S�gaard
I'll bite. Recently I wrote some simple floating point code in SBCL to
test it against C generated code. With appropriate type declares and
optimisations, the SBCL machine code was almost identical to the GCC
produced machine code. Timing the code showed that SBCL was a couple
of percent slower, but I personally put that down to either SBCL code
generation not quite being the same as GCC, or shear background noise.
Function call overhead might be slightly higher, and other factors may
contribute to Lisp appearing slower - but if you really want to you can
cause SBCL to generate machine code that is comparable to GCC.
And at that stage we are really talking about the quality of the
compiler rather than any fundamental flaws in the language.
Brad
This is not a myth, but a legend. Lisp /used/ to be slow.
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Robert Bralic wrote:
> But why the Auto CAD,
> a program that mostly needs
> fast work is wtitted in LISP...???
>
> Thanks, Robert...!!!
Lisp (Common Lisp) as a high level,
compilable, general purpose programming language.
Shows a very good performance in industrial implementations
such that CMUCL, SBCL, Allegro etc.
Comparison with languages which generally
lower level like ANSI C or domain specific like Fortran
or not compilable like Ruby is not fear.
Comparison with other from same group (high level,universal,compilable)
lead to the discussion of programming practice and quality
of implementations.
All other details is a matter of personal/organizational
preferences.
--
*It is easy to lie with statistics, but it's a lot easier to lie without
them.
Robert Bralic wrote:
> But why the Auto CAD,
> a program that mostly needs
> fast work is wtitted in LISP...???
For the few who are curious about early AutoCAD:
I was a heavy AutoCAD user in the mid-1980's (fond memories of acad
v2.62) and later worked with a former distinguished AutoDesk employee
from that era.
AutoCAD only ever used Lisp for its extension scripting language:
http://www.fourmilab.ch/autofile/www/chapter2_35.html
I was told that the core was originally written in Pascal then ported
to C by the late 1980's, and a former employee previously posted here
that it was C++ later.
Documented versions, however, imply Pascal was never used:
http://www.fourmilab.ch/autofile/www/chapter2_112.html
I had gone deep into AutoLISP... Think of it as little more than shell
scripting in Bash. Many AutoCAD extensions used it only as glue code,
with the heavy lifting in C. (I've never touched VisualLisp and can't
comment on that.)
-Daniel
--
http://play.org/daniel