From: Vsevolod D. <vse...@gm...> - 2013-04-13 06:53:09
|
Hi, I'd like to participate in GSoC as a mentor. The projects I'm particularly interested in are: - 3.4 Quick compilation - here I have a direct interest, because I'm really hitting the wall with the current compiler in my projects that involve sophisticated DSLs - it seems like space requirements for the compiler grow exponentially (or as a high order polinomial) with single function code size increase, and I get into situations where the compiler memory usage jumps to multiple gigabytes. I would slightly rephrase the name of the goal as: tunable compilation, i.e. make the compiler behave differently depending on the speed and compilation-speed declarations - Implementing coroutine support - some brief remarks may be found here: http://orthecreedence.github.io/cl-async/2012/11/07/missing-coroutines-in-common-lisp.html. It is, I think, at the same time a promising and complicated subject, which should, obviously, be discussed in more detail. The interesting part is that, as far as I understand, a huge chunk of code for implementing coroutines can be reused from the condition system implementation. In fact, I've experimented with implementing coroutines on top of the signal protocol, and there's just one piece missing to be able to do it At the same time, I don't have a lot of practical experience with the SBCL codebase: I neer made any contributions, and only look at the code from times to times. So, I can bring to the table only my overall Lisp and system design experience, a demanding real-world environment to test some of the use cases, and a vision on how the things should work ideally. Given this I don't know if I can be a helpful mentor... Any comments on the above topics welcome, Best Vsevolod Dyomkin +38-096-111-41-56 skype, twitter: vseloved |
From: Stig H. <sti...@gm...> - 2013-04-13 13:08:57
|
Isn't coroutines trivial with threads? On Sat, Apr 13, 2013 at 8:52 AM, Vsevolod Dyomkin <vse...@gm...>wrote: > Hi, > > I'd like to participate in GSoC as a mentor. The projects I'm particularly > interested in are: > > - 3.4 Quick compilation - here I have a direct interest, because I'm > really hitting the wall with the current compiler in my projects that > involve sophisticated DSLs - it seems like space requirements for the > compiler grow exponentially (or as a high order polinomial) with single > function code size increase, and I get into situations where the compiler > memory usage jumps to multiple gigabytes. I would slightly rephrase the > name of the goal as: tunable compilation, i.e. make the compiler behave > differently depending on the speed and compilation-speed declarations > > - Implementing coroutine support - some brief remarks may be found here: > http://orthecreedence.github.io/cl-async/2012/11/07/missing-coroutines-in-common-lisp.html. > It is, I think, at the same time a promising and complicated subject, which > should, obviously, be discussed in more detail. The interesting part is > that, as far as I understand, a huge chunk of code for implementing > coroutines can be reused from the condition system implementation. In fact, > I've experimented with implementing coroutines on top of the signal > protocol, and there's just one piece missing to be able to do it > > At the same time, I don't have a lot of practical experience with the SBCL > codebase: I neer made any contributions, and only look at the code from > times to times. So, I can bring to the table only my overall Lisp and > system design experience, a demanding real-world environment to test some > of the use cases, and a vision on how the things should work ideally. Given > this I don't know if I can be a helpful mentor... > > Any comments on the above topics welcome, > > Best > > Vsevolod Dyomkin > +38-096-111-41-56 > skype, twitter: vseloved > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > |
From: Vsevolod D. <vse...@gm...> - 2013-04-13 13:23:41
|
On Sat, Apr 13, 2013 at 4:08 PM, Stig Hemmer <sti...@gm...> wrote: > Isn't coroutines trivial with threads? > I'm talking here about the cooperatively scheduled coroutines. > > > On Sat, Apr 13, 2013 at 8:52 AM, Vsevolod Dyomkin <vse...@gm...>wrote: > >> Hi, >> >> I'd like to participate in GSoC as a mentor. The projects I'm >> particularly interested in are: >> >> - 3.4 Quick compilation - here I have a direct interest, because I'm >> really hitting the wall with the current compiler in my projects that >> involve sophisticated DSLs - it seems like space requirements for the >> compiler grow exponentially (or as a high order polinomial) with single >> function code size increase, and I get into situations where the compiler >> memory usage jumps to multiple gigabytes. I would slightly rephrase the >> name of the goal as: tunable compilation, i.e. make the compiler behave >> differently depending on the speed and compilation-speed declarations >> >> - Implementing coroutine support - some brief remarks may be found here: >> http://orthecreedence.github.io/cl-async/2012/11/07/missing-coroutines-in-common-lisp.html. >> It is, I think, at the same time a promising and complicated subject, which >> should, obviously, be discussed in more detail. The interesting part is >> that, as far as I understand, a huge chunk of code for implementing >> coroutines can be reused from the condition system implementation. In fact, >> I've experimented with implementing coroutines on top of the signal >> protocol, and there's just one piece missing to be able to do it >> >> At the same time, I don't have a lot of practical experience with the >> SBCL codebase: I neer made any contributions, and only look at the code >> from times to times. So, I can bring to the table only my overall Lisp and >> system design experience, a demanding real-world environment to test some >> of the use cases, and a vision on how the things should work ideally. Given >> this I don't know if I can be a helpful mentor... >> >> Any comments on the above topics welcome, >> >> Best >> >> Vsevolod Dyomkin >> +38-096-111-41-56 >> skype, twitter: vseloved >> >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> _______________________________________________ >> Sbcl-devel mailing list >> Sbc...@li... >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel >> >> > |
From: Nikodemus S. <nik...@ra...> - 2013-04-13 14:12:21
|
On 13 April 2013 09:52, Vsevolod Dyomkin <vse...@gm...> wrote: I apologize for being a Negative Nelson here... > I'd like to participate in GSoC as a mentor. The projects I'm particularly > interested in are: I'm not directly involved in our GSoC, so take this with a ton of salt ... but I do believe mentors should be SBCL hackers -- enough so to be able to advice the students on technical issues specific to the project at the very least. (I don't know what the actual rule is, that's just what I would consider a reasonable minimum.) > I would slightly rephrase the name of the goal as: I would not start repainting that bikeshed now, especially since a fast mode is a pre-requiresite for tuning. > - Implementing coroutine support - some brief remarks may be found here: > http://orthecreedence.github.io/cl-async/2012/11/07/missing-coroutines-in-common-lisp.html. Unless someone has a much clearer plan of attack than I do (see http://random-state.net/log/2012-10-06-userspace-threads-for-sbcl----a-short-discussion.html) on getting this up and running, or unless there is a student with a very strong pre-existing working knowledge of the domain, then adding coroutines is IMO way out of scope for a GSoC project. A broken prototype or a proof of concept I could see happening, but unless someone has time to finish that... there's little point IMO. Cheers, -- Nikodemus |
From: Paul K. <pv...@pv...> - 2013-04-13 14:20:45
|
Nikodemus Siivola wrote: > I'm not directly involved in our GSoC, so take this with a ton of salt > ... but I do believe mentors should be SBCL hackers -- enough so to be > able to advice the students on technical issues specific to the > project at the very least. (I don't know what the actual rule is, > that's just what I would consider a reasonable minimum.) [...] >> I would slightly rephrase the name of the goal [Quick compilation] as: > > I would not start repainting that bikeshed now, especially since a > fast mode is a pre-requiresite for tuning. [...] >> - Implementing coroutine support - some brief remarks may be found here: >> http://orthecreedence.github.io/cl-async/2012/11/07/missing-coroutines-in-common-lisp.html. > > Unless someone has a much clearer plan of attack than I do (see > http://random-state.net/log/2012-10-06-userspace-threads-for-sbcl----a-short-discussion.html) > on getting this up and running, or unless there is a student with a > very strong pre-existing working knowledge of the domain, then adding > coroutines is IMO way out of scope for a GSoC project. [...] +1 on all three counts. Paul Khuong |
From: Stig H. <sti...@gm...> - 2013-04-13 14:53:28
|
On Sat, Apr 13, 2013 at 3:22 PM, Vsevolod Dyomkin <vse...@gm...>wrote: > On Sat, Apr 13, 2013 at 4:08 PM, Stig Hemmer <sti...@gm...> wrote: > >> Isn't coroutines trivial with threads? >> > > I'm talking here about the cooperatively scheduled coroutines. > So was I. Sorry about being too short. Threads and coroutines are not the same thing, obviously, but it seems to me that threads are powerful enough to be used to implement a coroutine library without a whole lot of effort. You will need a some sort of locking to make sure only one thread is actually executing at any given time, but you will get independent call stacks for free. I haven't really thought this through and there might be some trvial reason I am wrong. |
From: Paul K. <pk...@gm...> - 2013-04-13 15:00:50
|
Stig Hemmer wrote: > On Sat, Apr 13, 2013 at 3:22 PM, Vsevolod Dyomkin<vse...@gm...>wrote: > >> On Sat, Apr 13, 2013 at 4:08 PM, Stig Hemmer<sti...@gm...> wrote: >> >>> Isn't coroutines trivial with threads? >>> >> I'm talking here about the cooperatively scheduled coroutines. >> > > So was I. Sorry about being too short. > > Threads and coroutines are not the same thing, obviously, but it seems to > me that threads are powerful enough to be used to implement a coroutine > library without a whole lot of effort. That's right, and if all you want is cooperative threading, it may be good enough. GNU Pth works that way, nowadays. However, that's pretty much the worst of both worlds: heavyweight system threads with locking, and you still have to schedule them manually. I expect many people who would like to see (full) coroutines expect some sort of performance gain over plain threads, in return for being willing to manage task switching manually. Paul Khuong |
From: David L. <da...@li...> - 2013-04-14 10:02:29
|
Quoting Paul Khuong (pk...@gm...): > That's right, and if all you want is cooperative threading, it may be > good enough. GNU Pth works that way, nowadays. However, that's pretty > much the worst of both worlds: heavyweight system threads with > locking, and you still have to schedule them manually. I expect many > people who would like to see (full) coroutines expect some sort of > performance gain over plain threads, in return for being willing to > manage task switching manually. Anyone interested in cooperative threading might want to start by merging fiber support from the windows branch first. The reason we don't have fibers in upstream yet is 1. that I wasn't (and still am not) convinced that's it's entirely worthwhile and 2. specifically wanted to ensure that we're not depending on it internally for use cases which do not strictly need it. So the code already exists -- it's just a matter of extracting and merging it in just the right way. I'd still strongly prefer a fiber support patch that's minimally invasive. But fibers definitely could have some benefits, and are interesting as such from a technical perspective, so if someone comes up with a clean patch, it's worth considering. Benchmarks demonstrating fabulous speed improvements (e.g. for callbacks) might help make a good impression. d. |
From: Vsevolod D. <vse...@gm...> - 2013-04-13 15:50:12
|
On Sat, Apr 13, 2013 at 5:12 PM, Nikodemus Siivola < nik...@ra...> wrote: > On 13 April 2013 09:52, Vsevolod Dyomkin <vse...@gm...> wrote: > > I apologize for being a Negative Nelson here... > > > I'd like to participate in GSoC as a mentor. The projects I'm > particularly > > interested in are: > > I'm not directly involved in our GSoC, so take this with a ton of salt > ... but I do believe mentors should be SBCL hackers -- enough so to be > able to advice the students on technical issues specific to the > project at the very least. (I don't know what the actual rule is, > that's just what I would consider a reasonable minimum.) > I see your point and have to agree. That's why I was asking. Cheers |
From: Christophe R. <cs...@ca...> - 2013-04-13 18:24:44
|
Vsevolod Dyomkin <vse...@gm...> writes: > On Sat, Apr 13, 2013 at 5:12 PM, Nikodemus Siivola < > nik...@ra...> wrote: >> I apologize for being a Negative Nelson here... >> >> > I'd like to participate in GSoC as a mentor. The projects I'm >> > particularly >> > interested in are: >> >> I'm not directly involved in our GSoC, so take this with a ton of salt >> ... but I do believe mentors should be SBCL hackers -- enough so to be >> able to advice the students on technical issues specific to the >> project at the very least. (I don't know what the actual rule is, >> that's just what I would consider a reasonable minimum.) > > I see your point and have to agree. That's why I was asking. Well. There's unblocking technical issues, and there's also routine project management (e.g. making sure that the student actually knows where to look, is working, can write reports, knows where the git repository is this week, and so on). SBCL hackery is probably required for the former, and if we get enough SBCL hackers (not necessarily commiters, people with experience) as mentors then great. But we might not, and in that case I'd rather have team mentorship from someone willing to do project management and someone to be a technical consultant sharing the load, than have no-one at all. Whether that's contortable into the GSoC way of thinking I don't know. (But it is at least suggestive that UK PhD supervision is very much going this way: people have several supervisors, one of whom is responsible for the paperwork, and need not necessarily have any direct academic input.) Cheers, Christophe |
From: Vsevolod D. <vse...@gm...> - 2013-04-14 06:16:44
|
On Sat, Apr 13, 2013 at 9:24 PM, Christophe Rhodes <cs...@ca...> wrote: > Vsevolod Dyomkin <vse...@gm...> writes: > > > On Sat, Apr 13, 2013 at 5:12 PM, Nikodemus Siivola < > > nik...@ra...> wrote: > >> I apologize for being a Negative Nelson here... > >> > >> > I'd like to participate in GSoC as a mentor. The projects I'm > >> > particularly > >> > interested in are: > >> > >> I'm not directly involved in our GSoC, so take this with a ton of salt > >> ... but I do believe mentors should be SBCL hackers -- enough so to be > >> able to advice the students on technical issues specific to the > >> project at the very least. (I don't know what the actual rule is, > >> that's just what I would consider a reasonable minimum.) > > > > I see your point and have to agree. That's why I was asking. > > Well. There's unblocking technical issues, and there's also routine > project management (e.g. making sure that the student actually knows > where to look, is working, can write reports, knows where the git > repository is this week, and so on). SBCL hackery is probably required > for the former, and if we get enough SBCL hackers (not necessarily > commiters, people with experience) as mentors then great. But we might > not, and in that case I'd rather have team mentorship from someone > willing to do project management and someone to be a technical > consultant sharing the load, than have no-one at all. > > Whether that's contortable into the GSoC way of thinking I don't know. > (But it is at least suggestive that UK PhD supervision is very much > going this way: people have several supervisors, one of whom is > responsible for the paperwork, and need not necessarily have any direct > academic input.) > > Cheers, > > Christophe > As for me, I'm willing to participate, so if you there's a need I can volunteer to help. I also view it as a chance to get more involved in SBCL development. Best, Vsevolod |