Improve list of SoC projects

[jiahao]

Reviewing our current list of Summer of Code projects, I think that some of the projects should be removed and others should be significantly revised or otherwise removed entirely. IMO the projects listed in Lists 1 and 2 are far too ambitious, vague or otherwise unsuitable for a SoC project of 2-3 developer-months.

List 1: Projects which I think are unrealistic for SoC students to pursue and should be nixed

• Translations of Axiom to Julia. I don't see this as high priority, nor is this realistic to expect any usable product after just 2-3 developer-months, nor do we really have the mentors capable of supervising this project (which requires expert knowledge of computer algebra systems).
• Base Julia Restructuring. While this project needs doing, I do not think it is feasible for a summer student to do it. It's far too much work for a SoC, has little tangible product that a student can take ownership of, and whoever does this project will bear the brunt of being harangued against by the other developers as they adjust to the new base library structure.

List 2: Projects worth doing but are too vague

Projects on this list have descriptions that are essentially "X is broken, fix it" or "I want X, Y, Z, three ponies, and a unicorn".

IMO these project descriptions should be whittled down in scope, so that SoC students can reasonably hope to finish something in 2-3 months, or otherwise axed.

• Writing high-performance, multithreaded kernels for image processing - the current description is vague and does not define any project of reasonable scope for a SoC. Taken literally, this project could easily be 1-n PhD's worth of work.
• Better error reporting - Worth doing, but vague.
• C linter - Solving the memory leak problem via static analysis seems way too hard for a SoC project.
• Web stack / networking improvements - a random grab bag that just says "it's all broken, fix it".

List 3: Projects that could use cross-referencing to existing packages

This list of projects just need minor updates to the descriptions. If the authors referenced agree, I think these extant packages could be cross-referenced to existing project descriptions.

• Dynamic distributed execution for data parallel tasks in Julia - could use a cross-reference to @shashi's ComputeFramework.jl
• Syntax checker should probably be updated to reference @tonyhffong's Lint.jl.

[ViralBShah]

I will put up concrete stuff for ComputeFramework.

[jiahao]

Thanks Viral!

[MikeInnes]

Thanks @jiahao for taking a really detailed look over these. FWIW, I do think that compelling proofs-of-concept / prototypes of larger projects are a fine project idea, but I agree that it can be much clearer what we do and don't expect from most of these.

I think the web stuff can be broken down into:

• Support for new protocols / low level technologies – HTTP2 etc.
• Mid-level things like routing, cookie handling, auth etc. – and making these independent but composable pieces (I like the Clojure/Ring model a lot here)
• Basic database interaction
• In general, getting to a polished state where it's easy to set up a webserver with some basic logic and serve some pages etc.

To some extent these can be done independently, but getting enough of each part working to have a really basic proof of concept (e.g. a simple jekyll-like server) would be a great project in itself. I'd be happy to mentor if there's no one better qualified, and I expect @shashi has some thoughts too.

[timholy]

@ViralBShah, do you want to edit the GPU project to incorporate recent efforts on ArrayFire? (Or will the work on ArrayFire likely make other efforts unnecessary?)

[ViralBShah]

I have been quite impressed with ArrayFire in general, since @ranjanan and I have been working with it in the last few weeks. It still does not have sparse capabilities (perhaps @pavanky can say if there is a plan), but our plan is to wrap up all of it and port the ArrayFire demos to Julia.

This may mean that our focus on GPU side can be more on native codegen going forward, and we may be ok on GPU libraries.

[ChrisRackauckas]

On the GPU side, what about a wrapper for CUSP? I know that sparse iterative solvers are on the menu on the CPU side, but this is really well-suited for the GPU. Although we have cuSPARSE, that doesn't implement the common solvers like conjugate gradient and the like, and so someone who is looking to really use sparse linear algebra has to either implement it or wrap to CUSP themselves in a CUDA kernel.

Another thing that I think should be added is a better console in Juno Atom. Something to do with JunoLab/atom-ink#20, but also the issue with progress bars like at JuliaLang/julia#8064 and timholy/ProgressMeter.jl#32. A good outcome could be a more responsive console that allows for showing a progress meter (that can be used on parallel operations), or simply putting the progress bar in some window not in the console (which I would prefer so other updates could print). That would immensely help usability.

Another idea is to fix up the GSL.jl wrapper since a lot of the functionality doesn't work, though I would prefer native Julia implementations for most of it.

Julia functions to ptx via the LLVM was also mentioned elsewere, but that might be difficult.

Depending on the release of Knights Landing, maybe some packages for usability / a standard Julia for implementing automatic offloading via MKL could be interesting projects.

[ViralBShah]

Cusp looks awesome. Have you used it? Is it reasonably ready to use and maintained?

[ChrisRackauckas]

@ViralBShah, I haven't used it yet (been meaning to), but I keep getting linked back to it. It seems perfectly ready to use and is pretty stable with most of the new releases just matching new CUDA toolkits. PETSc uses it as the basis for the GPU methods.

[timholy]

To clarify a previous point I made, I think the idea of Julia->LLVM->PTX would be awesome. It's just that I fear the number of people who could mentor such a project may be small, and it may be a big project. But with the right student/mentor combination, it could have huge impact.

Overall I'm enthusiastic about better GPU tooling.

[ChrisRackauckas]

Another thing that comes to mind is extending Julia's random number generation by making bindings to MKL VSL. These would most likely beat a native Julia implementation in terms of performance and would be very useful in scientific computing (especially once Knights Landing comes out and more things are offloaded/built with MKL). It wouldn't be too hard since they could use a lot of the implementation ideas from VML.jl.

[jiahao]

I believe we can close this now that GSoC project selection is well underway. Thank you everyone for their suggestions!

[eford]

Is there a way to indicate that one could be interested in serving as a
mentor for a specific project?
In may case, it's Native Julia solvers for ordinary differential equations.

On Tue, Apr 12, 2016 at 1:41 PM, Jiahao Chen notifications@github.com
wrote:

I believe we can close this now that GSoC project selection is well
underway. Thank you everyone for their suggestions!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#339 (comment)

Eric Ford
Professor of Astronomy & Astrophysics
Center for Exoplanets & Habitable Worlds
Center for Astrostatistics
Institute for CyberScience
Penn State Astrobiology Research Center
Pennsylvania State University

[jiahao]

@eford Yes; @MikeInnes or @shashi can invite you to participate on the Google Summer of Code website as a official mentor.