From domm at cpan.org Tue Aug 29 02:49:50 2017 From: domm at cpan.org (Thomas Klausner) Date: Tue, 29 Aug 2017 11:49:50 +0200 Subject: [Vienna-pm] Funding fuer Jonathan Worthington Message-ID: <20170829094950.kavjt4b6ytm5tdem@plix.at> 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$_.$/} From rl at brabbel.net Tue Aug 29 03:04:58 2017 From: rl at brabbel.net (Roland Lammel) Date: Tue, 29 Aug 2017 12:04:58 +0200 Subject: [Vienna-pm] Funding fuer Jonathan Worthington In-Reply-To: <20170829094950.kavjt4b6ytm5tdem@plix.at> References: <20170829094950.kavjt4b6ytm5tdem@plix.at> Message-ID: Ich w?rde gerne die Concurrency und Threadpool Implementierung sehen, also 1) and 2) von Jonathan's Liste. Hintergrund kommt aus der Scala Ecke, wo ich jetzt schon l?nger das Play Framework (Web Framework ala Mojolicious nur gr??er) verwende, da? auf dem Actor System aufsetzt und herrlich jegliche komplexit?t der dahinterliegenden Threadpools versteckt. F?r den Entwickler gro?artig. Als Kassier w?r mein Ziel zumindest genug am Konto zu behalten um einen j?hrlichen Workshop vorfinanzieren zu k?nnen (sprich ca. 2000? sollten am Konto bleiben). Cheers Roland 2017-08-29 11:49 GMT+02:00 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 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$_.$/} > _______________________________________________ > Vienna-pm mailing list > Vienna-pm at pm.org > http://mail.pm.org/mailman/listinfo/vienna-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at hartmaier.priv.at Wed Aug 30 13:46:47 2017 From: alex at hartmaier.priv.at (Alexander Hartmaier) Date: Wed, 30 Aug 2017 22:46:47 +0200 Subject: [Vienna-pm] Funding fuer Jonathan Worthington In-Reply-To: <20170829094950.kavjt4b6ytm5tdem@plix.at> References: <20170829094950.kavjt4b6ytm5tdem@plix.at> Message-ID: 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: