Prev: static typing
Next: Java is going to have closures.
From: Sidney Markowitz on 13 Aug 2006 17:11
verec wrote, On 14/8/06 2:06 AM:
> I'm amazed at the difference a compiler makes...

If you look at the recent thread in this newsgroup with subject "Squeezing
blood from a turnip" you will see a related discussion about getting better
performance in Lisp than C at counting bits in an integer.

What ended up being found is that the Common Lisp built in function logcount
was the fastest way do do it in SBCL, that the fastest C program to do it was
faster, that the implementation of logcount in SBCL was not using the fastest
algorithm that was known in C, and then coincidentally someone contributed a
faster logcount to the SBCL project and that made the Lisp version faster than
the C version.

An important point that you can get from my post to that thread is that you
can write your own compiler implementation of a function like logcount using
the SBCL macro define-vop, which allows you to write the assembler language
implementation of a function. So even if the bottleneck in your program is not
something that is part of the CL language definition such as logcount, you are
able to hand optimize it if it makes sense to do so. And you can evaluate a
define-vop form right at the REPL. You don't have to touch the compiler source
code to in effect make a patch to the the compiler.

If profiling shows that the bottleneck is a function that is part of Common
Lisp, you can give your improvements back to the project, if it is an open
source Lisp.

That means that if you have a very large program, once you have the algorithm
tweaked and you profile to find where the bottleneck is, you can go the extra
step of telling the compiler how to write fully optimized machine language for
a critical function in the inner loop, if there is such a function.

The advantage I have found in using Common Lisp instead of C for highly
optimized code is that it is much easier to make major changes to the
algorithm, which usually is the right way to get big improvements, before
dealing with low level tweaking.

--
Sidney Markowitz
http://www.sidney.com
From: patro on 13 Aug 2006 18:15
"verec" <verec(a)mac.com> wrote:

> Depending on the
> speed outcome, CL may get considered for the project that
> will be havy on mumeric computations.

Why use Lisp for numerical computations ?


patro
From: Pierre THIERRY on 13 Aug 2006 18:44
Le Mon, 14 Aug 2006 00:15:29 +0200, patro a écrit :
> Why use Lisp for numerical computations ?

Why not?

Curiously,
Nowhere man
--
nowhere.man(a)levallois.eu.org
OpenPGP 0xD9D50D8A

From: verec on 13 Aug 2006 19:30
On 2006-08-13 23:15:29 +0100, "patro" <patro(a)ortap.com> said:

>> Depending on the
>> speed outcome, CL may get considered for the project that
>> will be havy on mumeric computations.
>
> Why use Lisp for numerical computations ?

I said that the project was going to be heavy on numerical
computations, not that it was only about them.

The basic blocks (financial modelling on time series) are
fairly well defined. That's where the "raw speed" is needed
because the data samples are potentially _huge_, and the
computations not trivial. The math guy doesn't really care
which language is chosen, provided it is "fast enough", and
I'm pushing as hard as I can to avoid having to use Java
for the rest, because Java forces me to build too much
infrastructure/protocols that have to be almost entirely discarded
when the higher level requirements change.

The higher levels (what strategies to apply according to the
results of the models) are a lot less well defined, and it is
my beleif that changing our mind three times along the way about
what we really want is going to be less expensive and faster
in CL (than the daily nightmare of forcing new business requirements
into a three year old Java code base that was not meant for them.)

But in order to be able to change our minds, we need first
to see some results, hence experiment, hence my plea for using
CL
--
JFB



From: Rob Thorpe on 14 Aug 2006 13:52
Marcin 'Qrczak' Kowalczyk wrote:
> Pierre THIERRY <nowhere.man(a)levallois.eu.org> writes:
>
> > OK, I'm also significantly faster in Lisp... It took 1.7s even with -O3
> > for the C++ version (ten times with ten times iterations, so spawning
> > the process is quite lightweight, in fact), and 1.1s in Lisp
>
> Compile the C version with -ffast-math and do something to avoid
> optimizing out the whole computation (e.g sum the results and print
> the sum). It's twice faster than without -ffast-math on my box.

On the MS Windows machine I'm currently using:

Cygwin GCC 3.4.4 takes 19.5secs (with -O3 and --fast-math)
SBCL "kitten of death" takes ~23secs
GCL 2.6.1 takes 59secs

I'm impressed by how close SBCL gets to GCC. I'm also impressed at the
acrobatics needed to stop GCC from removing the calculation altogether
(as you say sum results + print sum).

The 'time' function seems not to work on MS windows SBCL, I imagine
fixing that isn't a priority.

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8
Prev: static typing
Next: Java is going to have closures.