Relatedly, there is a sketch of something like a "case construct" on Richard's blog, where he talks about a "type instance where" syntax that allows closed interdependent sets of family instances. Is that something that was later found to be infeasible?<div><br><div class="gmail_quote"><div dir="ltr">On Fri, May 12, 2017, 17:53 <<a href="mailto:haskell-cafe-request@haskell.org">haskell-cafe-request@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Haskell-Cafe mailing list submissions to<br>
<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:haskell-cafe-request@haskell.org" target="_blank">haskell-cafe-request@haskell.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:haskell-cafe-owner@haskell.org" target="_blank">haskell-cafe-owner@haskell.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Haskell-Cafe digest..."<br>
Today's Topics:<br>
<br>
1. Re: Fast JSON validation - reducing allocations (Arjen)<br>
2. Re: Fast JSON validation - reducing allocations (David Turner)<br>
3. Re: [ghc-proposals/cafe] Partially applied type families<br>
(Anthony Clayden)<br>
<br><br><br>---------- Forwarded message ----------<br>From: Arjen <<a href="mailto:arjenvanweelden@gmail.com" target="_blank">arjenvanweelden@gmail.com</a>><br>To: David Turner <<a href="mailto:dct25-561bs@mythic-beasts.com" target="_blank">dct25-561bs@mythic-beasts.com</a>>, Haskell Cafe <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>><br>Cc: <br>Bcc: <br>Date: Fri, 12 May 2017 12:16:45 +0200<br>Subject: Re: [Haskell-cafe] Fast JSON validation - reducing allocations<br>On Fri, 2017-05-12 at 10:48 +0100, David Turner wrote:<br>
> On 12 May 2017 at 09:27, Arjen <<a href="mailto:arjenvanweelden@gmail.com" target="_blank">arjenvanweelden@gmail.com</a>> wrote:<br>
> > Maybe this is a silly question, and please let me know why if so,<br>
> > but:<br>
> ><br>
> > Has anyone thought about parallelizing it for multiple messages in<br>
> > order to "produce garbage faster"? While reducing allocation will<br>
> > make<br>
> > the single validations faster, doing multiple ones might improve<br>
> > the<br>
> > throughput per GC ratio. This assumes that the amount of live data<br>
> > in<br>
> > the heap is small, making GC sort of constant time, and having<br>
> > multiple<br>
> > cores available.<br>
><br>
> Not a silly question at all. Adding the following incantation:<br>
><br>
> `using` parListChunk 100 rseq<br>
><br>
> does quite happily spread things across all 4 cores on my development<br>
> machine, and it's certainly a bit faster. To give some stats, it<br>
> processes ~24 events between GCs rather than ~6, and collects ~2MB<br>
> rather than ~500kB. The throughput becomes a lot less consistent,<br>
> however, at least partly due to some bigger GC pauses along the way.<br>
> As Ben's statistics showed, our allocation rate on one thread is<br>
> around 4TBps, which is already stressing the GC out a bit, and<br>
> parallelising it doesn't make that problem any easier.<br>
><br>
> I know in the OP I said "we have a stream" (accidental MLK misquote)<br>
> but in fact there are a bunch of parallel streams whose number<br>
> exceeds the number of available cores, so we don't anticipate any<br>
> enormous benefit from spreading the processing of any one stream<br>
> across multiple cores: single-threaded performance is what we think<br>
> we should be concentrating on.<br>
><br>
> Cheers,<br>
><br>
> David<br>
><br>
Apologies for spamming, but if you want more mutator time between<br>
garbage collections, try increasing the nursery size. I get a lot less<br>
time in GC and also much less sync's on GC (according to -s). It seems<br>
to reduce the execution time by a third using something -A8M or -A64M<br>
(quite extreem). In a large program, this effect might be less.<br>
<br>
kind regards, Arjen<br>
<br>
<br>
<br>
<br><br><br>---------- Forwarded message ----------<br>From: David Turner <<a href="mailto:dct25-561bs@mythic-beasts.com" target="_blank">dct25-561bs@mythic-beasts.com</a>><br>To: Arjen <<a href="mailto:arjenvanweelden@gmail.com" target="_blank">arjenvanweelden@gmail.com</a>><br>Cc: Haskell Cafe <<a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a>><br>Bcc: <br>Date: Fri, 12 May 2017 11:24:23 +0100<br>Subject: Re: [Haskell-cafe] Fast JSON validation - reducing allocations<br><div dir="ltr"><div>On 12 May 2017 at 11:00, Arjen <span dir="ltr"><<a href="mailto:arjenvanweelden@gmail.com" target="_blank">arjenvanweelden@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="m_-8571670317171693297gmail-HOEnZb"><div class="m_-8571670317171693297gmail-h5"><span style="color:rgb(34,34,34)">Happy to read that you have more success than I with parListChunk.</span><br></div></div>
I expect(ed) the sparks to be cheap, so this might help if the various<br>
incoming streams are very unbalanced in length and/or message sizes.<br>
I agree that multi-processing a single stream does not make much sense<br>
if you already have multiple concurrent streams.<br>
<br>
Nice to see that adding on parallelism in Haskell (GHC) is that easy<br>
(in this case) and with a very good speed-up factor!<br>
<br>
kind regards, Arjen<br>
</blockquote></div><br></div><div class="gmail_extra">Ah, ok, this is strange. The production system is definitely faster with the parallel strategy (on one stream) but my Criterion benchmarks are much slower. I've updated the code and results on Github (<a href="https://github.com/DaveCTurner/json-validator" target="_blank">https://github.com/DaveCTurner/json-validator</a>). Probably not going to be able to look at the parallel version much more, but thought you might like a look.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"><br></div></div>
<br><br><br>---------- Forwarded message ----------<br>From: Anthony Clayden <<a href="mailto:anthony_clayden@clear.net.nz" target="_blank">anthony_clayden@clear.net.nz</a>><br>To: <a href="mailto:haskell-cafe@haskell.org" target="_blank">haskell-cafe@haskell.org</a><br>Cc: <br>Bcc: <br>Date: Fri, 12 May 2017 22:46:45 +1200<br>Subject: Re: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families<br>> 2 days ago Richard Eisenberg (and mniip) wrote:<br>
<br>
> ...<br>
> On incremental improvements / the "half-baked" nature of<br>
> type families: I agree completely. ...<br>
["half-baked" is Richard quoting mniip]<br>
<br>
> ... the weird place of type families in the language.<br>
> It is my hope that Dependent Haskell will obviate<br>
> a lot of these concerns, allowing us to deprecate<br>
> type families as we know them<br>
> (you would just use an ordinary function in types<br>
> instead).<br>
<br>
I don't want to sidetrack the github discussion<br>
on mniip's proposal.<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/52" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/52</a><br>
<br>
So please explain here in what way<br>
type families are "half baked".<br>
<br>
The part of type families I find<br>
hard to use and hard to reason about<br>
is closed type families.<br>
I'd be very happy to deprecate them,<br>
if there was something that did overlaps better.<br>
<br>
>From what I can make out, though,<br>
in Richard's Dissertation,<br>
they can't be promoted to "ordinary functions<br>
in types".<br>
<br>
If the closed equations were ordinary<br>
functions in types, you could go:<br>
<br>
> type family F a b<br>
> type instance F Int b = b<br>
> type instance F a Bool | a /~ Int = a<br>
> -- non-unifiability guard<br>
<br>
With no need for a closed sequence of choices.<br>
<br>
Is this the "case-like computations"<br>
others talk about on the proposal?<br>
<br>
<br>
AntC<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div></div>