One-shot semantics in GHC event manager

[Austin Seipp]

For the record, I talked to Ben earlier on IRC, and I can provide him
with a machine to do intense benchmarks of the new I/O manager.

Also, if any other developers (like Andreas, Johan, Bryan, etc) in
this space want a big machine to test it on, I can probably equip you
with one (or several). Since Rackspace is so gracious to us, we can
immediately allocate high-powered, physical (i.e. not Xen, but real
machines) machines to do high-scale testing on.[1]

In any case, it's not hard to do and only takes a few minutes, so Ben:
let me know. (I've thought it would be neat to implement a leasing
system somehow, where a developer could lease a few machines for a
short period of time, at which point they expire and a background job
cleans them up.)

[1] You can find the hardware specs here; GHC benchmarking is probably
best suited for the "OnMetal I/O" type, which has 40 cores, 2x PCIe
flash and 128GB of RAM -
http://www.rackspace.com/cloud/servers/onmetal/

On Mon, Oct 13, 2014 at 2:05 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:
> Ben Gamari <bgamari.foss at gmail.com> writes:
>
>> Andreas Voellmy <andreas.voellmy at gmail.com> writes:
>>
>>> On Sat, Oct 11, 2014 at 12:17 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:
>>>
>>> Ah... so this is not useful to you. I guess we could add `loop` to
>>> GHC.Event's export list. On the other hand, I like your LifeTime proposal
>>> better and then no one needs `loop`, so let's try this first.
>>>
>> I have a first cut of this here [1]. It compiles but would be I shocked
>> if it ran. All of the pieces are there but I need to change
>> EventLifetime to a more efficient encoding (there's no reason why it
>> needs to be more than an Int).
>>
> As it turns out the patch seems to get through the testsuite after a few
> minor fixes.
>
> What other tests can I subject this to? I'm afraid I don't have the
> access to any machine even close to the size of those that the original
> event manager was tested on so checking for performance regressions will
> be difficult.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/