[racket-users] Re: “If you could have a wish granted, what would you like to see next in Racket?”
Faster load time and less memory consumption. -- 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/d4ffd31c-ba5a-442b-8483-ea4253af998an%40googlegroups.com.
[racket-users] Re: Racket CS release plan
I noticed that the size of the CS version is 244% compare to BS version. Wondering why it became so large. Does that mean Chez Scheme runtime/vm 100 MB larger than the original one? Racket Mac OS X 64-bit Intel 116.7 MB SHA1: 521b5a264afcfb3f390afacc682987268f650a25 Racket CS Mac OS X 64-bit Intel 285.8 MB SHA1: 060f311fc6621c5797a62f98b743499fa4277793 https://pre-release.racket-lang.org/ Matthew Flatt 在 2020年7月30日 星期四下午8:46:42 [UTC+8] 的信中寫道： > With the improvements in the upcoming v7.8 release, Racket CS provides > all of the functionality of Racket BC (the current default > implementation). Also, end-to-end performance measurements > increasingly favor Racket CS. For example, Racket CS now builds a > distribution slightly faster and in slightly less memory than Racket > BC: > > https://build-plot.racket-lang.org/ > > https://build-plot-cs.racket-lang.org/ > > It's time to consider shifting the Racket release to use Racket CS as > the default --- while Racket BC will remain an option for a long time > to come. > > We (the release managers) propose the following rule to trigger the > switch to Racket CS in the default distribution: > > Between this release and the next, if Racket CS testing and use > uncover no bugs that are more serious than ones typically discovered > for Racket BC, then Racket CS becomes the default for the next > release. > > At the earliest, the switch would happen with the release *after* the > soon-to-be-released v7.8. Our expectation is that the switch would > happen with the next release (in October), but we'll see how that > expectation lines up with reality. > > This rule is somewhat subjective, in that "more serious" and "typical" > are in the eye of the beholder, but we keep a close eye on the results > of the pkg-build service as well as Racket tests. We'll also count > performance problems as bugs, so Racket CS must not have substantial > known performance problems relative to Racket BC. > > Jay, John, Matthew, Matthias, Robby, Ryan, Sam, and Vincent > (the release managers) > > -- 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/7f6672e4-449d-4bda-b737-a45e9ee8dc97n%40googlegroups.com.
[racket-users] Strange performance behavior
I was working on a exercism problem named Raindrops. Problem description: Convert a number to a string, the contents of which depend on the number's factors. If the number has 3 as a factor, output 'Pling'. If the number has 5 as a factor, output 'Plang'. If the number has 7 as a factor, output 'Plong'. If the number does not have 3, 5, or 7 as a factor, just pass the number's digits straight through. I came out with two version. ; version 1 (define (convert n) (define pling (divides? 3 n)) (define plang (divides? 5 n)) (define plong (divides? 7 n)) (if (or pling plang plong) (string-append (if pling "Pling" "") (if plang "Plang" "") (if plong "Plong" "")) (number->string n))) ; version 2 (define (convert n) (define table '((3 . "Pling") (5 . "Plang") (7 . "Plong"))) (define result (for/list ([(k v) (in-dict table)] #:when (divides? k n)) v)) (if (empty? result) (number->string n) (string-append* result))) (require math/number-theory) I thought version 1 would be faster, but it turned out to be wrong. Running with raco test got following timing information. version 1 cpu time: 9 real time: 9 gc time: 9 version 2 cpu time: 0 real time: 0 gc time: 0 Then I ran both version in DrRacket, both output following result. cpu time: 0 real time: 0 gc time: 0 It's strange, isn't it? -- 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/46592171-c357-4897-af1a-bea91c838cacn%40googlegroups.com.
Re: [racket-users] Strange performance behavior
Thanks, that make sense! One more thing which bothers me is if I put a (collect-garbage) in front of the testing, I got gc time: 0 if not I got gc time: 9. Why can't 1 gc reclaim all memory during execution while it can before executes? Sam Tobin-Hochstadt 在 2020年8月5日 星期三下午11:44:21 [UTC+8] 的信中寫道： > What's happening here is that your function takes effectively 0 time, > but when you ran the first version, there was a GC pause during it > (that's why there's the "gc time: 9" there). GC pauses can happen at > any time, basically, so it's not something about what your function is > doing. > > Here's a benchmark of your two functions that takes long enough to run > that it avoids some of these issues, and also runs a GC before > benchmarking: https://gist.github.com/7cb4645308d8572e2250833ef7b90b7c > > On my machine, I get 40 ms for version 1, and 100 ms for version 2, as > you expected. > > Sam > > On Wed, Aug 5, 2020 at 11:21 AM wanp...@gmail.com > wrote: > > > > I was working on a exercism problem named Raindrops. > > > > Problem description: > > Convert a number to a string, the contents of which depend on the > number's factors. > > > > If the number has 3 as a factor, output 'Pling'. > > If the number has 5 as a factor, output 'Plang'. > > If the number has 7 as a factor, output 'Plong'. > > If the number does not have 3, 5, or 7 as a factor, just pass the > number's digits straight through. > > > > I came out with two version. > > > > ; version 1 > > (define (convert n) > > (define pling (divides? 3 n)) > > (define plang (divides? 5 n)) > > (define plong (divides? 7 n)) > > (if (or pling plang plong) > > (string-append (if pling "Pling" "") > > (if plang "Plang" "") > > (if plong "Plong" "")) > > (number->string n))) > > > > ; version 2 > > (define (convert n) > > (define table '((3 . "Pling") (5 . "Plang") (7 . "Plong"))) > > (define result (for/list ([(k v) (in-dict table)] #:when (divides? k n)) > v)) > > (if (empty? result) (number->string n) > > (string-append* result))) > > > > (require math/number-theory) > > > > I thought version 1 would be faster, but it turned out to be wrong. > Running with raco test got following timing information. > > > > version 1 > > cpu time: 9 real time: 9 gc time: 9 > > version 2 > > cpu time: 0 real time: 0 gc time: 0 > > > > Then I ran both version in DrRacket, both output following result. > > cpu time: 0 real time: 0 gc time: 0 > > > > It's strange, isn't it? > > > > -- > > 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/46592171-c357-4897-af1a-bea91c838cacn%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/e7d0d239-1b36-4e7d-a93d-7dbdfcbcc04en%40googlegroups.com.
