typed compilation option again

23 views
Skip to first unread message

JCG

unread,
Jan 6, 2016, 12:32:13 PM1/6/16
to Racket Users
I alluded to a compilation option to enable/disable types, much in the way of

typed/racket

and

typed/racket/no-check.


In my foray into using Typed Racket, two performance issues persist, compilation speed and runtime speed of my hybrid code. The reasons why are clear and the fact that it works at all is great.

Not having that option to 'raco exe ...', I changed all my #lang lines in 40 files to:

#lang s-exp "mytyped.rkt"

That "mytyped.rkt" file contains:

---------------------------------------------------------------------
#lang racket

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; This permits flip-flopping between
; typed and typed/no-check
;
; Use one and comment the other
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Type checking active
#;(require typed/racket)
#;(provide (all-from-out typed/racket))

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Type checking inactive
(require typed/racket/no-check)
(provide (all-from-out typed/racket/no-check))
(define-syntax-rule (require/typed module-name ignored ...)
(require module-name))
(provide require/typed)
---------------------------------------------------------------------

I comment out the undesired section, enabling/disabling type checking. Using my test suite, here's how three programs compare in relation to compilation and execution time.

Previous untyped version:
Compilation time: 13 seconds
Execution time: 18 minutes

Hybrid version with type checking on:
Compilation time: 178 seconds
Execution time: 33 minutes

Hybrid version with type checking off:
Compilation time: 44 seconds
Execution time: 22 minutes

The executable in both hybrid versions is 16 megs, about double the untyped compiled size. Runtime memory use is similar across all three and proportional to the number of instantiated places. The result of this test is about 122,000 time series; they match output in all versions.

Note that mytyped.rkt includes a macro for an apparently missing require/typed form.

--------------------

One question that concerns me is whether the following statement is correct:

A typed program that does not have conditions based upon type predicates, e.g. port? or integer?, should act the same when stripped of its types.

---------------------

Anyway, this felt like too easy a way to get my hybrid performance back. If the Typed version actually ends up faster, then I'm set too. If anyone sees something faulty or improvable, I'm open to advice.

Thanks (again),
John Griffin


Sam Tobin-Hochstadt

unread,
Jan 6, 2016, 1:16:25 PM1/6/16
to JCG, Racket Users
On Wed, Jan 6, 2016 at 12:32 PM, JCG <griff...@gmail.com> wrote:
>
> One question that concerns me is whether the following statement is correct:
>
> A typed program that does not have conditions based upon type predicates, e.g. port? or integer?, should act the same when stripped of its types.

A typed program should _always_ act the same as one stripped of its
types, unless the generated contracts produce extra runtime errors in
the typed code. That's the goal of Typed Racket.

There are a few caveats here:
- contracts can change the eq? behavior of programs, which may change
other behavior (such as eq-based hash tables)
- contracts for polymorphic functions force parametric behavior,
which can change some badly-behaved programs to behave differently
- contract errors are obviously different behavior, which could be
caught or otherwise change the results of the program

Anything other than these sorts of issues related to the extra
contract wrapping would be a bug.

Sam
Reply all
Reply to author
Forward
0 new messages