"Boespflug, Mathieu" writes:
> You might want to have a look at
> https://github.com/mboes/ghc-events/tree/streaming. Similar to what
> you mention, it uses the "streaming" package for the incremental
> parsing. I ran into an issue with binary that I wasn't able to track
> down:
Hmmm I'll take a look, but from what I see - it uses the same code as
ghc-events for decoding and all the streaming done in a short single commit
- it must suffer the same bug then. It is not a single stream of events,
it's several of them per capability mixed due to caching done by RTS so you
You might want to have a look at
https://github.com/mboes/ghc-events/tree/streaming. Similar to what
you mention, it uses the "streaming" package for the incremental
parsing. I ran into an issue with binary that I wasn't able to track
down: even medium sized buffers make the parsing slower
Note that the (AFAIK unreleased) version of ghc-events on the master
branch of the upstream repo can parse event streams incrementally, if
that's what you meant.
--
Mathieu Boespflug
Founder at http://tweag.io.
On 1 October 2017 at 03:49, Michael Baikov wrote:
> Hi Niklas
>
Hi Niklas
This is indeed looks interesting and I think I saw behavior similar to
this one. At the moment I'm working through ghc-events code to get
myself a better understanding on what is going on in threads scheduler
and get a tool that can handle event stream incrementally, once I'm
done with
Hey Michael, greetings!
Here's a little side issue that may also be of interest to you in case
you've got HyperThreading on:
https://ghc.haskell.org/trac/ghc/ticket/10229
Niklas
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
Here is a simple diagram of forkIO, forkOn and forkOS:
https://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=69
Regards,
Takenobu
2017-09-11 21:54 GMT+09:00 Michael Baikov :
>
> >> I'm developing a program that contains several kinds of threads -
>> I'm developing a program that contains several kinds of threads - those
that do little work and sensitive to latency and those that can spend more
CPU time and less latency sensitive. I looked into several cases of
increased latency in those sensitive threads (using GHC eventlog) and in
all
On 10 September 2017 at 04:03, Michael Baikov wrote:
> Greetings
>
>
> Currently GHC supports two kinds of threads - pinned to a specific
> capability (bound threads) and those it can migrate between any
> capabilities (unbound threads). For purposes of achieving lower
Greetings
Currently GHC supports two kinds of threads - pinned to a specific
capability (bound threads) and those it can migrate between any
capabilities (unbound threads). For purposes of achieving lower latency in
Haskell applications it would be nice to have something in between -
threads GHC
10 matches
Mail list logo