[Vienna-pm] Funding fuer Jonathan Worthington

[Alexander Hartmaier]

Hi, 

find ich sehr gut! Gerade bei Parallelität und Asynchronität sehe ich
die Stärken von Perl 6. 

+1 von mir also. 

LG Alex 

Am 2017-08-29 11:49, schrieb Thomas Klausner:

> Hi!
> 
> Beim letzten Meeting (im Juni) haben wir (bzw ein Teil) besprochen, dass 
> wir einen Teil unseres immer noch vorhandenen YAPC-2007-Geldes ausgeben 
> koennen, indem wir Jonathan Worthington sponsorn, ein paar nette 
> Perl6-Features zu implementieren.
> 
> Er ist dazu generell bereit (bzw sucht ja aktiv Sponsoren):
> https://6guts.wordpress.com/2017/05/12/looking-for-perl-6-rakudo-and-moarvm-development-funding/
> 
> Jonathan hat mir vor dem Sommer mal eine Liste mit Ideen geschickt, was 
> er in ca 50h machen koennte (siehe weiter unten). Ich weiss nicht, ob 
> die Liste noch aktuell ist, aber falls nicht, koennen wir sicher 
> aehnliche Features finden.
> 
> Budgetmaessig reden wir von 55EUR x 50h = 2750EUR
> Am Konto haben wir etwas ueber 6000EUR
> 
> Ich wuerde vorschlagen, wir diskutieren das mal kurz, und machen nachste 
> Woche eine Abstimmung (sagen wir bis Freitag, 8.9., 12:00)
> Da es um Vereinsgeld geht, sind bei der Abstimmung nur Vereinsmitglieder 
> stimmberechtigt. Vereinsmitglied ist, wer den Mitgliedsbeitrag (10EUR) 
> bezahlt hat (allerdings sind die Aufzeichnungen daruber recht duerftig). 
> Falls also jemand noch schnell bezahlen mag:
> http://vienna.pm.org/verein.html
> Name:        VIENNA.PM-VEREIN PROGRAMMIERSPRACHE PERL
> IBAN:        AT133200000002776474
> BIC:         RLNWATWW
> 
> (und wow, die website ist alt!)
> 
> Jonathans Vorschlaege vom 21.6.:
> 
> There are certainly a number of outstanding concurrency and parallelism
> tasks which would benefit from funding. Some key areas are:
> 
> * Completing the work on non-blocking `await`, which makes `await` not
> really block a thread in the thread pool, but instead return it to the
> scheduler to use for something else. At present, it's quite easy -
> especially if doing divide and conquer style things - to exhaust the thread
> pool, but with most threads blocked awaiting a result from a child task
> rather than actually doing work. With this change, the threads would not
> block, but instead work on completing the child tasks. This was always the
> plan, but there wasn't time ahead of 6.c to realize it. I already started
> this work and have a working proof of concept (just `use v6.d.PREVIEW`),
> but it interacts badly with `supply`/`react` blocks and has some other
> rough edges that need dealing with before we can really consider it ready.
> This would be a good thing to deal with.
> 
> * Improving the thread pool scheduler. This is the component that spreads
> tasks over threads. The current implementation is very simplistic, usually
> starting more threads than are really needed. It also doesn't distinguish
> between time, I/O, and computation in any way, meaning that a huge amount
> of input coming in from a spawned process can swamp the work queue and
> prevent a timer event intended to kill the process from firing on time.
> There's many ways to do better in this area.
> 
> * Continuing the work on .race and .hyper, which should allow for data
> parallel list operations (think of a chain of map and grep, but where the
> input data is partitioned automatically into chunks and then the chains run
> on different threads). I've done a good bit of planning work on this front,
> but now the actual implementation work is needed.
> 
> Any of these would be useful (I suspect with 50 hours I could deal with the
> first issue and get a good way into the second, for example). I'm open to
> other suggestions and priorities you might come up with also.
> 
> Schoene Gruesse,
> Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/vienna-pm/attachments/20170830/1ddfd2a8/attachment.html>