- gsll-devel - mailman3.common-lisp.net

Re: [GSLL-devel] [PATCH] ode-system: 'next-step' should be exported
by Liam Healy 04 May '11

04 May '11

On Wed, May 4, 2011 at 2:18 PM, Matt Peddie <mpeddie(a)gmail.com> wrote: > Liam, > > On Wed, May 04, 2011 at 10:20:42AM -0400, Liam Healy wrote: > > Unless I'm misunderstanding this request, this is already possible, in > > fact I'd regard it as the basic usage. Perhaps you are thrown off by > > the with-ode-integration macro and example. > > Great! I followed the example to begin with, so that was my starting > point. > > > I made up this macro in order to easily accommodate the case of > > non-array usage in the ODE solvers, because I wanted to show a simple > > example with scalars. However if you look at how that macro expands, > > there is a symbol #:DEP that is bound to a foreign array with the > > appropriate dimensions: > > > > [ macro definition ] > > > > So what you want to do is mimic this form, but instead define your > > foreign array directly. Is this what you're asking about? If it's an > > issue of CL array vs. foreign array, then you can use #'cl-array or > > just copy it over at the beginning and end. > > Thanks. I saw the way that DEP works within the macro, and I rewrote it > a few times in an attempt to pass around the array directly and use > grid:gref inside my dynamics function. I guess I just need to try a few > more things (like I said, newbie here). I want to use the foreign array > and avoid copying. > > > P.S. Please join the mailing list to post. Thank you. > > I joined right after I got the `your message needs to be approved' mail; > sorry. > > Matt > Good. Having said all that, I think there is definitely room for a more meaningful and more general macro than with-ode-integration. Though I'd like GSLL to be easier to use than GSL, at least calling make-ode-stepper, make-y-control, make-ode-evolution, apply-evolution, etc. on your own isn't any worse than GSL. And the macro expansion is what I would use as a "tutorial"; I understand for a CL newcomer it's still a tough task. Liam

1 0

Re: [GSLL-devel] [PATCH] ode-system: 'next-step' should be exported
by Matt Peddie 04 May '11

04 May '11

Hi, On Fri, 8 Apr 2011 at 15:44:08, Fedor Bezrukov <Fedor.Bezrukov(a)physik.uni-muenchen.de> wrote: > Though one thing is definitely needed (I'll think of it when I have > some time) -- ability to make the function for the ode to get and > return the arguments as an array -- quite a common case if you want to > solve a large system of differential equations (eg, inital value > problem for an ODE) I'd really, really like to use this array functionality. I know nothing about CFFI and am a gsll newbie, but I'm willing to help if I can. Matt

2 2

[GSLL-devel] [GSD] Time making large foreign-arrays vs large arrays
by Sumant Oemrawsingh 03 May '11

03 May '11

Hi, I ran into a problem making foreign arrays. I have a two lists of lists of floats called *data-50* and *data-1024*, which are to be used as the initial contents of a matrix (first is 50x50, second 1024x1024). I do the following: CL-USER> (time (type-of (make-grid '((array) single-float) :initial-contents *data-50*))) Evaluation took: 0.000 seconds of real time 0.000000 seconds of total run time (0.000000 user, 0.000000 system) 100.00% CPU 228,096 processor cycles 27,744 bytes consed (SIMPLE-ARRAY SINGLE-FLOAT (50 50)) CL-USER> (time (type-of (make-grid '((foreign-array) single-float) :initial-contents *data-50*))) Evaluation took: 0.036 seconds of real time 0.026995 seconds of total run time (0.026995 user, 0.000000 system) 75.00% CPU 79,104,003 processor cycles 294,688 bytes consed MATRIX-SINGLE-FLOAT With a 50x50 array, everything works out fine. However, when moving to the 1024x1024 data: CL-USER> (time (type-of (make-grid '((array) single-float) :initial-contents *data-1024*))) Evaluation took: 0.036 seconds of real time 0.035995 seconds of total run time (0.034995 user, 0.001000 system) 100.00% CPU 80,301,650 processor cycles 4,194,320 bytes consed (SIMPLE-ARRAY SINGLE-FLOAT (1024 1024)) CL-USER> (time (type-of (make-grid '((foreign-array) single-float) :initial-contents *data-1024*))) Evaluation took: 686.167 seconds of real time 683.878034 seconds of total run time (683.608075 user, 0.269959 system) [ Run times consist of 0.196 seconds GC time, and 683.683 seconds non-GC time. ] 99.67% CPU 3 forms interpreted 1,502,208,488,440 processor cycles 59,838,352 bytes consed before it was aborted by a non-local transfer of control. ; Evaluation aborted on NIL. After over 10 minutes of intensive work, I gave up and aborted. When using make-foreign-array directly, instead of make-grid, I get the same problem. I would understand that foreign arrays take a bit more time to make; in the *data-50* example, about an order of magnitude more bytes were consed to make the foreign array (and needing more processor cycles). While this is not very thorough, I would expect there to be some linear relation between the array size and the time it takes. E.g. 50x50 foreign array takes less than a 0.1 second, so I would expect 1024x1024 to take less than 42.0 seconds. While that is still a long time for a normal-sized array, clearly, this is not the case. I can run some more tests later to find out where the problem lies. Or is this a known bug or limitation for foreign arrays and sbcl? Or am I just doing something wrong here? Thanks, Sumant -- Sumant Oemrawsingh

2 2

[GSLL-devel] [PATCH] ode-system: 'next-step' should be exported
by Fedor Bezrukov 08 Apr '11

08 Apr '11

I guess next-step should be exported --- ordinary-differential-equations/ode-system.lisp | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ordinary-differential-equations/ode-system.lisp b/ordinary-differential-equations/ode-system.lisp index 2e0490f..851b5ac 100644 --- a/ordinary-differential-equations/ode-system.lisp +++ b/ordinary-differential-equations/ode-system.lisp @@ -20,7 +20,7 @@ (in-package :gsl) -(export '(with-ode-integration)) +(export '(with-ode-integration next-step)) (defmacro with-ode-integration ((function time step-size max-time dependent dimensions -- 1.7.4.2

2 2

[GSLL-devel] FFT speed, tests
by Sumant Oemrawsingh 03 Apr '11

03 Apr '11

Hi Liam, Today, I had some time to take a look at the (slow) speed of the FFT tests. I found that having the tests as is and adding declarations only gives a speed-up of (barely) 10%. I think I'll need to thoroughly rewrite the tests to find/solve the problem. I need to do this anyway, since a small number of tests still keeps on failing and I haven't been able to track down _that_ problem yet. As such, I'll begin "from scratch", rewriting each test. This might take some time, and due to a shortage of that due to work-related things, this might take even longer than anticipated. This situation is quite annoying since, naturally, the FFT tests should be enabled in the gsll-tests package, and not only for completeness. I'll do my best allocating time to this. Regards, Sumant -- Sumant Oemrawsingh Sikander on #lisp

2 1

[GSLL-devel] gsll lives on clisp&cygwin -- better than ever
by Mirko Vukovic 23 Mar '11

23 Mar '11

Although most of my gsll work is on sbcl, I also have clisp running on top of cygwin on my old laptop. When connectivity to my sbcl at work is a problem I need to have gsll running on my laptop. I finally managed to coax gsll & friends to compile on the clisp+cygwin setup by loading the appropriate cygwin libraries, setting path, and a few read-time conditionals. Currently: - FSBV examples run - GSD grid tests pass - The vast majority of gsll's tests pass The full story on the cygwin setup and the gsll, gsd and fsbv modifications is in the attached html file. The three patch files are for fsbv, gsd and gsll. Liam, these patches also contain some permission changes (no clue why). If that causes problems, I can send you diffs for the files in question. Enjoy, Mirko

2 1

[GSLL-devel] ffi with gsll
by N J 26 Feb '11

26 Feb '11

Dear gsll-dev, I was unable to build gsll (through quicklisp) on my gentoo box today because of "missing ffi.h". After I filled a bug report* with gentoo they gave me the advice to use pkg-config --cflags-only-I libffi to get the right path to ffi. I am able to build gsll anyway but maybe this "tool" is something that could be incorporated into the build of gsll. Cheers, Niklas * http://bugs.gentoo.org/show_bug.cgi?id=348267#c1

2 1

[GSLL-devel] questions/requests on foreign-array
by Mirko Vukovic 17 Feb '11

17 Feb '11

I am trying to make my gsd-based code to work on both sbcl (which supports foreign-arrays) and clisp which does not. Hence the questions/requests: 1) Foreign-array creates the `static-vectors' feature. I want to double-check that I can use it to test if foreign-arrays is loaded or not (#+static-vectors or #-static-vectors). Or should I use #+sbcl, #+clisp 2) I use the mvector class from as a method specializer for some of my routines on sbcl. On clisp I use vector) Liam, please don't make mvector go away :-) 3) Could the #m reader macro be adapted to return CL vectors and arrays if foreign-arrays are not loaded?. That would simplify some of my testing routines, as the reader macro #+clisp has to expand #m before deciding not to use it. Right now, for clisp I plan to define a dummy #m macro that doesn't do anything meaningful, but allows the reader to expand into something, and then throw it away. Thanks, Mirko

2 2

[GSLL-devel] how to optimize grid mapping?
by Mirko Vukovic 05 Feb '11

05 Feb '11

Hello, I was wondering whether optimization can help grid-map's performance. (But I really have not done much optimizing). So, I timed the following two functions which map `sin' over a really large grid: (in-package :grid) (defun optimized (arg) (grid:map-grid :source arg :element-function #'(lambda (arg) (declare (optimize (speed 3) (safety 0) (debug 0)) (double-float arg)) (the double-float (sin arg)))) (values)) (defun unoptimized (arg) (grid:map-grid :source arg :element-function #'(lambda (arg) (sin arg))) (values)) (progn (defvar *arg* nil) (setf *arg* (grid:make-grid '((foreign-array 300000) double-float) :initial-element 1d0)) nil) On 64bit linux & SBCL, compilation of the optimized routine generate the following notes that I don't understand: ; note: unable to avoid inline argument range check ; because the argument range (DOUBLE-FLOAT) was not within 2^63 ; #'(LAMBDA (GRID::ARG) ; (DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0) (DEBUG 0)) ; (DOUBLE-FLOAT GRID::ARG)) ; (THE DOUBLE-FLOAT (SIN GRID::ARG))) ; ; note: doing float to pointer coercion (cost 13) to "<return value>" Timing both routines gives very similar results: GRID> (time (unoptimized *arg*)) Evaluation took: 0.112 seconds of real time 0.111983 seconds of total run time (0.110983 user, 0.001000 system) [ Run times consist of 0.004 seconds GC time, and 0.108 seconds non-GC time. ] 100.00% CPU 335,890,827 processor cycles 19,202,048 bytes consed GRID> (time (optimized *arg*)) Evaluation took: 0.113 seconds of real time 0.112983 seconds of total run time (0.111983 user, 0.001000 system) [ Run times consist of 0.003 seconds GC time, and 0.110 seconds non-GC time. ] 100.00% CPU 337,194,558 processor cycles 19,202,032 bytes consed Any ideas how to properly optimize the code? Thanks, Mirko

2 2

[GSLL-devel] iterate extensions and asdf-system-connections
by James Wright 09 Jan '11

09 Jan '11

Hi all, (I'm not sure whether or not this is the right place for questions about the grid system in gsd; apologies if I should be posting elsewhere.) Has anyone else found a reliable way to force the grid extension to iterate to load? I have a project that uses some of the various iterate extensions. Naturally its asdf system won't compile properly if the iterate extension is not loaded. There doesn't seem to be any way to ensure that the grid extension is loaded aside from making sure that the asdf-system-connections system has been loaded before I try to load my system. That means I need this ugly piece of work in my asd file, before my system definition: ;; We want to use the iterate extension for grid data (eval-when (:compile-toplevel :load-toplevel :execute) (require '#:asdf-system-connections)) Including :asdf-system-connections in the dependencies of my system is not sufficient, either because I can't control the order in which systems load, or for some deeper reason (I suspect that in fact asdf-system-connections needs to be fully loaded before asdf even starts thinking about my system). Would it be possible to include an asdf system in the grid project like the following? (asdf:defsystem grid-iterate-extension :depends-on (#:grid #:iterate #:alexandria) :components ((:module "grid-iterate" :pathname "" :components ((:file "iterate"))))) Then I could just include grid-iterate-extension in the dependencies for my asdf system and not have to go through any contortions to get asdf-system-connections loaded first. It has to go in its own file to be reliably found by asdf, which I recognize adds clutter, but I think it's wrong to have a dependency on asdf-system-connections that I can't express in my system definition. Thanks! James

2 1