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