Adam, The test case was the Python-3.6.0b3 release, 234 input YAML files. The large majority of time is spent with processing the file input. Next ranked was rendering output. Moving the files to a tmpfs partition didn’t change the time significantly (but I would expect that experiment would yield different results with libYAML). original, single-threaded: processed input files 335.985792875 secs mapped remarks 0.060357093811 secs file rendering 70.5569140911 sec index rendering 1.79133582115 sec x20 processes spawned: processed input files 53.4612071514 secs mapped remarks 0.0622367858887 secs file rendering 8.30268716812 sec index rendering 2.08150291443 sec total time 63.9999139309 secs -Brian From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Adam Nemet via llvm-dev Sent: Thursday, November 17, 2016 11:15 AM To: Cain, Brian <bcain at quicinc.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Bob Haarman <inglorion at google.com> Subject: Re: [llvm-dev] Rewriting opt-viewer in C++ Hi Brian, Great, thanks for doing this! Can you please share the timing printouts? Are we spending most of the time in parsing? Is this on an internal test case? Adam On Nov 16, 2016, at 9:43 PM, Cain, Brian <bcain at quicinc.com <mailto:bcain at quicinc.com> > wrote: If the decision on whether this should swing Python or C++ is still open, here’s some food for thought: it’s trivially parallelizable. I lobbed some stuff in <https://reviews.llvm.org/D26789> https://reviews.llvm.org/D26789 I used the pure python PyYAML and got a speedup of ~4x on my test case. I expect you might still be able to get an improvement with libYAML + a patch like this one. FWIW prior to this I also tried PyPy (w/original opt-viewer.py+pure python PyYAML) and got a very modest improvement. I haven’t tried revisiting it after parallelization. -Brian From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Adam Nemet via llvm-dev Sent: Tuesday, November 15, 2016 10:14 PM To: Bob Haarman <inglorion at google.com <mailto:inglorion at google.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Rewriting opt-viewer in C++ Well, we’re talking about completely different inputs. Can you please try the libYAML version with your input and do some profiling to address the comments in this thread. There are clear advantages to keeping the tooling around optimization records in Python. Besides syntax highlighting, there are other tools we can build around it (e.g. diffing tool for performance regression analysis, stats, SQL exporting) so having a Python module (or bindings) to expose this programmatically sounds pretty attractive to me. Adam On Nov 15, 2016, at 5:55 PM, Bob Haarman < <mailto:inglorion at google.com> inglorion at google.com> wrote: That's compared to the implementation with the Python parser. So if the libYAML parser is 6x the speed of that, the C++ version would be about 10x the speed of the implementation with libYAML, instead of 60x. On Tue, Nov 15, 2016 at 10:50 AM, Adam Nemet < <mailto:anemet at apple.com> anemet at apple.com> wrote: On Nov 15, 2016, at 10:33 AM, Bob Haarman < <mailto:inglorion at google.com> inglorion at google.com> wrote: Thanks for your comments, everyone! I'll try to answer the questions people have asked. First, let me say that I like Python, so I would be happy to keep the tool in Python if people feel that is a better way to go and we can still get it to go fast. As for precedent, we have several Python scripts already shipping with LLVM, including lit, and Python is listed in the requirements, so I imagine it's fine from that perspective. Having said that, the C++ version is quite a lot faster. I'm seeing about a 60x difference in how long it takes to generate HTML. This is with the C++ version doing a bit more work - specifically, it correctly encodes characters that have special meaning to HTML. I've been testing this on a build of the Chromium web browser with reports for the inline pass. On my machine, processing only the storage directory takes about 7 seconds with the C++ version and about 6 minutes and 20 seconds with the Python version. The v8 directory takes about 35 seconds with the C++ version and 44 minutes with the Python version. Processing the whole build takes about 13 minutes with the C++ version; when I tried it with the Python version over night, it was still going 14 hours later. Is this compared against the libYAML parser or the original Python parser? See my mail from last night. Adam The way I would like to use the tool is to perform a compilation and then look at the optimization report to look at which optimizations were missed and why, then change the code and/or the compiler to see if we can get faster code to be emitted. Ideally, I would like to have the optimization report ready for viewing soon after the compilation. Being able to generate the report in seconds, or less than a second, is definitely more useful to my use case than taking minutes. I figured we might get a good speedup from rewriting the tool in C++, and if we ever were going to do that, it would be easier to do it when the tool was relatively simple, as it is now. I believe my rewrite is complete now, and I think the increase in speed actually makes the tool more useful in that it can now feasibly be used on larger projects. I'll clean up the code a bit (it's very much proof of concept now) and put it up for review once that's done. Bob On Mon, Nov 14, 2016 at 9:12 AM, Adam Nemet < <mailto:anemet at apple.com> anemet at apple.com> wrote: Again I am still undecided which way this should go but I was also wondering about the speed difference if we used the C-based parser in PyYAML ( <http://pyyaml.org/wiki/LibYAML> http://pyyaml.org/wiki/LibYAML). On Nov 13, 2016, at 12:19 AM, Adam Nemet < <mailto:anemet at apple.com> anemet at apple.com> wrote: Hi Bob, I am glad you’re finding opt-viewer useful. I am generally fine this being rewritten in C++. The idea was that once the prototype proves itself to be useful this would be considered. Do you have ideas how to get syntax highlighting implemented? In Python, Pygments makes this easy. Another usage model I was considering is for people who ssh to remote servers for their builds. In this case it should be easy in Python to have a simple HTTP server started in opt-viewer. On the other hand, I am not sure if we have precedence to ship tools written in Python in LLVM so we may *have to* move. Adam On Nov 11, 2016, at 11:50 PM, Bob Haarman < <mailto:llvm at inglorion.net> llvm at inglorion.net> wrote: Hi Adam, Thank you for writing opt-viewer! I've been playing around with it and found it helps me understand what optimizations were performed, which were missed, and why, as well as easily navigate to the relevant code. Wanting to use it on larger projects, I found that it can take a while to analyze the optimization reports. Since there doesn't seem to be too much code in it yet, I figured it wouldn't be too much work to implement the same functionality in C++, which should give us a nice speedup compared to the current Python implementation. I have something that implements most of the functionality: the index page is generated and links to lines on source pages, which are also generated, but I haven't gotten to annotations on source pages yet. I expect to put up some code for review next week, but wanted to post here in case others are thinking along similar lines so we can hopefully avoid duplicating effort. Cheers, Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/b08da7c7/attachment.html>
Hi Brian,> On Nov 17, 2016, at 3:05 PM, Brian Cain <bcain at codeaurora.org> wrote: > > Adam, > > The test case was the Python-3.6.0b3 release, 234 input YAML files. The large majority of time is spent with processing the file input. Next ranked was rendering output. Moving the files to a tmpfs partition didn’t change the time significantly (but I would expect that experiment would yield different results with libYAML). > > > original, single-threaded: > processed input files 335.985792875 secs > mapped remarks 0.060357093811 secs > file rendering 70.5569140911 sec > index rendering 1.79133582115 sec > > x20 processes spawned: > processed input files 53.4612071514 secs > mapped remarks 0.0622367858887 secs > file rendering 8.30268716812 sec > index rendering 2.08150291443 sec > total time 63.9999139309 secsIsn’t this actually an improvement of over 6x rather than the 4x you mentioned? ;) Anyhow, do you want to properly submit a review for this? I’d like to try it with libYAML. In the new review, you need to add llvm-commits as a subscriber. You may also want to split up main into smaller functions. Thanks! Adam> > > -Brian > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Adam Nemet via llvm-dev > Sent: Thursday, November 17, 2016 11:15 AM > To: Cain, Brian <bcain at quicinc.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org>; Bob Haarman <inglorion at google.com> > Subject: Re: [llvm-dev] Rewriting opt-viewer in C++ > > Hi Brian, > > Great, thanks for doing this! > > Can you please share the timing printouts? Are we spending most of the time in parsing? > > Is this on an internal test case? > > Adam > >> On Nov 16, 2016, at 9:43 PM, Cain, Brian <bcain at quicinc.com <mailto:bcain at quicinc.com>> wrote: >> >> If the decision on whether this should swing Python or C++ is still open, here’s some food for thought: it’s trivially parallelizable. >> >> I lobbed some stuff in https://reviews.llvm.org/D26789 <https://reviews.llvm.org/D26789> >> >> I used the pure python PyYAML and got a speedup of ~4x on my test case. I expect you might still be able to get an improvement with libYAML + a patch like this one. >> >> FWIW prior to this I also tried PyPy (w/original opt-viewer.py+pure python PyYAML) and got a very modest improvement. I haven’t tried revisiting it after parallelization. >> >> -Brian >> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Adam Nemet via llvm-dev >> Sent: Tuesday, November 15, 2016 10:14 PM >> To: Bob Haarman <inglorion at google.com <mailto:inglorion at google.com>> >> Cc: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> >> Subject: Re: [llvm-dev] Rewriting opt-viewer in C++ >> >> Well, we’re talking about completely different inputs. Can you please try the libYAML version with your input and do some profiling to address the comments in this thread. >> >> There are clear advantages to keeping the tooling around optimization records in Python. Besides syntax highlighting, there are other tools we can build around it (e.g. diffing tool for performance regression analysis, stats, SQL exporting) so having a Python module (or bindings) to expose this programmatically sounds pretty attractive to me. >> >> Adam >> >>> On Nov 15, 2016, at 5:55 PM, Bob Haarman <inglorion at google.com <mailto:inglorion at google.com>> wrote: >>> >>> That's compared to the implementation with the Python parser. So if the libYAML parser is 6x the speed of that, the C++ version would be about 10x the speed of the implementation with libYAML, instead of 60x. >>> >>> On Tue, Nov 15, 2016 at 10:50 AM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote: >>>> >>>>> On Nov 15, 2016, at 10:33 AM, Bob Haarman <inglorion at google.com <mailto:inglorion at google.com>> wrote: >>>>> >>>>> Thanks for your comments, everyone! I'll try to answer the questions people have asked. First, let me say that I like Python, so I would be happy to keep the tool in Python if people feel that is a better way to go and we can still get it to go fast. As for precedent, we have several Python scripts already shipping with LLVM, including lit, and Python is listed in the requirements, so I imagine it's fine from that perspective. >>>>> >>>>> Having said that, the C++ version is quite a lot faster. I'm seeing about a 60x difference in how long it takes to generate HTML. This is with the C++ version doing a bit more work - specifically, it correctly encodes characters that have special meaning to HTML. I've been testing this on a build of the Chromium web browser with reports for the inline pass. On my machine, processing only the storage directory takes about 7 seconds with the C++ version and about 6 minutes and 20 seconds with the Python version. The v8 directory takes about 35 seconds with the C++ version and 44 minutes with the Python version. Processing the whole build takes about 13 minutes with the C++ version; when I tried it with the Python version over night, it was still going 14 hours later. >>>> >>>> Is this compared against the libYAML parser or the original Python parser? See my mail from last night. >>>> >>>> Adam >>>> >>>> >>>> >>>>> The way I would like to use the tool is to perform a compilation and then look at the optimization report to look at which optimizations were missed and why, then change the code and/or the compiler to see if we can get faster code to be emitted. Ideally, I would like to have the optimization report ready for viewing soon after the compilation. Being able to generate the report in seconds, or less than a second, is definitely more useful to my use case than taking minutes. I figured we might get a good speedup from rewriting the tool in C++, and if we ever were going to do that, it would be easier to do it when the tool was relatively simple, as it is now. I believe my rewrite is complete now, and I think the increase in speed actually makes the tool more useful in that it can now feasibly be used on larger projects. I'll clean up the code a bit (it's very much proof of concept now) and put it up for review once that's done. >>>>> >>>>> Bob >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Nov 14, 2016 at 9:12 AM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote: >>>>>> Again I am still undecided which way this should go but I was also wondering about the speed difference if we used the C-based parser in PyYAML (http://pyyaml.org/wiki/LibYAML <http://pyyaml.org/wiki/LibYAML>). >>>>>> >>>>>>> On Nov 13, 2016, at 12:19 AM, Adam Nemet <anemet at apple.com <mailto:anemet at apple.com>> wrote: >>>>>>> >>>>>>> Hi Bob, >>>>>>> >>>>>>> I am glad you’re finding opt-viewer useful. I am generally fine this being rewritten in C++. The idea was that once the prototype proves itself to be useful this would be considered. >>>>>>> >>>>>>> Do you have ideas how to get syntax highlighting implemented? In Python, Pygments makes this easy. >>>>>>> >>>>>>> Another usage model I was considering is for people who ssh to remote servers for their builds. In this case it should be easy in Python to have a simple HTTP server started in opt-viewer. >>>>>>> >>>>>>> On the other hand, I am not sure if we have precedence to ship tools written in Python in LLVM so we may *have to* move. >>>>>>> >>>>>>> Adam >>>>>>> >>>>>>>> On Nov 11, 2016, at 11:50 PM, Bob Haarman <llvm at inglorion.net <mailto:llvm at inglorion.net>> wrote: >>>>>>>> >>>>>>>> Hi Adam, >>>>>>>> >>>>>>>> Thank you for writing opt-viewer! I've been playing around with it and found it helps me understand what optimizations were performed, which were missed, and why, as well as easily navigate to the relevant code. Wanting to use it on larger projects, I found that it can take a while to analyze the optimization reports. Since there doesn't seem to be too much code in it yet, I figured it wouldn't be too much work to implement the same functionality in C++, which should give us a nice speedup compared to the current Python implementation. I have something that implements most of the functionality: the index page is generated and links to lines on source pages, which are also generated, but I haven't gotten to annotations on source pages yet. I expect to put up some code for review next week, but wanted to post here in case others are thinking along similar lines so we can hopefully avoid duplicating effort. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Bob-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/4281f704/attachment.html>
On Nov 17, 2016 10:36 PM, "Adam Nemet via llvm-dev" <llvm-dev at lists.llvm.org> wrote:> > Hi Brian, > >> On Nov 17, 2016, at 3:05 PM, Brian Cain <bcain at codeaurora.org> wrote: >> >> Adam, >> >> The test case was the Python-3.6.0b3 release, 234 input YAML files. Thelarge majority of time is spent with processing the file input. Next ranked was rendering output. Moving the files to a tmpfs partition didn’t change the time significantly (but I would expect that experiment would yield different results with libYAML).>> >> >> original, single-threaded: >> processed input files 335.985792875 secs >> mapped remarks 0.060357093811 secs >> file rendering 70.5569140911 sec >> index rendering 1.79133582115 sec >> >> x20 processes spawned: >> processed input files 53.4612071514 secs >> mapped remarks 0.0622367858887 secs >> file rendering 8.30268716812 sec >> index rendering 2.08150291443 sec >> total time 63.9999139309 secs > > > Isn’t this actually an improvement of over 6x rather than the 4x youmentioned? ;)>The 4x was measured on a smaller subset of the 234 input files.> Anyhow, do you want to properly submit a review for this? I’d like totry it with libYAML.> > In the new review, you need to add llvm-commits as a subscriber. You mayalso want to split up main into smaller functions.>Ok, I'll clean it up and make a real review.> Thanks! > > Adam > >> >> >> -Brian >> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On BehalfOf Adam Nemet via llvm-dev>> Sent: Thursday, November 17, 2016 11:15 AM >> To: Cain, Brian <bcain at quicinc.com> >> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Bob Haarman <inglorion at google.com > >> Subject: Re: [llvm-dev] Rewriting opt-viewer in C++ >> >> Hi Brian, >> >> Great, thanks for doing this! >> >> Can you please share the timing printouts? Are we spending most of thetime in parsing?>> >> Is this on an internal test case? >> >> Adam >> >>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161117/fd72259b/attachment-0001.html>