Prev: static typing
Next: Java is going to have closures.
From: Rob Thorpe on 15 Aug 2006 13:40
Paul Jones wrote:
> On 2006-08-14 01:30:26 +0200, verec <verec(a)mac.com> said:
>
> > 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.
> >
> > 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.
> Speaking from experience, it's really not at all about how fast a
> language can do one sort or another of numerical floating point
> arithmetic. With huge data samples, it's about how the data are
> organized and what types of methods are used to access them.

I'd agree with that. The example program given isn't a particularly
good one.
Most programs that use floating point iterate over large data
structures to read the data they need and output the results. The
optimization of these data structures is often the most important part.

In the SPECfp2000 floating point benchmark set there are now few
benchmarks that make great use of the floating point capabilities of
the processor. Most test the capabilities of the memory subsystem to
access regularly structured data. This is because the benchmarks are
built to be typical of fp applications and this is what fp applications
today do.

From: verec on 19 Aug 2006 11:24
Thanks to all for your replies. It helped win the case: we're
using Lisp for the project! Yeap! BTW: the math guy apologized:
the reason that the initial pi/2 wasn't very accurate (15% off
or so) is that the formula he gave me was for (sqrt pi), not
(/ pi 2) ...

CL-USER 11 > (defun pi/2-opt4 () ;;; formula for (sqrt pi) not for (/ pi 2) !!
(declare (optimize (speed 3) (safety 0) (debug 0) (float 0)))
(loop with sum of-type double-float = #.(realpart (+ (exp (- (expt
-10.0d0 2.0d0)))
(exp (- (expt
10.0d0 2.0d0)))))
for x of-type double-float from -9.99d0 below 10.0d0 by 0.01d0
do (incf sum (* 2d0 (exp (- (realpart (expt x 2.0d0))))))
finally (return (* sum 0.005d0))))

CL-USER 12 > (pi/2-opt4)
1.7724538509055174D0

CL-USER 13 > (sqrt pi)
1.7724538509055159D0

CL-USER 14 > (/ pi 2)
1.5707963267948966D0

Many thanks again.
--
JFB

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