Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

With the recent improvements by Phil, the rank of the syntax object variant moves up from 26th to the second (what?!?), losing only to c++ / g++. Moreover, it's significantly faster than the third place. On Fri, Mar 5, 2021 at 3:29 AM philngu...@gmail.com < philnguyen0...@gmail.com> wrote: > Oh

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

Oh I see. So one problem is here that `match-define` expands to `match` with an implicit error case, which at the low level, isn't distinguished from a user-written second case, and the tag check can't just be eliminated. On Thursday, March 4, 2021 at 9:40:22 AM UTC-8 Sam Tobin-Hochstadt wrote:

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

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

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

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

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

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

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

For what it's worth, I ran my own benchmark on Racket 8.0 and Racket 8.0.10 (current), and current is between 50 and 100% faster for certain operations. There must have been some optimizations done recently to current. Dex On Tuesday, March 2, 2021 at 9:37:29 AM UTC+1 wanp...@gmail.com

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

I previously came out with a version that converts a BF program directly into a module, which has received some optimization contributions from Matthew Flatt. Got some pretty good results. Execute bench.b in cpu time: 1542 ms, (2.2s include compile time). And mandel.b in cpu time: 3851 ms, (7s

Re: [racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

When Chez is faster than Racket CS, the usual culprits are either: - mutable pairs - very large code size that causes Racket CS to interpret the outer module However, neither of those seem to be happening here. Sam On Mon, Mar 1, 2021 at 2:39 AM philngu...@gmail.com wrote: > > There’s this

[racket-users] Racket slower than Chez Scheme on interpreter benchmark, potential low hanging fruit?

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