{"thread":{"id":"47936","subject":"Is offloading to GPU a worthwhile feature?","startedAt":"2018-02-27T20:52:13Z","lastAt":"2018-04-11T16:47:00Z","messageCount":5,"participants":["Konstantin Ryabitsev","Stefan Beller","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"340443","messageId":"efc4af6b-53c9-bd02-65f6-9de517f6868e@linuxfoundation.org","threadId":"47936","inReplyTo":null,"subject":"Is offloading to GPU a worthwhile feature?","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2018-02-27T20:52:12Z","receivedAt":"2018-02-27T20:52:13Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"Hi, all:\n\nThis is an entirely idle pondering kind of question, but I wanted to\nask. I recently discovered that some edge providers are starting to\noffer systems with GPU cards in them -- primarily for clients that need\nto provide streaming video content, I guess. As someone who needs to run\na distributed network of edge nodes for a fairly popular git server, I\nwondered if git could at all benefit from utilizing a GPU card for\nsomething like delta calculations or compression offload, or if benefits\nwould be negligible.\n\nI realize this would be silly amounts of work. But, if it's worth it,\nperhaps we can benefit from all the GPU computation libs written for\ncryptocoin mining and use them for something good. :)\n\nBest,\n-- \nKonstantin Ryabitsev\n\n"},{"id":"340470","messageId":"CAGZ79kbJawTH6bPWC+4is+okTf7ZRN5U68JZgOy8EFvaZOtF5g@mail.gmail.com","threadId":"47936","inReplyTo":"efc4af6b-53c9-bd02-65f6-9de517f6868e@linuxfoundation.org","subject":"Re: Is offloading to GPU a worthwhile feature?","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-02-27T22:08:27Z","receivedAt":"2018-02-27T22:08:34Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Feb 27, 2018 at 12:52 PM, Konstantin Ryabitsev\n wrote:\n> compression offload\n\nCurrently there is a series under review that introduces a commit graph\nfile[1], which would allow to not need decompressing objects for a rev walk, but\nhave the walking information as-needed on disk.\n\nOnce walking (as part of negotiation) is done,\nwe'd have to pack a pack file to return to the client,\nwhich maybe can be improved by GPU acceleration[2].\n\nThough once upon a time Junio had proposed to change\nthis part of the protocol as well. Instead of having a packfile\ncatered to a specific user/request, the server would store\nmultiple pack files, which are temporally sorted, e.g.\none \"old\" packfile containing everything that is roughly older\nthan 4 weeks ago, then a \"medium pack file\" that is up to last\nweekend, and then a \"new\" pack that is just this weeks work,\nfollowed by the on-demand pack that is just the latest\ngenerated on the fly.\n\nThe server would just dump these different packfiles\n(concatenated?) at the user, and would need to refresh\nits packfiles occasionally every week or so.\n\n[1] https://public-inbox.org/git/1519698787-190494-1-git-send-email-dstolee@microsoft.com/\n[2] http://on-demand.gputechconf.com/gtc/2014/presentations/S4459-parallel-lossless-compression-using-gpus.pdf\n\n\n> I realize this would be silly amounts of work. But, if it's worth it,\n> perhaps we can benefit from all the GPU computation libs written for\n> cryptocoin mining and use them for something good. :)\n\nCurrently there is work being done on \"protocol v2\"[3], which\nis also motivated by the desire to have easy extensibility in the protocol,\nso if you want to put in a cryptocoin-secret-handshake [into the protocol]\nthat improves the cost of compute or the bandwidth required for your\ntypical use case, it will be possible to do so with ease.\n\n[3] https://public-inbox.org/git/20180207011312.189834-1-bmwill@google.com/\n\nI wonder if the bitmap code can be sped up using GPUs. Every once in a while\nthe discussion floats up bloom filters or inverse bloom filters for\nthe negotiation\npart, and a quick search shows that those could also be sped up using GPUs.\n\nStefan\n"},{"id":"344107","messageId":"86k1thdck7.fsf@gmail.com","threadId":"47936","inReplyTo":"efc4af6b-53c9-bd02-65f6-9de517f6868e@linuxfoundation.org","subject":"Re: Is offloading to GPU a worthwhile feature?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2018-04-08T13:59:04Z","receivedAt":"2018-04-08T13:59:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Hello,\n\nKonstantin Ryabitsev writes:\n\n> This is an entirely idle pondering kind of question, but I wanted to\n> ask. I recently discovered that some edge providers are starting to\n> offer systems with GPU cards in them -- primarily for clients that need\n> to provide streaming video content, I guess. As someone who needs to run\n> a distributed network of edge nodes for a fairly popular git server, I\n> wondered if git could at all benefit from utilizing a GPU card for\n> something like delta calculations or compression offload, or if benefits\n> would be negligible.\n>\n> I realize this would be silly amounts of work. But, if it's worth it,\n> perhaps we can benefit from all the GPU computation libs written for\n> cryptocoin mining and use them for something good. :)\n\nThe problem is that you need to transfer the data from the main memory\n(host memory) geared towards low-latency thanks to cache hierarchy, to\nthe GPU memory (device memory) geared towards bandwidth and parallel\naccess, and back again. So to make sense the time for copying data plus\nthe time to perform calculations on GPU (and not all kinds of\ncomputations can be speed up on GPU -- you need fine-grained massively\ndata-parallel task) must be less than time to perform calculations on\nCPU (with multi-threading).\n\nAlso you would need to keep non-GPU and GPGPU code in sync. Some parts\nof code do not change much; and there also solutions to generate dual\ncode from one source.\n\nStill, it might be good idea,\n-- \nJakub Narębski\n\n"},{"id":"344219","messageId":"57c33d0a-458e-f591-164d-33f8257d3972@linuxfoundation.org","threadId":"47936","inReplyTo":"86k1thdck7.fsf@gmail.com","subject":"Re: Is offloading to GPU a worthwhile feature?","fromName":"Konstantin Ryabitsev","fromEmail":"konstantin@linuxfoundation.org","sentAt":"2018-04-09T17:57:55Z","receivedAt":"2018-04-09T17:58:05Z","isPatch":false,"sender":{"key":"konstantin@linuxfoundation.org","avatar":"https://gravatar.com/avatar/7cb8827c6de56e1bd2dea16508c6708aa43feed3bf3813bcdacecdf96ceadd79?d=mp&s=160"},"body":"On 04/08/18 09:59, Jakub Narebski wrote:\n>> This is an entirely idle pondering kind of question, but I wanted to\n>> ask. I recently discovered that some edge providers are starting to\n>> offer systems with GPU cards in them -- primarily for clients that need\n>> to provide streaming video content, I guess. As someone who needs to run\n>> a distributed network of edge nodes for a fairly popular git server, I\n>> wondered if git could at all benefit from utilizing a GPU card for\n>> something like delta calculations or compression offload, or if benefits\n>> would be negligible.\n> \n> The problem is that you need to transfer the data from the main memory\n> (host memory) geared towards low-latency thanks to cache hierarchy, to\n> the GPU memory (device memory) geared towards bandwidth and parallel\n> access, and back again. So to make sense the time for copying data plus\n> the time to perform calculations on GPU (and not all kinds of\n> computations can be speed up on GPU -- you need fine-grained massively\n> data-parallel task) must be less than time to perform calculations on\n> CPU (with multi-threading).\n\nWould something like this be well-suited for tasks like routine fsck,\nrepacking and bitmap generation? That's the kind of workloads I was\nimagining it would be most well-suited for.\n\n> Also you would need to keep non-GPU and GPGPU code in sync. Some parts\n> of code do not change much; and there also solutions to generate dual\n> code from one source.\n> \n> Still, it might be good idea,\n\nI'm still totally the wrong person to be implementing this, but I do\nhave access to Packet.net's edge systems which carry powerful GPUs for\nprojects that might be needing these for video streaming services. It\nseems a shame to have them sitting idle if I can offload some of the\nRAM- and CPU-hungry tasks like repacking to be running there.\n\nBest,\n-- \nKonstantin Ryabitsev\nDirector, IT Infrastructure Security\nThe Linux Foundation\n\n"},{"id":"344465","messageId":"86h8oh6689.fsf@gmail.com","threadId":"47936","inReplyTo":"57c33d0a-458e-f591-164d-33f8257d3972@linuxfoundation.org","subject":"Re: Is offloading to GPU a worthwhile feature?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2018-04-11T16:46:46Z","receivedAt":"2018-04-11T16:47:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Konstantin Ryabitsev writes:\n> On 04/08/18 09:59, Jakub Narebski wrote:\n\n>>> This is an entirely idle pondering kind of question, but I wanted to\n>>> ask. I recently discovered that some edge providers are starting to\n>>> offer systems with GPU cards in them -- primarily for clients that need\n>>> to provide streaming video content, I guess. As someone who needs to run\n>>> a distributed network of edge nodes for a fairly popular git server, I\n>>> wondered if git could at all benefit from utilizing a GPU card for\n>>> something like delta calculations or compression offload, or if benefits\n>>> would be negligible.\n>> \n>> The problem is that you need to transfer the data from the main memory\n>> (host memory) geared towards low-latency thanks to cache hierarchy, to\n>> the GPU memory (device memory) geared towards bandwidth and parallel\n>> access, and back again. So to make sense the time for copying data plus\n>> the time to perform calculations on GPU (and not all kinds of\n>> computations can be speed up on GPU -- you need fine-grained massively\n>> data-parallel task) must be less than time to perform calculations on\n>> CPU (with multi-threading).\n>\n> Would something like this be well-suited for tasks like routine fsck,\n> repacking and bitmap generation? That's the kind of workloads I was\n> imagining it would be most well-suited for.\n\nAll of those, I think, would need to use some graph algorithms. While\nthere are here ready graph libraries on GPU (like nVidia's nvGRAPH),\ngraphs are irregular structures not that well souted to the SIMD type of\nparallelism that GPU is best for.\n\nI also wonder if the amound of memory on GPU would be enough (and if\nnot, would be it possible to perform calculations in batches).\n\n>> Also you would need to keep non-GPU and GPGPU code in sync. Some parts\n>> of code do not change much; and there also solutions to generate dual\n>> code from one source.\n>> \n>> Still, it might be good idea,\n>\n> I'm still totally the wrong person to be implementing this, but I do\n> have access to Packet.net's edge systems which carry powerful GPUs for\n> projects that might be needing these for video streaming services. It\n> seems a shame to have them sitting idle if I can offload some of the\n> RAM- and CPU-hungry tasks like repacking to be running there.\n\nHappily, GPGPU programming (in CUDA C mainly, which limits use to nVidia\nhardware) is one of my areas if interests...\n\nBest regards,\n--\nJakub Narębski\n"}]}