[Vienna-pm] Funding fuer Jonathan Worthington

Thomas Klausner domm at cpan.org
Tue Aug 29 02:49:50 PDT 2017


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 55€ x 50h = 2750€
Am Konto haben wir etwas ueber 6000€

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 (10€) 
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

-- 
#!/usr/bin/perl                              http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}


More information about the Vienna-pm mailing list