[ghc-steering-committee] #540: parallelism semaphores, recommendation: *accept*

[Arnaud Spiwack]

I would like to oppose the argument that “it's already implemented” is a
strong argument for this court. It certainly helps evaluate feasibility,
but we are supposed to evaluate whether something is a good idea.

That being said, considering that
1/ better solutions are hard to design (and even hard to prove better, as
there is not really a standard job server outside of Macos)
2/ it is believed that almost no user will have to use this command
themselves (we expect `-jsem` to be called in a handful of places, such as
in the Cabal tool and possibly in the Stack tool)

I think the benefit will largely outweigh the costs, and am in favour.

On Mon, 13 Feb 2023 at 17:24, Chris Dornan <chris at chrisdornan.com> wrote:

> I have wanted this for many years.
>
> I have one question which I put in the thread but it really should not get
> in the way of making things better -- let's iterate.
>
> +1 from me.
>
> Chris
>
> On 13 Feb 2023, at 01:45, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
> > On balance, I think we should accept this proposal and not let the
> perfect be the enemy of the good.
>
> I agree with this. An incremental improvement is an improvement. And if
> need/interest/funding is there can be iterated upon.
>
> On Mon, 13 Feb 2023 at 5:11 AM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Sonntag, dem 12.02.2023 um 14:01 -0500 schrieb Eric Seidel:
>> > I have two minds about this proposal. On the one hand, it seems
>> > likely to leave performance on the table compared to the alternatives
>> > discussed. But on the other hand, this proposal has already been
>> > implemented and validated by Well-Typed, and it seems like a small
>> > amount of additional complexity for GHC to adapt. (Though I'd love
>> > for someone with more knowledge of GHC internals to opine on the
>> > internal complexity.)
>> >
>> > On balance, I think we should accept this proposal and not let the
>> > perfect be the enemy of the good.
>>
>> I agree. Especially given that there is an implementation, I see no
>> good reason why we shouldn’t trust the implementors and authors’s good
>> sense in their design choices.
>>
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230214/afa743a8/attachment.html>