[gambit-list] Re: Scheme/C help request for code needed for Math paper

Bill Richter richter at math.northwestern.edu
Wed Jan 26 00:25:02 EST 2005


   you can speed up your code quite a bit simply by adding some
   declarations in your code....Something like this [say, at the top
   of 'Curtis-algorithm.scm']:

   (declare
     (standard-bindings)
     (fixnum)
     (not safe)
     (inline)
     (inlining-limit 1000)
     (block))

Thanks, Guillaume!!!  I'm getting 3 times faster!!! I did t = 0 to 51
in 41.1 minutes, in 2 stages:

;; t = 0--50 in 21.8 minutes.  
;; t = 51, in 19.3 minutes

My previous mark was 134.9 minutes, in 4 stages:

;;  t = 0--45,  489826 ms real time, 8.1 minutes
;;  t = 46--49  1510112 ms real time, 25.2 minutes 
;;  t = 50,    2484842 ms real time, 41.4 minutes
;;  t = 51    3613899 ms real time, 60.2 minutes

I have a suspicion that it goes faster to break it up into stages like
this, although I think that would be a failure of garbage collection.

That's fabulous!  Now I have a bunch of nitpicking technical stuff:

The Gambit manual was very clear about all these options, in the info
node "Miscellaneous extensions", especially as they have an example
similar to yours.  The one thing not explained is where best to stick
the `declare', but you advised me on that: at the very top.  Then it
applies to the whole file.  I suppose that's explained.

   Finally, if you want to simplify your build process, you could use
   'include' instead of 'load' in your files (except for that data
   file), and simply compile the code with:

   % gsc -dynamic Curtis-algorithm.scm

   then you try it with:

   % gsi Curtis-algorithm

Thanks, that was very helpful.  Three things I don't understand:

1) why I shouldn't include the data file "BZ" as well?  I changed the
name to BZ.scm and did include it.  I'm thinking it's related to:

2) I'm a little confused about the (block) declaration, which is about
mutation, and BZ.scm is full of mutation statements like

(vector-set!
 (vector-ref B-vec 3) 7
 '(((1 2 1) (2 3))
   ((2 1 1) (4 1))))

The Gambit info node says:

          In block compilation, the compiler assumes that global
          variables defined in the current file that are not mutated
          in the file will never be mutated.

If you include all the different files, then you really only have one
file, right?  Then you can always (block), since it's all just one
file, doesn't matter who mutates.  Isn't that what this means:

 - special form: include FILE
     The FILE argument must be a string naming an existing file
     containing Scheme source code.  The `include' special form splices
     the content of the specified source file.  This form can only
     appear where a `define' form is acceptable.

But I don't think I have any global variables that are mutated at all!
I certainly think (vector-set! ...) does mutation, but it's not
mutation of any global variables.   My interpretation is that only 

(set! some-global-variable foo)

will run you into block problems.

3) You're not saying that 

   % gsc -dynamic Curtis-algorithm.scm
   % gsi Curtis-algorithm

is essentially equivalent to 

   % gcc -O2 -L. -I. Curtis-algorithm.c Curtis-algorithm_.c -lgambc
   % a.out

I didn't find the Gambit manual clear on this point.  

Also, I couldn't run your profiler with gsc/gcc/a.out.  Your profiler
seems to need load rather than include, as in my file
profile-Curtis.scm, based on your example.scm:

	 #!/rhome/richter/my-gambit/bin/gsi-script

	 (load "statprof.scm")

	 (define (main)

	   (profile-start!)
	   (load "Curtis-algorithm.scm")
	   (profile-stop!)

	   (write-profile-report "prof-CA"))

So I tried:

   % gsc Curtis-algorithm statprof profile-Curtis 

   % gcc -O2 -L. -I. -o prof.out Curtis-algorithm.c statprof.c profile-Curtis.c profile-Curtis_.c -lgambc

and it did not create the directory "prof-CA".   Neither did this: 

   % gsc -dynamic Curtis-algorithm statprof profile-Curtis 

   % gsi Curtis-algorithm statprof profile-Curtis

The only thing that worked was 

   % gsi Curtis-algorithm.scm statprof.scm profile-Curtis.scm

But I'd really like to run your profiler on compiled jobs.  Otherwise
it may not run fast enough to run at all.  Your profiler will I
imagine give different ratios for different values of t.


I used your profiler for Min_t = 0 & Max_t = 45, and got a smaller
denominator 33982 than you did, and using my Emacs-kludge technique
from to calculate that Mono-left-lex got 62% of the hits.

(+ 3982 874 652 2276 2544 5356 1094 1076 3362)
21216
(/  21216.0 33982)
0.6243305279265493

But what's more interesting to me is that Poly-simplify, which I had
made an accumulator version, only got 1% of the hits.  Maybe that's
because the accumulator is so efficient, but I bet doesn't it make
much difference either way.   Your profiler will tell me!

(+ 24 6 55 6 75 22 45 45 86 39 50)
(/  453.0 33982)
0.013330586781237126

-- 
Best,
Bill 


More information about the Gambit-list mailing list