I think there are two reasons that code gets slower. 1. The `match-define` includes pair and struct checks, which are omitted for plain accessor uses because of the unsafe declaration. 2. That use of `match` expands to `define-values` which ends up as a `call-with-values` and a `case-lambda` at the chez layer and is not removed.
`match` could recognize that it's being compiled with unsafe mode and omit these checks, although it's not that straightforward. Also schemify (or Chez) could do more to eliminate the use of multiple values, although that's hard without eliminating the failure cases. Sam On Thu, Mar 4, 2021 at 3:23 AM philngu...@gmail.com <philnguyen0...@gmail.com> wrote: > > Thanks for the tip about PLT_CS_COMPILE_LIMIT! I submitted a revision to the > syntax object variant that incorporated sleepnova's and yjqww6's improvements. > > Also, I never knew about `(#%declare #:unsafe)` until I saw yjqww6's pull > request. It makes a noticeable difference. One unsatisfying thing is that in > one place, if I replace the 4 separate define clauses with just > `(match-define (cons (op o val) rst) parsed)`, the benchmarks are more than > twice slower. > > On Wednesday, March 3, 2021 at 11:12:30 AM UTC-8 Sam Tobin-Hochstadt wrote: >> >> First, there's no longer a difference because yjqww6 just had a PR >> merged that improves the Racket performance. >> >> The performance difference that was there was mostly because the Chez >> code was run with `--optimize-level 3` which turns off safety. If that >> was changed to `--optimize-level 2` the timing became much slower. >> >> Sam >> >> On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com >> <philngu...@gmail.com> wrote: >> > >> > There’s this benchmark on BF interpreter where the Racket and Chez Scheme >> > implementations are very similar, but Chez Scheme is much faster than >> > Racket 8.0 at interpreting bench.b (3s vs 8s) and mandel.b (40s vs 136s). >> > >> > There’s the “Racket (Syntax Object)” variant that directly parses BF’s >> > syntax into Racket syntax object, which is faster (3.7s for bench, 82s for >> > mandel), but still significantly behind Chez Scheme’s naive interpreter. >> > >> > Profiling doesn’t give very illuminating results, saying most of the cost >> > is from interpreting BF’s loop instruction. >> > >> > Given that Racket is on Chez, could this benchmark reveal some low hanging >> > fruit for improving Racket’s performance? >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Racket Users" group. >> > To unsubscribe from this group and stop receiving emails from it, send an >> > email to racket-users...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/racket-users/83b2819d-8295-4769-944d-fa0c155976dan%40googlegroups.com. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/a5e77286-68b8-481a-8dea-0f547c5ce968n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAK%3DHD%2BbSp%3Dg-POJ7v9HUksw5WivY6_RbsPSnGv8B6PwfSYZs1A%40mail.gmail.com.
