Alexandre Isoard via llvm-dev
2018-Mar-15 15:45 UTC
[llvm-dev] Commit module to Git after each Pass
Huh. Great! 😁 I don't believe my poor excuse from earlier (else we should map all pipes into files!), but I'm curious why we spend less time in system mode when going through file than pipe. Maybe /dev/null is not as efficient as we might think? I can't believe I'm saying that... On Thu, Mar 15, 2018, 08:25 Fedor Sergeev <fedor.sergeev at azul.com> wrote:> Well, git by itself is so focused on performance, so its not surprising > to me that even using git add/git commit does not cause > performance penalties. >Sure, but still, I write more stuff (entire module) into a slower destination (file). Even ignoring git execution time it's counter intuitive. The only difference is that while I write more, it overwrite itself continuously, instead of being a long linear steam. I was thinking of mmap the file instead of going through our raw_stream, but maybe that's unnecessary then...>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180315/c303c87c/attachment.html>
Philip Reames via llvm-dev
2018-Mar-15 16:16 UTC
[llvm-dev] Commit module to Git after each Pass
The most likely answer is that the printer used by print-after-all is slow. I know there were some changes made around passing in some form of state cache (metadata related?) and that running printers without doing so work, but are dog slow. I suspect the print-after-all support was never updated. Look at what we do for the normal IR emission "-S" and see if print-after-all is out of sync. Philip On 03/15/2018 08:45 AM, Alexandre Isoard via llvm-dev wrote:> Huh. Great! 😁 > > I don't believe my poor excuse from earlier (else we should map all > pipes into files!), but I'm curious why we spend less time in system > mode when going through file than pipe. Maybe /dev/null is not as > efficient as we might think? I can't believe I'm saying that... > > On Thu, Mar 15, 2018, 08:25 Fedor Sergeev <fedor.sergeev at azul.com > <mailto:fedor.sergeev at azul.com>> wrote: > > Well, git by itself is so focused on performance, so its not > surprising > to me that even using git add/git commit does not cause > performance penalties. > > > Sure, but still, I write more stuff (entire module) into a slower > destination (file). Even ignoring git execution time it's counter > intuitive. > > The only difference is that while I write more, it overwrite itself > continuously, instead of being a long linear steam. I was thinking of > mmap the file instead of going through our raw_stream, but maybe > that's unnecessary then... > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180315/a0a74848/attachment.html>
Daniel Sanders via llvm-dev
2018-Mar-15 20:35 UTC
[llvm-dev] Commit module to Git after each Pass
Does https://reviews.llvm.org/D44132 <https://reviews.llvm.org/D44132> help at all?> On 15 Mar 2018, at 09:16, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The most likely answer is that the printer used by print-after-all is slow. I know there were some changes made around passing in some form of state cache (metadata related?) and that running printers without doing so work, but are dog slow. I suspect the print-after-all support was never updated. Look at what we do for the normal IR emission "-S" and see if print-after-all is out of sync. > Philip > > On 03/15/2018 08:45 AM, Alexandre Isoard via llvm-dev wrote: >> Huh. Great! 😁 >> >> I don't believe my poor excuse from earlier (else we should map all pipes into files!), but I'm curious why we spend less time in system mode when going through file than pipe. Maybe /dev/null is not as efficient as we might think? I can't believe I'm saying that... >> >> On Thu, Mar 15, 2018, 08:25 Fedor Sergeev <fedor.sergeev at azul.com <mailto:fedor.sergeev at azul.com>> wrote: >> Well, git by itself is so focused on performance, so its not surprising >> to me that even using git add/git commit does not cause >> performance penalties. >> >> Sure, but still, I write more stuff (entire module) into a slower destination (file). Even ignoring git execution time it's counter intuitive. >> >> The only difference is that while I write more, it overwrite itself continuously, instead of being a long linear steam. I was thinking of mmap the file instead of going through our raw_stream, but maybe that's unnecessary then... >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180315/6965f1e1/attachment.html>