On Wed, Jan 31, 2024 at 10:30 AM Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote: > > On Tue, 30 Jan 2024 12:28:27 PST (-0800), stefanha@xxxxxxxxx wrote: > > On Tue, 30 Jan 2024 at 14:40, Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote: > >> > >> On Mon, 15 Jan 2024 08:32:59 PST (-0800), stefanha@xxxxxxxxx wrote: > >> > Dear QEMU and KVM communities, > >> > QEMU will apply for the Google Summer of Code and Outreachy internship > >> > programs again this year. Regular contributors can submit project > >> > ideas that they'd like to mentor by replying to this email before > >> > January 30th. > >> > >> It's the 30th, sorry if this is late but I just saw it today. +Alistair > >> and Daniel, as I didn't sync up with anyone about this so not sure if > >> someone else is looking already (we're not internally). > >> > >> > Internship programs > >> > --------------------------- > >> > GSoC (https://summerofcode.withgoogle.com/) and Outreachy > >> > (https://www.outreachy.org/) offer paid open source remote work > >> > internships to eligible people wishing to participate in open source > >> > development. QEMU has been part of these internship programs for many > >> > years. Our mentors have enjoyed helping talented interns make their > >> > first open source contributions and some former interns continue to > >> > participate today. > >> > > >> > Who can mentor > >> > ---------------------- > >> > Regular contributors to QEMU and KVM can participate as mentors. > >> > Mentorship involves about 5 hours of time commitment per week to > >> > communicate with the intern, review their patches, etc. Time is also > >> > required during the intern selection phase to communicate with > >> > applicants. Being a mentor is an opportunity to help someone get > >> > started in open source development, will give you experience with > >> > managing a project in a low-stakes environment, and a chance to > >> > explore interesting technical ideas that you may not have time to > >> > develop yourself. > >> > > >> > How to propose your idea > >> > ---------------------------------- > >> > Reply to this email with the following project idea template filled in: > >> > > >> > === TITLE === > >> > > >> > '''Summary:''' Short description of the project > >> > > >> > Detailed description of the project that explains the general idea, > >> > including a list of high-level tasks that will be completed by the > >> > project, and provides enough background for someone unfamiliar with > >> > the codebase to do research. Typically 2 or 3 paragraphs. > >> > > >> > '''Links:''' > >> > * Wiki links to relevant material > >> > * External links to mailing lists or web sites > >> > > >> > '''Details:''' > >> > * Skill level: beginner or intermediate or advanced > >> > * Language: C/Python/Rust/etc > >> > >> I'm not 100% sure this is a sane GSoC idea, as it's a bit open ended and > >> might have some tricky parts. That said it's tripping some people up > >> and as far as I know nobody's started looking at it, so I figrued I'd > >> write something up. > >> > >> I can try and dig up some more links if folks thing it's interesting, > >> IIRC there's been a handful of bug reports related to very small loops > >> that run ~10x slower when vectorized. Large benchmarks like SPEC have > >> also shown slowdowns. > > > > Hi Palmer, > > Performance optimization can be challenging for newcomers. I wouldn't > > recommend it for a GSoC project unless you have time to seed the > > project idea with specific optimizations to implement based on your > > experience and profiling. That way the intern has a solid starting > > point where they can have a few successes before venturing out to do > > their own performance analysis. > > Ya, I agree. That's part of the reason why I wasn't sure if it's a > good idea. At least for this one I think there should be some easy to > understand performance issue, as the loops that go very slowly consist > of a small number of instructions and go a lot slower. > > I'm actually more worried about this running into a rabbit hole of > adding new TCG operations or even just having no well defined mappings > between RVV and AVX, those might make the project really hard. > > > Do you have the time to profile and add specifics to the project idea > > by Feb 21st? If that sounds good to you, I'll add it to the project > > ideas list and you can add more detailed tasks in the coming weeks. > > I can at least dig up some of the examples I ran into, there's been a > handful filtering in over the last year or so. > > This one > <https://gist.github.com/compnerd/daa7e68f7b4910cb6b27f856e6c2beba> > still has a much more than 10x slowdown (73ms -> 13s) with > vectorization, for example. It's probably worth creating a Gitlab issue for this and adding all of the examples there. That way we have a single place to store them all Alistair > > > Thanks, > > Stefan >
