Racket-on-Chez snapshot builds

[Matthew Flatt]

The Utah snapshot site now includes Racket-on-Chez builds for x86_64
Windows, Mac OS, and Linux:

http://pre.racket-lang.org/
-> follow the "University of Utah" link
-> scroll down to "Racket CS"

Although Racket-on-Chez is not yet ready to replace the existing
implementation of Racket for most purposes, it should generally work
now --- and it might even be useful for some purposes. Many, many
details have to be right for Racket-on-Chez to assemble itself into a
snapshot distribution, so this is a significant milestone.

Try it out. Report bugs at

https://github.com/racket/racket/issues


Here are some issues that we already know about:

* Load times can be slower.

* Compile times can be slower, including package installation.

* Errors that originate from Chez Scheme have non-Rackety messages.
Values in those error message can look especially strange.

* Not all `racket` command-line arguments are handled, yet.

* Not all core Racket tests pass, yet.

* No cross-compilation, yet.

* No single-precision flonums, no extflonums.

[Philip McGrath]

If you use Travis CI with Greg's wonderful https://github.com/greghendershott/travis-racket script, as of this morning you can build against the Racket-on-Chez snapshots by adding a "RACKET_VERSION" of "HEADCS" to your build matrix.

-Philip

--
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.
For more options, visit https://groups.google.com/d/optout.

[Matthew Butterick]

> On Nov 19, 2018, at 2:06 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
>
> Although Racket-on-Chez is not yet ready to replace the existing
> implementation of Racket for most purposes, it should generally work
> now --- and it might even be useful for some purposes. Many, many
> details have to be right for Racket-on-Chez to assemble itself into a
> snapshot distribution, so this is a significant milestone.

Thank you for the all your effort & hard work to get Racket-on-Chez this far.

This week, I've gone over to using the Racket-on-Chez snapshots exclusively. They are stable & fast enough for everything I do with Racket. There are bugs, of course, though so far all small. And Matthew has been fixing them as fast as I can file them.

For that matter, if you've ever wondered "what can I do to improve Racket-on-Chez, without being a 1337 h4x0r?" I suggest that you also use the snapshots and file bugs. Because that will make Racket-on-Chez better, sooner, for everyone.

One tip, if you haven't used the snapshots before (I hadn't): I've switched to installing my own packages in "--scope user" rather than "--scope installation". This keeps the packages out of the snapshot folder, so the snapshot can be easily replaced without disturbing the rest.

To infinity and beyond.

[Sanjeev Sharma]

I'm getting much faster startup times. 

And the initial freeze when loading a file after initial startup - is that actually faster or has it been amortized using lazy techniques?

[Alex Harsanyi]

I have updated the Travis build file for my application to use Racket-on-Chez

as one of the build configurations and, while the code builds and automated

tests pass, the performance is very poor.  I know that measuring times of

Travis builds is not exactly scientific, however, I have run these builds four

times and there is not much variations in the numbers.  Here is a summary of my

findings (Racket CS is the build from Dec 6, 2018):

* Racket CS runs out of memory when assembling a distribution (a "raco dist"

  command) -- my current build script runs the equivalent of "raco make",

  "raco exe" and "raco dist" from the same racket process, perhaps memory is

  not released?

* Build time for my application, "raco make", is 98 seconds for Racket 7.1 and

  187 seconds for Racket CS

* `df-test`, a test that runs mostly Racket code, has increased from

  approximatly 5 seconds in Racket 7.1 to about 14 seconds in Racket CS.

* `db-upgrade-test` is a test that mostly runs SQL code inside SQLite, the

  racket code just reads SQL statements and executes them.  This test runs in

  the same amount of time.

* the remaining tests, `db-test`, `trends-test` `aggregate-test` and

  `fit-test` all have running times that are about 50% larger in Racket CS

  when compared to Racket 7.1.  These test spend a significant amout of time

  running SQL code which has not changed in timing, so the performance drop of

  the Racket code is probably worse than that.

None of the above are actual performance tests -- they are meant to verify

that the application works correctly, they just happen to run for a long time

even in Racket 7.1 and they make perfromance problems show up more clearly.

I have summarized my results here:

https://docs.google.com/spreadsheets/d/1r1ZKtw4lDfv5xGXCfrOuE6jlCAMm0atMic4BfAnLLLw/edit?usp=sharing

You can also find the build logs below, Travis adds timings for each step and

the builds are 209, 210, 211 -- the first round in the spread sheet is a

restart of 209 and unfortunately Travis has not kept the logs for the original

build:

https://travis-ci.org/alex-hhh/ActivityLog2/builds

Is Racket-on-Chez built in debug mode?  The installation size for Racket CS is

1.9 Gb while the installation size for Racket 7.1 is approximately 0.5 Gb...

I have not installed and run Racket CS on my machine, so I don't know if the

final application runs and what the user level performance is.

Best Regards,

Alex.

[Matthew Flatt]

At Thu, 6 Dec 2018 17:27:31 -0800 (PST), Alex Harsanyi wrote:
> * Racket CS runs out of memory when assembling a distribution (a "raco dist"
> command) -- my current build script runs the equivalent of "raco make",
> "raco exe" and "raco dist" from the same racket process, perhaps memory is
> not released?

I'm seeing almost 2GB memory use for current Racket during the `raco
exe` step and 5GB with Racket CS. Neither of those numbers seems
reasonable, and I'll investigate more.

> * Build time for my application, "raco make", is 98 seconds for
> Racket 7.1 and 187 seconds for Racket CS

That's expected, at least. Compile times are that much longer in Racket
CS, generating machine code instead of bytecode.

> * `df-test`, a test that runs mostly Racket code, has increased from
> approximatly 5 seconds in Racket 7.1 to about 14 seconds in Racket CS.

Much of the difference here is load time. On my machine, it's 5 seconds
versus 10 seconds, where just loading "test/df-test.rkt" takes 3
seconds versus 7 seconds. Also, I think the loading effect is worse on
Windows, for reasons that I haven't yet tracked down.

Like compile time, load time has been a stubborn problem, but I'm
optimistic that we can improve load time.

> * the remaining tests, `db-test`, `trends-test` `aggregate-test` and
> `fit-test` all have running times that are about 50% larger in
> Racket CS when compared to Racket 7.1. These test spend a
> significant amout of time running SQL code which has not changed in
> timing, so the performance drop > of the Racket code is probably
> worse than that.

I tried "db-test.rkt", where it's 15 versus 25 to run and 5 versus 9 to
just load. I'm not immediately sure why running is slower, but my
initial guess is that the FFI adapter in Racket CS needs work.

> Is Racket-on-Chez built in debug mode? The installation size for
> Racket CS is 1.9 Gb while the installation size for Racket 7.1 is
> approximately 0.5 Gb...

That difference is machine code (uncompressed) versus bytecode.


Thanks for the report! There's plenty here for me to investigate.


Matthew