[MLton-devel] Fwd: C back end for MLton

[Brad Lucier]

> That would be good.  Could you please mail the scheme code you are
> comparing with?  Thanks.

(define pseudoknot-domains
  (list
   (reference rA  23   )
   (wc-Dumas  rU   8 23)
   (helix3*   rG  22 23)
   (wc-Dumas  rC   9 22)
   (helix3*   rG  21 22)
   (wc-Dumas  rC  10 21)
   (helix3*   rC  20 21)
   (wc-Dumas  rG  11 20)
   (helix3*   rU* 19 20);<-.
   (wc-Dumas  rA  12 19);  | Distance
;                       ;  | Constraint
; Helix 1               ;  | 4.0 Angstroms
   (helix3*   rC   3 19);  |
   (wc-Dumas  rG  13  3);  |
   (helix3*   rC   2  3);  |
   (wc-Dumas  rG  14  2);  |
   (helix3*   rC   1  2);  |
   (wc-Dumas  rG* 15  1);  |
;                       ;  |
; L2 LOOP               ;  |
   (P-O3*     rUs 16 15);  |
   (P-O3*     rCs 17 16);  |
   (P-O3*     rAs 18 17);<-'
;
; L1 LOOP
   (helix3*   rU   7  8);<-.
   (P-O3*     rCs  4  3);  | Constraint
   (stacked5* rU   5  4);  | 4.5 Angstroms
   (stacked5* rC   6  5);<-'
   ))

; Pseudoknot constraint

(define (pseudoknot-constraint? v partial-inst)
  (case (var-id v)
    ((18)
     (let ((p   (atom-pos nuc-P (get-var 19 partial-inst)))
           (o3* (atom-pos nuc-O3* v)))
       (FLOAT<= (pt-dist p o3*) 4.0)))
    ((6)
     (let ((p   (atom-pos nuc-P (get-var 7 partial-inst)))
           (o3* (atom-pos nuc-O3* v)))
       (FLOAT<= (pt-dist p o3*) 4.5)))
    (else
     #t)))

(define (pseudoknot)
  (search '() pseudoknot-domains pseudoknot-constraint?))

(define (var-most-distant-atom v)

  (define (distance pos)
    (let ((abs-pos (tfo-apply (var-tfo v) pos)))
      (let ((x (pt-x abs-pos)) (y (pt-y abs-pos)) (z (pt-z abs-pos)))
        (FLOATsqrt (FLOAT+ (FLOAT* x x) (FLOAT* y y) (FLOAT* z z))))))

  (maximum (map distance (list-of-atoms (var-nuc v)))))

(define (sol-most-distant-atom s)
  (maximum (map var-most-distant-atom s)))

(define (most-distant-atom sols)
  (maximum (map sol-most-distant-atom sols)))

(define (maximum lst)
  (let loop ((m (car lst)) (l (cdr lst)))
    (if (null? l)
      m
      (let ((x (car l)))
        (loop (if (FLOAT> x m) x m) (cdr l))))))

(define (run)
  (most-distant-atom (pseudoknot)))

(define (main . args)
  (run-benchmark
    "nucleic"
    nucleic-iters
    (lambda () (run))
    (lambda (result)
      (and (number? result)
           (let ((x (FLOAT/ result 33.797594890762724)))
             (and (FLOAT> x 0.999999) (FLOAT< x 1.000001)))))))

If this isn't enough to figure out what's going on, then I put nucleic.scm
and prefix-gambit.scm at

http://www.math.purdue.edu/~lucier/{nucleic,prefix-gambit}.scm

> Actually, it occurs to me that it is easier for a quick comparison for
> you to delete code than for me to add it.

I'm not concerned about the extra run time, I'd just like to make sure
that the codes are computing the same thing.

> As to gcc optimization -- sure, it may have improved.  But, there are
> some fundamental limitations to compiling to C and using gcc that will
> always make it harder to do as well as a well-written native backend.
> On example is the much better aliasing information that our native
> backend has.

If the conclusions will always be "C back ends are worse than native back
ends" and/or "gcc is buggy", then tell me now and we can stop wasting
time discussing it.  My guess is that MLton doesn't have deterministic finite
automata models of x86 processor execution in its native back end,
or any number of other optimizations, that gcc has.

> Getting back to priorities, I would rate it as *much* more important
> to port the C codegen to other archs than to squeeze another 10% out
> (via command-line switches, computed gotos, whatever ...).  It looks
> like we're in agreement there.

Playing with command-line switches is, of course, one or two orders of
magnitude easier than implementing computed gotos.

> > I'd be interested in this.  Unfortunately, I'd have to learn ML to
> > be effective at all.  (I'm a Schemer, I was trying to keep my experiments
> > in ML quiet. ;-)
> 
> Ve half spice efryver.

I was worried about that ;-).

Brad


-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel