PSF GSoC 2010 (Py3K focus)
Hello, Given the interest in participating in the GSoC this summer, I am forwarding a very interesting email from Titus Brown. If you are interested in doing a GSoC or mentoring, please read his email carefully. Basically, the PSF will be focuing on Py3K-related projects. Given Pauli's work on Py3K support for NumPy, I think we might be in a good position to move forward on porting the rest of our stack to Py3K. So we should focus on projects to: 1. finish porting and testing NumPy with Py3K 2. port and test SciPy with Py3K 3. port and test matplotlib with Py3K 4. port and test ipython with Py3K 5. etc. Given the PSF's stated emphasis this year, it probably doesn't make sense to pursue any non-Py3K projects. Jarrod ---------- Forwarded message ---------- From: C. Titus Brown <ctb@msu.edu> Date: Tue, Mar 2, 2010 at 6:12 AM Subject: [SoC2009-mentors] [ctb@msu.edu: GSoC 2010 - it's on!] To: soc2009-mentors@python.org ----- Forwarded message from "C. Titus Brown" <ctb@msu.edu> ----- Date: Wed, 24 Feb 2010 12:54:52 -0800 From: "C. Titus Brown" <ctb@msu.edu> To: psf-members@python.org Cc: gsoc2010-mentors@python.org Subject: GSoC 2010 - it's on! Hi all, it's that time of year again, and Google has decided to run the Google Summer of Code again! http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/t... http://socghop.appspot.com/ Arc Riley has stepped up to run it for the PSF again this year, and I'm backstopping him. If you are interested in mentoring or kibbitzing on those who are, please sign up for the soc2010-mentors mailing list here, http://mail.python.org/mailman/listinfo/soc2010-mentors This year we're proposing to solicit and prioritize applications for Python 3.x -- 3K tools, porting old projects, etc. Python 2.x projects will be a distinct second. There will be no "core" category this year, although obviously if someone on one of the core teams wants to push a project it'll help! If you have an idea for a project, please send it to the -mentors list and add it to the wiki at http://wiki.python.org/moin/SummerOfCode/2010 We're also going to change a few things up to make it more useful to the PSF. Specifically, - the foundation is going to *require* 1 blog post/wk from each student. - we're going to hire an administrative assistant to monitor the students. - the student application process will be a bit more rigorous and job-app like; the Django SF has been doing this for at least one round and they claim that it results in much better and more serious students. - we'll be focusing on student quality more than on project egalitarianism. If project X can recruit three fantastic students to one fantastic and one mediocre student for project Y, then project X gets three and project Y gets one. The hope is that this will make the GSoC much more useful for Python than it has been in the past. Arc will be posting something to the www.python.org site and python-announce soon, too. Followups to soc2010-mentors. cheers, --titus -- C. Titus Brown, ctb@msu.edu ----- End forwarded message -----
I added Titus' email regarding the PSF's focus on Py3K-related projects to our SoC ideas wiki page: http://projects.scipy.org/scipy/wiki/SummerofCodeIdeas Given Titus' email, this is the most likely list of projects we will get accepted this year: - finish porting NumPy to Py3K - port SciPy to Py3K - port matplotlib to Py3K - port ipython to Py3K Given that we know what projects we will likely have accepted, it is worth starting to flesh these proposals out in detail. Also, we should start discussing how we will choose which student's we want to work on these ports. In particular, we should list what skills and background will be necessary to successfully complete these ports. Thoughts? Ideas? Best, Jarrod
Hello All, Anyone have any hints on speeding up the FFTs on EPD? I've just started to do some larger 1-d convolutions, and am finding the crunching to be somewhat slow for my data sets (Room Impulse Responses * Audio Files). I don't seem to think the EPD installation comes set up with FFTW... and, my first thought is that's what's needed to speed things up. Any advice? Thanks in advance. My best, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr Joseph Anderson Lecturer in Music School of Arts and New Media University of Hull, Scarborough Campus, Scarborough, North Yorkshire, YO11 3AZ, UK T: +44.(0)1723.357341 T: +44.(0)1723.357370 F: +44.(0)1723.350815 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ***************************************************************************************** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *****************************************************************************************
Joseph Anderson wrote:
Hello All,
Anyone have any hints on speeding up the FFTs on EPD?
I've just started to do some larger 1-d convolutions, and am finding the crunching to be somewhat slow for my data sets (Room Impulse Responses * Audio Files).
I don't seem to think the EPD installation comes set up with FFTW... and, my first thought is that's what's needed to speed things up.
Any advice?
The latest EPD comes with Intel MKL; so that's likely what you want to use. It uses the FFTW 3 API, so any code you write would be usable with either MKL (costs money) or FFTW (GPL). Personally I'd use Cython to start wrap the FFTW 3 API... at least if you know some C that shouldn't take long. Dag Sverre
I've written an fftw3 wrapper using ctypes (not cython). In contrast to the numpy and scipy fft functions it uses plans like the fftw3 c-api. However I've tried to make it more usable from Python, i.e. types are detected automatically etc.. You can find the fftw3 wrapper at http://launchpad.net/pyfftw. Cheers Jochen On 03/22/10 10:02, Dag Sverre Seljebotn wrote:
Joseph Anderson wrote:
Hello All,
Anyone have any hints on speeding up the FFTs on EPD?
I've just started to do some larger 1-d convolutions, and am finding the crunching to be somewhat slow for my data sets (Room Impulse Responses * Audio Files).
I don't seem to think the EPD installation comes set up with FFTW... and, my first thought is that's what's needed to speed things up.
Any advice?
The latest EPD comes with Intel MKL; so that's likely what you want to use. It uses the FFTW 3 API, so any code you write would be usable with either MKL (costs money) or FFTW (GPL).
Personally I'd use Cython to start wrap the FFTW 3 API... at least if you know some C that shouldn't take long.
Dag Sverre _______________________________________________ SciPy-User mailing list SciPy-User@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user
Hello Jochen, Ah... Ok, I'll have a look. And... I'm hoping that there will be a simple way to stand in for SciPy.signal.signaltools.fftconvolve. Ideally I'd just like to replace the above convolve with something faster--so I don't have to do much, if any re-writing! My best, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr Joseph Anderson Lecturer in Music School of Arts and New Media University of Hull, Scarborough Campus, Scarborough, North Yorkshire, YO11 3AZ, UK T: +44.(0)1723.362392 T: +44.(0)1723.357370 F: +44.(0)1723.350815 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On 22/03/2010 11:59 am, "Jochen Schroeder" <cycomanic@gmail.com> wrote:
I've written an fftw3 wrapper using ctypes (not cython). In contrast to the numpy and scipy fft functions it uses plans like the fftw3 c-api. However I've tried to make it more usable from Python, i.e. types are detected automatically etc.. You can find the fftw3 wrapper at http://launchpad.net/pyfftw.
Cheers Jochen
***************************************************************************************** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *****************************************************************************************
Hello Dag,
The latest EPD comes with Intel MKL; so that's likely what you want to use. It uses the FFTW 3 API, so any code you write would be usable with either MKL (costs money) or FFTW (GPL).
Ah... I forgot to mention I'm using a OSX on a G5 PPC. From my reading, MKL isn't available for this.
Personally I'd use Cython to start wrap the FFTW 3 API... at least if you know some C that shouldn't take long.
Dag Sverre
Hmm... I'm a bit rough on my C... I have some code written calling scipy.signal.signaltools.fftconvolve. With small arrays, this is fine, but I have some larger RIRs (room impulse responses) that just grind to a halt. I've figured that I can write an overlap-add routine to step through both my input signal (doing this already) AND the kernel. However, my feeling is that a nicely written convolution routine will 'play nicely' and do that for me. Was hoping that there was a simple way to do that, by just setting up FFTW or something else to stand in for scipy.signal.signaltools.fftconvolve. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr Joseph Anderson Lecturer in Music School of Arts and New Media University of Hull, Scarborough Campus, Scarborough, North Yorkshire, YO11 3AZ, UK T: +44.(0)1723.362392 T: +44.(0)1723.357370 F: +44.(0)1723.350815 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ***************************************************************************************** To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *****************************************************************************************
participants (5)
-
Dag Sverre Seljebotn -
Jarrod Millman -
Jochen Schroeder -
Joseph Anderson -
Joseph Anderson