I am new to Lisp so forgive me if this question is very noobish, but is
Lisp and/or the functional paradigm a good way to implement a large
physics system. Like a simulation engine ect. Especially if real time
results are important. One reason why i ask this question is because
since hardware is becoming incresingly parrallel, it would make sence
to use a language for which concurrency is not a big a issue as in
forinstance c++ or java
·······@gmail.com wrote:
> I am new to Lisp so forgive me if this question is very noobish, but is
> Lisp and/or the functional paradigm a good way to implement a large
> physics system.
Yes, and you can delete the word "physics".
> Like a simulation engine ect. Especially if real time
> results are important.
Lisp is only 20% slower than C. It is also easy to call C from Lisp if
that helps.
> One reason why i ask this question is because
> since hardware is becoming incresingly parrallel, it would make sence
> to use a language for which concurrency is not a big a issue as in
> forinstance c++ or java
>
Did you really want to write your own. Like I said, it is easy to call C
and to a degree C++ from Lisp, so you could use ODE or Tokomak or something.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> ·······@gmail.com wrote:
> > I am new to Lisp so forgive me if this question is very noobish, but is
> > Lisp and/or the functional paradigm a good way to implement a large
> > physics system.
>
> Yes, and you can delete the word "physics".
>
> > Like a simulation engine ect. Especially if real time
> > results are important.
>
> Lisp is only 20% slower than C. It is also easy to call C from Lisp if
> that helps.
Except when it is faster, http://weitz.de/cl-ppcre/ :)
Cheers
Brad
Ken Tilton wrote:
> Lisp is only 20% slower than C. It is also easy to call C from Lisp if
> that helps.
On this numerical benchmark:
http://www.ffconsultancy.com/free/ray_tracer/languages.html
I get 3.333s for g++ (4.1.2), 4.118s for OCaml (3.09.2) and 6.039s for SBCL
(0.9.16). So SBCL is 80% slower than g++ in this case. This is a 2.2GHz
Athlon64 running AMD64 Debian.
For n=11, I get 4.960s for g++, 6.925s for OCaml and 10.062s for SBCL. So
SBCL is less than half the speed of g++.
Compile times are also interesting, I get 2.012s for g++, 0.743s for OCaml
and 2.61s for SBCL.
Lisp also requires significantly more code on this benchmark.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists
Jon Harrop wrote:
> Ken Tilton wrote:
>
>>Lisp is only 20% slower than C. It is also easy to call C from Lisp if
>>that helps.
>
>
> On this numerical benchmark:
>
...So SBCL is 80% slower than g++ in this case.
"In this case", making your remarks no more pertinent than Mr. Atkin's
observation that a certain Lisp application could outerform a Perl
function implemented in C.
Try to keep up, will you people? With the English language, I mean.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Jon Harrop wrote:
> On this numerical benchmark:
> http://www.ffconsultancy.com/free/ray_tracer/languages.html
> I get 3.333s for g++ (4.1.2), 4.118s for OCaml (3.09.2) and 6.039s for SBCL
> (0.9.16). So SBCL is 80% slower than g++ in this case. This is a 2.2GHz
> Athlon64 running AMD64 Debian.
> For n=11, I get 4.960s for g++, 6.925s for OCaml and 10.062s for SBCL. So
> SBCL is less than half the speed of g++.
I noticed that both the OCaml and g++ benchmarks used the fastmath,
which isn't available in SBCL. That does make the whole thing seem a
bit apple-and-orangish to me.
Also, I doubt it matters, but why is "zero" defvar'd instead of
defconstant'd?
Cheers,
Pillsbury
·········@gmail.com writes:
> Also, I doubt it matters, but why is "zero" defvar'd instead of
> defconstant'd?
(defvar zero (vec 0d0 0d0 0d0))
Because the vector that can be built at compilation time, CANNOT be EQ
to the vector that is built at run time. (Given that compilation time
and run time might occur on different machines at different clock
times on different planets).
clhs defconstant:
If a defconstant form appears as a top level form, the compiler
must recognize that name names a constant variable. An
implementation may choose to evaluate the value-form at compile
time, load time, or both. Therefore, users must ensure that the
initial-value can be evaluated at compile time (regardless of
whether or not references to name appear in the file) and that it
always evaluates to the same value.
--
__Pascal Bourguignon__ http://www.informatimago.com/
ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.
Ken Tilton wrote:
Snip
> >
>
> Did you really want to write your own. Like I said, it is easy to call C
> and to a degree C++ from Lisp, so you could use ODE or Tokomak or something.
If you want to use an existing library (with-plug (:type :shameless)
You could use CL-ODE http://common-lisp.net/project/cl-ode/ ).
Ken Tilton wrote:
> Lisp is only 20% slower than C. It is also easy to call C from Lisp if
> that helps.
Of course the Lisp boat starts dragging the anchor as soon as a great
many calls are made to C using the FFI. For example using the native
line drawing functions in SDL_gfx are a LOT faster than implementing
the same function in Lisp and having to write to each pixel to an SDL
surface - a single FFI call to SDL_gfx versus many for each pixel
write.
However Lispworks at least provides alternatives in its native FFI that
CFFI does not. For example Lispworks provides a single function to copy
a Lisp array to a C array. I must still benchmark performing all pixel
'writes' in Lisp land and then block copying this buffer to the SDL
surface (if possible).
I seem to remember reading about Lispworks having a kind of hybrid
array that had one foot in Lisp and the other in C. So read/writes were
cheap from Lisp and the array could also be used directly by the C side
at the expense of some functionality on the Lisp side. I can't seem to
find this documented anywhere though.
+ ·······@gmail.com:
| I am new to Lisp so forgive me if this question is very noobish, but
| is Lisp and/or the functional paradigm a good way to implement a
| large physics system. Like a simulation engine ect. Especially if
| real time results are important.
I am not qualified to answer your question, but would like to point
out that "real time programming" means something different than just
throwing enough hardware at a problem. Just like in ordinary
programming, you need to be able to make guarantees of the form "input
X produces output Y", in real time programming you must be able to
guarantee "input X produces output Y within time T". This is a
guarantee you can usually not make, unless you run on an operating
system that is designed for such purposes. (QNX comes to mind. Maybe
there are others.) Or, I suppose, if your program just owns the CPU
alone, with no other process that might come along and compete for
resources. The obvious challenge for real time programming in any
language with garbage collection, is to have a garbage collector that
can be guaranteed not to take up more than some fixed percentage of
CPU time, even over short time periods. How short depends on the
requirements of your application.
But if your question is simply, "can Lisp be very fast?" then lots of
people here will jump up and down yelling "yes!".
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen wrote:
> + ·······@gmail.com:
>
> | I am new to Lisp so forgive me if this question is very noobish, but
> | is Lisp and/or the functional paradigm a good way to implement a
> | large physics system. Like a simulation engine ect. Especially if
> | real time results are important.
>
> I am not qualified to answer your question, but would like to point
> out that "real time programming" means something different than just
> throwing enough hardware at a problem. Just like in ordinary
> programming, you need to be able to make guarantees of the form "input
> X produces output Y", in real time programming you must be able to
> guarantee "input X produces output Y within time T". This is a
> guarantee you can usually not make, unless you run on an operating
> system that is designed for such purposes. (QNX comes to mind. Maybe
> there are others.) Or, I suppose, if your program just owns the CPU
> alone, with no other process that might come along and compete for
> resources. The obvious challenge for real time programming in any
> language with garbage collection, is to have a garbage collector that
> can be guaranteed not to take up more than some fixed percentage of
> CPU time, even over short time periods. How short depends on the
> requirements of your application.
>
> But if your question is simply, "can Lisp be very fast?" then lots of
> people here will jump up and down yelling "yes!".
>
> --
> * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
> - It is undesirable to believe a proposition
> when there is no ground whatsoever for supposing it is true.
> -- Bertrand Russell
Thx i think that answered my question.
On Fri, 06 Oct 2006 08:36:55 -0700, Omicron wrote:
>
> Harald Hanche-Olsen wrote:
>> + ·······@gmail.com:
>>
>> | I am new to Lisp so forgive me if this question is very noobish, but
>> | is Lisp and/or the functional paradigm a good way to implement a
>> | large physics system. Like a simulation engine ect. Especially if
>> | real time results are important.
>>
>> I am not qualified to answer your question, but would like to point
>> out that "real time programming" means something different than just
>> throwing enough hardware at a problem. Just like in ordinary
>> programming, you need to be able to make guarantees of the form "input
>> X produces output Y", in real time programming you must be able to
>> guarantee "input X produces output Y within time T". This is a
>> guarantee you can usually not make, unless you run on an operating
>> system that is designed for such purposes. (QNX comes to mind. Maybe
>> there are others.) Or, I suppose, if your program just owns the CPU
>> alone, with no other process that might come along and compete for
>> resources. The obvious challenge for real time programming in any
>> language with garbage collection, is to have a garbage collector that
>> can be guaranteed not to take up more than some fixed percentage of
>> CPU time, even over short time periods. How short depends on the
>> requirements of your application.
>>
>> But if your question is simply, "can Lisp be very fast?" then lots of
>> people here will jump up and down yelling "yes!".
>>
>> --
>> * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
>> - It is undesirable to believe a proposition
>> when there is no ground whatsoever for supposing it is true.
>> -- Bertrand Russell
>
> Thx i think that answered my question.
I'd just like to add that the time required to allocate memory in
languages without a garbage collector is not fully guaranteed either.
`malloc' will use some unknown amount of time before returning.
I believe one can pre-allocate memory (+ `dynamic-extent' - or was that
something else?), then turn off the GC (in SBCL at least) to improve the
"real-timeness" of things - but I've never experimented with this.
--
Lars Rune Nøstdal
http://lars.nostdal.org/
Lars Rune N�stdal <···········@gmail.com> writes:
> I believe one can pre-allocate memory (+ `dynamic-extent' - or was that
> something else?)
That effectively means "stack-allocated". But you can pre-allocate an
array to store your data if that makes sense for your program.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
·······@gmail.com writes:
> I am new to Lisp so forgive me if this question is very noobish, but is
> Lisp and/or the functional paradigm a good way to implement a large
> physics system. Like a simulation engine ect. Especially if real time
> results are important. One reason why i ask this question is because
> since hardware is becoming incresingly parrallel, it would make sence
> to use a language for which concurrency is not a big a issue as in
> forinstance c++ or java
Yes.
OO has been invented for simulation (Simula), and Lisp has the best OO
constructs (CLOS).
Moreover, to do physical simulation, I would go both way: numerical
and equational. When you need to simulate macro phenomenon, you can
easily switch to a symbolic simulation instead of keeping doing a
numerical simulation. Here Lisp will shine, since you can easily do
symbolic processing.
And finally, there have been several parallel lisp, and it would be
easy to add to Common Lisp abstractions to drive parallel hardware.
http://www.google.com/search?q=parallel+lisp&
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
·······@gmail.com wrote:
> I am new to Lisp so forgive me if this question is very noobish, but is
> Lisp and/or the functional paradigm a good way to implement a large
> physics system. Like a simulation engine ect. Especially if real time
> results are important.
Lisp is like a pulley , it can easily help you build faster than in
other language
I know. But it won't solve your problem for you, if you want realtime
physics you
really have to understand Physics very well . No language will help
you code
something that you don't understand yourself. Rigid body dynamics,
chosing your
solver like Euler, Runde Kutta 2 or 4 , buoyancy, handling collision
etc
are some of the problems you will face
Also the physics engine needs a lot of knowledge, time and dedication.
If you don't have all of those I suggest you take a look at :
http://www.newtondynamics.com/
It has a C inteface so no problem to interact with it from Lisp .
If you think you are ready to make your own Physics engine
probably http://www.ode.org/ who comes with source code
(FreeBSD licensed) will give you a good starting point.
>One reason why i ask this question is because
> since hardware is becoming incresingly parrallel, it would make sence
> to use a language for which concurrency is not a big a issue as in
> forinstance c++ or java
At present day with few processors synchronous function parallel model
and
asynchronous function parallel model are more than enaphe .
If you are interested in data parallel model that's still overkill but
definately
the future when ~10+ cores computers will be common.
Just out of curiosity what kind of app you have in mind?
If you're interested in games or any realtime simulation that mix
graphic and physics
than maybe you'll find this article interesthing
http://www.gamasutra.com/features/20060906/monkkonen_01.shtml
cheers
bobi
> Just out of curiosity what kind of app you have in mind?
> If you're interested in games or any realtime simulation that mix
> graphic and physics
> than maybe you'll find this article interesthing
> http://www.gamasutra.com/features/20060906/monkkonen_01.shtml
>
> cheers
> bobi
I was interested in real time simulation software. And if lisp or
functional programming as a whole, is a superior paradigm for this kind
of problem, than the traditional imperative approuch.
And thx your post was very helpfull.
AJ