Hello, Everyone LLVM recently was approved to take part in Google Summer of Code 2008. We welcome everyone to apply for this program. The list of ideas for (possible) projects is located at http://llvm.org/OpenProjects.html. Surely you can suggest any other project, if you feel, that it definitely can be useful. Our common requirement for student is to submit proposal to LLVM Developers Mainling list for discussions and suggestions *before* actual submission to Google. Be prepared, that you proposal can be changed a lot as a result of these discussions :) Drupal project has great page about "How to Write Summer of Code Application": http://drupal.org/node/59037, I'd suggest every applicant to read it before writing an application/proposal. We're waiting for you proposals! PS: The students application period (at Google) begins at 12 noon PDT, March 24 (19:00 UTC) and ends 5:00 PM PDT, March 31 (00:00 UTC April 1, 2008). Students application should be submitted to Google at this period. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Tuesday 18 March 2008 20:17:52 Anton Korobeynikov wrote:> Hello, Everyone > > LLVM recently was approved to take part in Google Summer of Code 2008. > We welcome everyone to apply for this program. > > The list of ideas for (possible) projects is located at > http://llvm.org/OpenProjects.html. Surely you can suggest any other > project, if you feel, that it definitely can be useful.Just some ideas to add to the mix: One of the suggestions is to write a code-density optimizer for the ARM backend. For an interesting alternative, try optimizing for power consumption instead. If you want something super researchy, try doing this for one of the clockless (asynchronous) ARM cores: http://www.arm.com/products/CPUs/ARM996HS.html Another suggestion under "Miscellaneous Additions" was to write a new front-end for Java/OCaml/Forth. IMHO, reimplementing Java or OCaml from scratch is way too much work and a lot of that work is uninteresting baggage. My personal dream is to implement a higher-level VM that bundles an existing concurrent GC with an intermediate representation that exposes high-level language-agnostic features like parametric polymorphism (generics), first-class lexical closures (and maybe even pattern matching) and a backend that type specializes to remove polymorphism (and the associated run-time performance hit, as seen in OCaml) before LLVM code is generated. I would like this for two reasons: a) to provide the foundation for better technical computing environments on Linux and Mac OS X (like F# for Windows). This could greatly improve the open source tools that scientists and engineers use for technical computing. b) to provide a CLR. This could make it much easier for industry to build and sell software written in exotic languages for Linux and Mac OS X. A tamer but related idea is to implement a Fortran 77 front-end for LLVM and then get LAPACK into the LLVM benchmark suite. This could help LLVM to improve and might provide a faster LAPACK library for the open source world. FFTW is another hugely important numerical library that could be used for benchmarking. Aside from simply getting FFTW to work using llvm-gcc, an interesting project might be to rewrite the OCaml source code in FFTW to generate codelets on-the-fly using LLVM or the CLang front-end. LLVM can probably beat GCC here, not least because an LLVM-based implementation would not be limited to a set of precompiled codelets. This could help the millions of people who use FFTW. On an unrelated note, LLVM has great potential for improving OCaml's FFI. At the moment, OCaml programmers are expected to write stubs in C and statically link them in with their OCaml code. A much better solution would be to use LLVM to generate the equivalent of the C stubs at run-time. Calling OpenGL directly from OCaml using LLVM without any existing OpenGL bindings would make an excellent example. This project could really help the OCaml community. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e
On Mar 18, 2008, at 2:49 PM, Jon Harrop wrote:> On Tuesday 18 March 2008 20:17:52 Anton Korobeynikov wrote: >> Hello, Everyone >> >> LLVM recently was approved to take part in Google Summer of Code >> 2008. >> We welcome everyone to apply for this program. >> >> The list of ideas for (possible) projects is located at >> http://llvm.org/OpenProjects.html. Surely you can suggest any other >> project, if you feel, that it definitely can be useful. > > Just some ideas to add to the mix: > > One of the suggestions is to write a code-density optimizer for the > ARM > backend. For an interesting alternative, try optimizing for power > consumption > instead. If you want something super researchy, try doing this for > one of the > clockless (asynchronous) ARM cores: > > http://www.arm.com/products/CPUs/ARM996HS.htmlWhile we are talking about ARM. Raul H. worked on ARM JIT support last summer, it would be nice if someone continues the work. Evan> > > Another suggestion under "Miscellaneous Additions" was to write a new > front-end for Java/OCaml/Forth. IMHO, reimplementing Java or OCaml > from > scratch is way too much work and a lot of that work is uninteresting > baggage. > My personal dream is to implement a higher-level VM that bundles an > existing > concurrent GC with an intermediate representation that exposes high- > level > language-agnostic features like parametric polymorphism (generics), > first-class lexical closures (and maybe even pattern matching) and a > backend > that type specializes to remove polymorphism (and the associated run- > time > performance hit, as seen in OCaml) before LLVM code is generated. I > would > like this for two reasons: > > a) to provide the foundation for better technical computing > environments on > Linux and Mac OS X (like F# for Windows). This could greatly improve > the open > source tools that scientists and engineers use for technical > computing. > > b) to provide a CLR. This could make it much easier for industry to > build and > sell software written in exotic languages for Linux and Mac OS X. > > A tamer but related idea is to implement a Fortran 77 front-end for > LLVM and > then get LAPACK into the LLVM benchmark suite. This could help LLVM to > improve and might provide a faster LAPACK library for the open > source world. > > FFTW is another hugely important numerical library that could be > used for > benchmarking. Aside from simply getting FFTW to work using llvm-gcc, > an > interesting project might be to rewrite the OCaml source code in > FFTW to > generate codelets on-the-fly using LLVM or the CLang front-end. LLVM > can > probably beat GCC here, not least because an LLVM-based > implementation would > not be limited to a set of precompiled codelets. This could help the > millions > of people who use FFTW. > > On an unrelated note, LLVM has great potential for improving OCaml's > FFI. At > the moment, OCaml programmers are expected to write stubs in C and > statically > link them in with their OCaml code. A much better solution would be > to use > LLVM to generate the equivalent of the C stubs at run-time. Calling > OpenGL > directly from OCaml using LLVM without any existing OpenGL bindings > would > make an excellent example. This project could really help the OCaml > community. > > -- > Dr Jon D Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/products/?e > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev