[racket-users] Re: Seeking a graphviz like, diagramming language for Racket
Mermaid (https://github.com/knsv/mermaid) is a useful alternative to GraphViz for the cases in which it specializes. If you're working on your own diagramming DSL, you may want to look at these for inspiration: * Diagrams for Haskell (https://archives.haskell.org/projects.haskell.org/diagrams/); * CL-DOT for Common Lisp (http://foldr.org/%7Emichaelw/projects/cl-dot/). CL-DOT generates DOT files. Its graph examples are impressively concise. It's under 500 SLOC, but seems to heavily use CLOS, so a Racket translation wouldn't be quite straightforward. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Re: Racket Web servlet performance benchmarked and compared
On Saturday, September 2, 2017 at 8:46:54 PM UTC+3, Piyush Katariya wrote: > Does Racket app make use of all CPU cores by having multiple processes ? Thanks for asking this question. It prompted me to revise how the benchmark is run. The short answer is that the servlet application uses a single core. The SCGI application is the same way, but benefits from nginx's built-in support for multicore through worker processes. I've made the servlet application use futures according to Jay McCarthy's post at https://lists.racket-lang.org/users/archive/2014-July/063419.html, but found that, as he predicted, it did not improve the performance (in fact, it reduced it). I don't know straight away how to implement places-based workers for servlets. I may investigate it later (I'm interested in message-passing parallelism), but my primary intention with this project is to measure the performance a developer gets out of existing, reusable, hopefully already debugged libraries and frameworks. A little custom code and configuration is fine, but a custom work scheduler seems to me to go beyond that. Does a library exist for running servlets in places? I've also experimented with having nginx load balance between two Racket SCGI instances. The result was somewhat better throughput (~2650 req/s instead of ~2300 req/s) and identical latency when the application had two cores to work with, and worse throughput (~1800 req/s) and latency with only one. As far as fairness goes, I don't think either a strictly single-core or a use-them-if-you-can multi-core benchmark is clearly unfair. Both types have value. After some consideration, I've decided to commit to single-core (sort of — read on) as the default for this benchmark. My first solution was to limit the VM in which I ran the benchmarks to a single core, but that lead to ApacheBench and the application competing for CPU time. This would take the benchmark further away from the real world, and it is generally not recommended to have the benchmarked application and the load generator share a CPU. I've tried a few solutions, and the best I have found in terms of how the resources are allocated is to bind each of the two containers (the application and ApacheBench) to a separate CPU core. That way the applications get only one core, but don't have to fight for it with ApacheBench. I've pushed this update to the repository. Here are some numbers for the three configurations: one core, two cores, and one core per container. -- 1 shared core results/caddy.txt -Requests per second:2312.93 [#/sec] (mean) results/compojure.txt -Requests per second:1677.89 [#/sec] (mean) results/flask.txt -Requests per second: 977.33 [#/sec] (mean) results/guile.txt -Requests per second:1508.77 [#/sec] (mean) results/plug.txt -Requests per second:2335.21 [#/sec] (mean) results/scgi.txt -Requests per second:2163.00 [#/sec] (mean) results/sinatra.txt -Requests per second: 317.75 [#/sec] (mean) results/stateful.txt -Requests per second: 494.55 [#/sec] (mean) results/stateless.txt -Requests per second: 584.34 [#/sec] (mean) -- 2 shared cores results/caddy.txt -Requests per second:4358.68 [#/sec] (mean) results/compojure.txt -Requests per second:4730.50 [#/sec] (mean) results/flask.txt -Requests per second:1140.01 [#/sec] (mean) results/guile.txt -Requests per second:2092.78 [#/sec] (mean) results/plug.txt -Requests per second:5235.78 [#/sec] (mean) results/scgi.txt -Requests per second:3074.15 [#/sec] (mean) results/sinatra.txt -Requests per second: 329.35 [#/sec] (mean) results/stateful.txt -Requests per second: 604.30 [#/sec] (mean) results/stateless.txt -Requests per second: 687.77 [#/sec] (mean) -- 2 fixed cores (one for "benchmarked", one for "ab") results/caddy.txt -Requests per second:3963.03 [#/sec] (mean) results/compojure.txt -Requests per second:2513.05 [#/sec] (mean) results/flask.txt -Requests per second:1207.77 [#/sec] (mean) results/guile.txt -Requests per second:2133.48 [#/sec] (mean) results/plug.txt -Requests per second:4322.55 [#/sec] (mean) results/scgi.txt -Requests per second:2406.02 [#/sec] (mean) results/sinatra.txt -Requests per second: 347.89 [#/sec] (mean) results/stateful.txt -Requests per second: 573.48 [#/sec] (mean) results/stateless.txt -Requests per second: 658.67 [#/sec] (mean) -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] unit of current-thread-initial-stack-size value
Yes, it's effectively in words (so 8 bytes on a 64-bit platform, 4
bytes on a 32-bit platform), since the count refers to Racket values
that are represented by pointers.
You can set the value to be a small as you want, since the stack is
grown as needed, but even the simplest program will need a dozen or so
words.
At Sun, 3 Sep 2017 15:23:30 -0400, Greg Hendershott wrote:
> Empirically it seems to be 8-byte words?
>
> Unless I made a mistake:
>
> #lang at-exp racket/base
>
> (require racket/format)
>
> (define (current-custodian-memory-use)
> (for ([_ (in-range 3)]) (collect-garbage))
> (current-memory-use (current-custodian)))
>
> (define (f v)
> (parameterize ([current-thread-initial-stack-size v]
> [current-custodian (make-custodian)])
> (define ch (make-channel))
> (thread
> (λ ()
>(channel-put ch (current-custodian-memory-use
> (channel-get ch)))
>
> (f 1024) ;=> 12944
> (f 2048) ;=> 21136
> (f 4096) ;=> 37520
>
> (define (diff v1 v2)
> (define f1 (f v1))
> (define f2 (f v2))
> @~a{Initial stack sizes of @v1 and @v2
> seem to consume @f1 and @f2 bytes respectively.
> Diff in stack sizes is @(- v2 v1).
> Diff in memory is @(- f2 f1).
> Factor is @(/ (- f2 f1) (- v2 v1)) bytes.})
>
> (displayln (diff 2048 4096))
> ;; Initial stack sizes of 2048 and 4096
> ;; seem to consume 21136 and 37520 bytes respectively.
> ;; Diff in stack sizes is 2048.
> ;; Diff in memory is 16384.
> ;; Factor is 8 bytes.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
--
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.
For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] unit of current-thread-initial-stack-size value
Empirically it seems to be 8-byte words?
Unless I made a mistake:
#lang at-exp racket/base
(require racket/format)
(define (current-custodian-memory-use)
(for ([_ (in-range 3)]) (collect-garbage))
(current-memory-use (current-custodian)))
(define (f v)
(parameterize ([current-thread-initial-stack-size v]
[current-custodian (make-custodian)])
(define ch (make-channel))
(thread
(λ ()
(channel-put ch (current-custodian-memory-use
(channel-get ch)))
(f 1024) ;=> 12944
(f 2048) ;=> 21136
(f 4096) ;=> 37520
(define (diff v1 v2)
(define f1 (f v1))
(define f2 (f v2))
@~a{Initial stack sizes of @v1 and @v2
seem to consume @f1 and @f2 bytes respectively.
Diff in stack sizes is @(- v2 v1).
Diff in memory is @(- f2 f1).
Factor is @(/ (- f2 f1) (- v2 v1)) bytes.})
(displayln (diff 2048 4096))
;; Initial stack sizes of 2048 and 4096
;; seem to consume 21136 and 37520 bytes respectively.
;; Diff in stack sizes is 2048.
;; Diff in memory is 16384.
;; Factor is 8 bytes.
--
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.
For more options, visit https://groups.google.com/d/optout.
[racket-users] unit of current-thread-initial-stack-size value
What is the unit of current-thread-initial-stack-size value ? Is it in KB ? what is recommended minimum value ? I did not find any page on Racket official doc to get this info so asking here. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] European Racketeers and conferences
OSM Map link for The Swan & Castle: https://www.openstreetmap.org/?mlat=51.75119&mlon=-1.26185#map=18/51.75120/-1.26212 On Sunday, 3 September 2017 11:04:16 UTC+1, Matthew Flatt wrote: > For anyone who can make the trip to Oxford, we'll be at the Swan & Castle at > 6:30pm on Monday. We hope to see you there! -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] European Racketeers and conferences
For anyone who can make the trip to Oxford, we'll be at the Swan & Castle at 6:30pm on Monday. We hope to see you there! Matthew > On Aug 27, 2017, at 8:12 PM, Matthias Felleisen wrote: > > > HI — we compared constraints with Matthew B. (London) to coordinate but we > haven’t heard back from him whether we’ll meet in Oxford or London. Sadly the > other 3 (Sam of Typed Racket fame is attending too) are now at a > secret-cabal-ifip meeting seem to be off-line too. If anything gets organized > still, we’ll get i touch with the Oxford/London people. — Matthias > > > > >> On Aug 27, 2017, at 7:16 AM, Chris Gallagher wrote: >> >> Hi Matthias. I am based near Oxford and would be interested in joining an >> informal get together while people are at ICFP. >> >> Kind Regards >> Chris >> >>> On Tuesday, 22 August 2017 15:51:03 UTC+1, Matthias Felleisen wrote: >>> Matthew F, Robby, and I will be in Oxford for ICFP starting late next week. >>> None of us thought of this before but I am sure we could at least arrange >>> for some dinner or afternoon get-together. — Matthias >>> >>> >>> >>> >>> On Aug 22, 2017, at 10:44 AM, Tim Jervis wrote: Hi Matthew, I’m based in London and would be interested in a get-together. Kind regards, Tim > On 22 Aug 2017, at 15:20, Daniel Brunner wrote: > > Hey Matthew, > > I live in Germany and use Racket for teaching students, teaching our > apprentices (dual education system in Germany) and use it "in > production" for some tasks. > > Best wishes, > Daniel > >> Am 22.08.2017 um 15:15 schrieb Matthew Eric Bassett: >> Hi all, >> >> Gutted I can't make it to RacketCon this year. Really glad to see it >> growing. >> >> Question for y'all - how many Racketeers are active on this side of the >> Atlantic? Enough for a specific get-together over here? Or are there >> already appropriate venues for that that I'm unaware of (I am already >> familiar with the European lisp symposium) >> >> Best, >> >> > > -- > 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. > For more options, visit https://groups.google.com/d/optout. Tim Jervis http://timjervis.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. For more options, visit https://groups.google.com/d/optout. >> > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Racket Web servlet performance benchmarked and compared
A time ago i have implemented a minimal fastcgi protocol and compare it against various others implementations. http://antoineb.github.io/blog/2015/06/02/basic-fastcgi-with-racket/ On 09/02/2017 10:12 PM, Neil Van Dyke wrote: dbohdan wrote on 09/02/2017 03:12 PM: I rather like the SCGI protocol. It's a pity that it isn't as widely supported as FastCGI, considering that it's much simpler to implement (second only to plain old CGI), but still has a performance profile similar to FastCGI's. I mostly implemented FastCGI in Racket at one point, but then I read about the FastCGI implementation in my target HTTP server having hard bugs, so I abandoned that. I also think there are faster ways to serve HTTP from Racket, but I'd have to find funding to work through them. And we have to keep in mind that, unlike benchmarks for LINPACK or standard transaction processing, the real-world applications of HTTP servers are messier. And also, I don't think many people have been tuning for Web application benchmarks, unlike was once done for LINPACK and TP. I think the Racket community has enough skill to make a respectable showing in a benchmark tuning war, or in general platform performance for real-world Web applications, but I'm not aware of any funding going into that right now. -- 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. For more options, visit https://groups.google.com/d/optout.
