help with numeric speed optimization
in [Lisp]
|
Prev: static typing
Next: Java is going to have closures.
From: Juho Snellman on 14 Aug 2006 14:08 Rob Thorpe <robert.thorpe(a)antenova.com> wrote: > The 'time' function seems not to work on MS windows SBCL, I imagine > fixing that isn't a priority. It works in the latest release, but you'll need to build that from source. Binaries aren't made for all platforms on every release. -- Juho Snellman
From: Ivan Boldyrev on 13 Aug 2006 22:56 On 9565 day of my life verec(a)mac.com wrote: > On 2006-08-12 21:49:58 +0100, Pierre THIERRY >>> static double piOver2() { >>> double sum = std::exp(-std::pow(-10.0, 2.0)) ; >>> sum += std::exp(-std::pow(10.0, 2)) ; >> For the sake of my curiosity, why do you calculate twice the same >> number? 10^2 == (-10)^2 > > Well spotted! Well, any modern compiler will calculate both values at compile time. And this "-" will help other people to understand your code. -- Ivan Boldyrev | recursion, n: | See recursion
From: Thomas A. Russ on 14 Aug 2006 17:57 verec <verec(a)mac.com> writes: > On 2006-08-12 20:33:51 +0100, pkhuong(a)gmail.com said: > > 1. Note that the call to TIME also tells you that your function was > > interpreted, not compiled. > > CL-USER 58 > (compile 'pi/2-opt) > ;;;*** Warning in PI/2-OPT: The definition of PI/2-OPT is already compiled. > PI/2-OPT > ((PI/2-OPT #<STYLE-WARNING 100B2BDF>)) > NIL > > It already was compiled :-( The function PI/2-OPT may have been compiled, but what you tested with TIME was the following: (time (dotimes (i 10000) (pi/2-opt))) and the DOTIMES loop is interpreted, not compiled. What I usually end up doing to get around that is to write some simple test function like so: (defun test (n) (dotimes (i n) (pi/2-opt))) and then make sure TEST is compiled. With dynamic linking, it also means that subsequent changes to the tested function can be timed without needing to recompile the TEST function. (time (test 10000)) -- Thomas A. Russ, USC/Information Sciences Institute
From: Rob Warnock on 14 Aug 2006 23:43 Thomas A. Russ <tar(a)sevak.isi.edu> wrote: +--------------- | verec <verec(a)mac.com> writes: | > On 2006-08-12 20:33:51 +0100, pkhuong(a)gmail.com said: | > > 1. Note that the call to TIME also tells you that your function was | > > interpreted, not compiled. | > | > CL-USER 58 > (compile 'pi/2-opt) | > ;;;*** Warning in PI/2-OPT: The definition of PI/2-OPT is already compiled. | > PI/2-OPT | > ((PI/2-OPT #<STYLE-WARNING 100B2BDF>)) | > NIL | > | > It already was compiled :-( | | The function PI/2-OPT may have been compiled, but what you tested with | TIME was the following: | (time (dotimes (i 10000) (pi/2-opt))) | and the DOTIMES loop is interpreted, not compiled. +--------------- Interesting. In CMUCL, TIME always compiles the form to be timed: cmu> (time (dotimes (i 100000000))) ; Compiling LAMBDA NIL: ; Compiling Top-Level Form: ; Evaluation took: ; 0.11f0 seconds of real time ; 0.11f0 seconds of user run time ; 0.0f0 seconds of system run time ; 200,529,433 CPU cycles ; 0 page faults and ; 0 bytes consed. ; NIL cmu> -Rob ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Paul Jones on 15 Aug 2006 12:44
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. We handle very large time series using Lisp, and are eternally thankful that we chose it for a language. We do use some routines for numerical computation that are not Lisp, but they're sure not Java either. They're carefully coded and optimized and then wrapped in Lisp wrappers. We have years of experience in using Lisp with (very large) time series for financial applications. If you'd like more pointers, let me know. > > 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 ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption =---- |