lly linear).
> --
> Mathieu Boespflug
> Founder at http://tweag.io.
>
>
> On 1 October 2017 at 14:34, Michael Baikov <manpac...@gmail.com> wrote:
> > On Sun, Oct 1, 2017 at 8:09 PM, Boespflug, Mathieu <m...@tweag.io> wrote:
> >> Note that the (AFAIK unreleased)
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
> I, too, have wished for the ability to have a separator in large number
> literals.
>
> So a strong +1 from me.
more +1 here
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> 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
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
Recently merged vector primops support only 16 bytes operands - Int32
x 4, Double x 2 and so on. Current AVX instructions support 256 bit
operands and with simple cut'n'paste work it's possible to support at
least Double x 4 operands. I made those changes and GHC generates
(using llvm) proper AVX
