Any ideas?

#lang racket
(require racket/draw racket/class pict)

(define font (make-object font% 100. 'roman 'slant 'bold))

(dc (λ (dc x y)
      ; Sanity check: make sure we have the identity transformation
      (displayln (send dc get-transformation))
      ; Make a path with the outline of "Racket".
      ; The call places the top left at 0 0.
      (define p (new dc-path%))
      (send p text-outline font "Racket" 0 0 #f)
      ; Let's check the bounding box:
      (define-values (left top w h) (send p get-bounding-box))
      (displayln (list 'bbox 'left-top left top 'wh w h))
      )
    1 1)

; #(#(1.0 0.0 0.0 1.0 0.0 0.0) 0.0 0.0 1.0 1.0 0.0)
; (bbox left-top -3.02734375 5.125 wh <tel:288.7890625\|288.7890625> 71.390625)

; Huh? The top left is not (0,0) ?!

how significant is FFI overhead? Is it reasonable to use a C math lib?

(I know racket has its own math lib, but the stated x50 slowdown in untyped racket seems a bit too much)

Where is the x50 slow down mentioned?

Here? https://docs.racket-lang.org/math/array.html?q=math

That comment is for array indexing only (but that’s bad enough).

@samth Do you know whether things have been improved in the mean time? (I think that comment is several years old).

Wrt to the FFI question. It depends on how you use it. What takes time is crossing the boundary between Racket and C. If the time actually spent in C is small, then you will see a large slowdown (and vice versa).

what does indexing mean in this context? I’d assume it’d happen on any matrix multiplication, no?

Actually no. The matrix library is implemented in Typed Racket, so inside the matrix library indexing is fast.

What takes some time is going from untyped (normal) Racket (R) to Typed Racket (TR). On the boundary it is checked that the value from R actually is the type that the TR functions expects as input.

Normally these checks are fast, but for -reasons- arrays are tricky.

Inside a TR module (such as the matrix library) the type checker knows that all values have the correct types, so there is no checking at runtime.

For most of the math library (the special functions, number theory, statictics etc.) there are no problems.

But perhaps you need matrices specifically?

If you want to experiment with a FFI matrix library, I can dig one up. Then you can benchmark.

Also if you can code the “inner loop” portion of your program in TR you can avoid the checking costs.

uhh I’m debating on how to implement bits and pieces of reusable code in context of making a game, and code would probably jump alot between entity’s logic update or render inside the loop (eg calculating camera transform matrix for the object, or things like updating positino = velocity * delta etc) and the place where math operations are actually implemented. Since I want it to be reusable, I don’t want to use my own written stuff, since that’d mean either imposing user to use it everywhere or write converter. Two options I see are either use math stuff provided by the lib I’m already using for graphics, or use racket’s math lib.

I hoped there would be a straightforward answer of FFI vs TR boundary thing, but if there’s not then I’ll think I’ll experiment with it myself

No easy answer.