{"thread":{"id":"30159","subject":"GSOC proposal: Improving parallelism","startedAt":"2012-04-06T02:24:28Z","lastAt":"2012-04-06T02:24:28Z","messageCount":1,"participants":["Pushkar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"188620","messageId":"CAMv=a95J2jg8of8nS7CYQdttQ52Z0pHa07HDnsU7kZ2MFnN6ZA@mail.gmail.com","threadId":"30159","inReplyTo":null,"subject":"GSOC proposal: Improving parallelism","fromName":"Pushkar","fromEmail":"pushkarkolhe@gmail.com","sentAt":"2012-04-06T02:24:28Z","receivedAt":"2012-04-06T02:24:28Z","isPatch":false,"sender":{"key":"pushkarkolhe@gmail.com","avatar":null},"body":"Goal:\n---------\nImproving parallelism in various git commands.\n\nAs the idea page says, only git grep seems to be using threads and\nthere are a lot of commands that can use threads.\n\nIt does seem from the codebase that grep uses pthreads and some\ninterface for using threads (for pack-objects) was started in\nthread-utils. To achieve this goal, I will have to mess around with\nthe core git functionality. I think there are 2 ways to go ahead with\nthis project: 1. Adding pthread mutex's specific to each and every\nfunctionality within its current implementation (much like what grep\ndoes), or 2. Write a pthread interface (like thread-utils),\nconsolidate the main data structures that would need to have mutex's\naround them and restructuring some of the code base.\n\nI think 2 is a better option, but I would like to see the codebase a\nlittle longer to understand how much time it would involve. As far as\nthe timeline for gsoc is concerned, I would start of with 2/3 simple\ncommands which could be easily modified. I would some help from my\nmentor and this list to help me identify them. After I have this\nworking, I can proceed to parallelize other git functionalities.\n\nWeek 1-2: Getting familiar with the git codebase\nWeek 2-6: Work on adding basic functionality to thread-utils and\nmessing with git diff/log\nWeek 6-10: Recognizing additional parts of git which can be parallelized\nWeek 10-12: Documentation/Finalizing or just keep continuing with\nadditional git commands if everything is going fine\n\nSuccess Criteria:\n----------------------\nI would identify commands whose efficiency can be improved by using\nthreads. And then measuring time metric for each of those commands on\nseveral git repo datasets.\n\nAbout Me:\n-------------\nI am a second year CS PhD student at Georgia Tech. I have previously\nworked with OpenCV as a gsoc student. I wrote a tracking algorithm for\nthem. I mostly work with robots (like a huge-a** humanoid called Golem\nKrang as you can see on my website). My experience with pthreads and\nwriting multi-threaded programs comes from developing IPC interfaces\nfor robots, because robot control has to be real time and it can be\nunsafe to run robot control programs in a single process. I learnt\nmultithreaded programming from my systems courses at Georgia Tech like\nOperating Systems and High Performance Computing.\n\nI have used git for over 2 years now, as you can see from the github\naccount. I had ever looked into the git codebase only to mess with\ngitweb while setting up gitolite on a server. But I am interested to\nwork with git because previous to this the most complex open source\nproject I had to work with was OpenCV. I realized they were more\ninterested in developing algorithms, and I want to dirty my hands in\nsystems programming now.\n\nYou can hit up the links below to find more about me. I would like to\nhear from you if you think my approach is correct or could be\ndifferent.\n\nWeb: http://www.pushkar.name/\nGithub: https://github.com/pushkar (look at cshm, cshm-net projects,\nshared mem ipc using circular buffers)\nResume: http://pushkar.name/resume.pdf\n\nPushkar Kolhe\n"}]}