Re: [Monotone-devel] using empty() instead of size()
Markus Wanner writes: > Eric Anderson wrote: > > Assuming that the code for getting memory usage is derived from the > > code I wrote a long time ago (output looks similar, so likely); I > > expect that the memory consumption differences are just sampling > > effects. It sampled every 1 second or so, and so changes to runtime > > can affect when the memory usage is sampled and hence the estimated > > memory usage. > > Yeah, I've been questioning the 'avg' value as well. If you now tell me > that sampling is done at 1 second intervals, then I even suspect the max > value to not be very meaningful. If a run went on for a while (20-60s), and you ran it multiple times (I did), it's generally pretty good, but it certainly wasn't something that should be trusted blindly. I generally ignored the memory information unless I was looking at something > 1.5x. -Eric ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Hi, Eric Anderson wrote: > Assuming that the code for getting memory usage is derived from the > code I wrote a long time ago (output looks similar, so likely); I > expect that the memory consumption differences are just sampling > effects. It sampled every 1 second or so, and so changes to runtime > can affect when the memory usage is sampled and hence the estimated > memory usage. Yeah, I've been questioning the 'avg' value as well. If you now tell me that sampling is done at 1 second intervals, then I even suspect the max value to not be very meaningful. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Hi, Stephen Leake wrote: > I need the profile info more than the total time; I want to find out > which particular function in mtn is slow. Then I want to add a ticker > output to it, so I will know it's not hung; then maybe speed it up > somehow. Guessing you are on Linux, that sounds more like you should have a look at oprofile and try the exact mtn actions you want profiling data for. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Zack Weinberg writes: > On Mon, Sep 22, 2008 at 3:09 PM, Markus Wanner <[EMAIL PROTECTED]> wrote: > > This leads me to think that the STL implementation doesn't provide an O(1) > > implementation for size()... savings is avg memory consumption seems to > > confirm this, no? > > Now that's just bloody weird. I can't think of any reason size() > would need to *allocate memory*. Assuming that the code for getting memory usage is derived from the code I wrote a long time ago (output looks similar, so likely); I expect that the memory consumption differences are just sampling effects. It sampled every 1 second or so, and so changes to runtime can affect when the memory usage is sampled and hence the estimated memory usage. Tools like valgrind in it's massif mode will give you better memory usage comparisons, but result in big slowdowns. -Eric ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Markus Wanner <[EMAIL PROTECTED]> writes: > Hi, > > Stephen Leake wrote: >> I don't know how to interpret these numbers. What tool did you run to >> generate them? > > It's the output of compare.py from the nvm.cbench branch, which takes > CSV inputs from the pythonic benchmark suite. Ok, thanks. >> I need to get some profile data on running mtn over NFS; something is >> deadly slow. Would this tool help with that? > > You can certainly run benchmarks over NFS as well. Although I'm not sure > how helpful that is. You are already saying it's deadly slow. What > difference does a benchmark value make against real world > experience? I need the profile info more than the total time; I want to find out which particular function in mtn is slow. Then I want to add a ticker output to it, so I will know it's not hung; then maybe speed it up somehow. The long term plan is to get rid of the NFS link, but we are stuck with it for a while. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Hi, Stephen Leake wrote: > I don't know how to interpret these numbers. What tool did you run to > generate them? It's the output of compare.py from the nvm.cbench branch, which takes CSV inputs from the pythonic benchmark suite. > I need to get some profile data on running mtn over NFS; something is > deadly slow. Would this tool help with that? You can certainly run benchmarks over NFS as well. Although I'm not sure how helpful that is. You are already saying it's deadly slow. What difference does a benchmark value make against real world experience? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Hi, Derek Scherger wrote: > Even if size does have to traverse a list to count the elements one > would expect that traversing an *empty* list should be reasonably quick. Yeah, but it the list is large, traversing is rather expensive, compared to aborting and returning false upon seeing the first element, as empty() can do. It's the difference between wanting to know the exact size or just being interested if there are some elements or not. > All the same, empty() does seem a bit easier on the eyes Yeah, I also like empty() better. > and if it wins on performance too then what the heck. For what it's worth, I suspected the slightly increased binary size and additional link time required for the nvm.cbr branch's binary and rerun the benchmark again just exactly the revision before: new: 805c482bc9bb80cd393be7d3ba01a65377d91d9c ref: 639a3179473e718e8b01b9c99232fa1f81ca7f61 This time I took special care to shut down other services on the machine so that the benchmark should really be the absolutely only load. With enough test runs I cannot really confirm the speed gain. See the three results below. I don't think it's really the nvm.cbr branch, as the executable didn't grow significantly. It would at least really surprise me. I rather think it's not such a good benchmark, because it varies quite a lot and it seems to measure a lot of disc i/o due to the drop_caches. I'm not sure we really want to exclude that from our benchmarks, because normally you run operations such as annotate with quite well populated caches. Anyway, sorry for the noise. I've just dropped the comment from NEWS. Regards Markus Wanner > annotate-a-ref.csv annotate-a-new.csv p > annotate-avg-resident-MiB 23.53 23.49 0.70 > annotate-avg-size-MiB 118.68 118.62 0.84 > annotate-max-resident-MiB 34.20 34.17 0.00 > annotate-max-size-MiB 130.86 130.86 nan > annotate-num-samples1753.601757.40 0.87 > annotate-system-time 0.86 0.87 0.67 >annotate-user-time 3.49 3.50 0.62 >annotate-wall-time 9.18 9.11 0.27 > annotate-b-ref.csv annotate-b-new.csv p > annotate-avg-resident-MiB 11.89 11.68 0.44 > annotate-avg-size-MiB 103.59 103.74 0.75 > annotate-max-resident-MiB 18.63 18.61 0.00 > annotate-max-size-MiB 115.32 115.32 nan > annotate-num-samples 602.20 540.10 0.33 > annotate-system-time 0.18 0.18 0.70 >annotate-user-time 0.51 0.52 0.40 >annotate-wall-time 3.24 2.87 0.26 > annotate-c-ref.csv annotate-c-new.csv p > annotate-avg-resident-MiB 11.83 11.35 0.31 > annotate-avg-size-MiB 103.50 102.42 0.41 > annotate-max-resident-MiB 18.28 18.26 0.00 > annotate-max-size-MiB 114.93 114.93 nan > annotate-num-samples 590.60 676.10 0.26 > annotate-system-time 0.24 0.27 0.12 >annotate-user-time 0.75 0.75 0.77 >annotate-wall-time 3.19 3.66 0.21 > annotate-d-ref.csv annotate-d-new.csv p > annotate-avg-resident-MiB 27.30 26.69 0.18 > annotate-avg-size-MiB 123.26 122.28 0.18 > annotate-max-resident-MiB 36.11 36.08 0.00 > annotate-max-size-MiB 132.78 132.78 nan > annotate-num-samples2699.902719.70 0.80 > annotate-system-time 1.07 1.04 0.32 >annotate-user-time 7.85 7.89 0.33 >annotate-wall-time 13.87 14.22 0.36 > > > > annotate-a-ref.csv annotate-a-new.csv p > annotate-avg-resident-MiB 23.42 23.43 0.99 > annotate-avg-size-MiB 118.53 118.56 0.93 > annotate-max-resident-MiB 34.19 34.17 0.00 > annotate-max-size-MiB 130.86 130.86 nan > annotate-num-samples1708.501741.50 0.37 > annotate-system-time 0.88 0.85 0.23 >annotate-user-time 3.48 3.50 0.34 >annotate-wall-time 9.11 9.16 0.63 > annotate-b-ref.csv annotate-b-new.csv p > annotate-avg-resident-MiB
Re: [Monotone-devel] using empty() instead of size()
Markus Wanner <[EMAIL PROTECTED]> writes: >> annotate-a-ref.csv annotate-a-new.csv p >> annotate-avg-resident-MiB 30.12 23.72 0.00 >> annotate-avg-size-MiB 125.68 119.28 0.00 >> annotate-max-resident-MiB 40.38 34.22 0.00 >> annotate-max-size-MiB 136.90 130.86 0.00 >> annotate-num-samples2089.201982.80 0.16 >> annotate-system-time 0.82 0.85 0.11 >>annotate-user-time 4.35 3.49 0.00 >>annotate-wall-time 10.60 10.06 0.16 I don't know how to interpret these numbers. What tool did you run to generate them? I need to get some profile data on running mtn over NFS; something is deadly slow. Would this tool help with that? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Even if size does have to traverse a list to count the elements one would expect that traversing an *empty* list should be reasonably quick. All the same, empty() does seem a bit easier on the eyes and if it wins on performance too then what the heck. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
On Mon, Sep 22, 2008 at 3:09 PM, Markus Wanner <[EMAIL PROTECTED]> wrote: > This leads me to think that the STL implementation doesn't provide an O(1) > implementation for size()... savings is avg memory consumption seems to > confirm this, no? Now that's just bloody weird. I can't think of any reason size() would need to *allocate memory*. Please do carry on with the empty() conversions; I may be doing the grumpy old man thing about crummy STL implementations, but those are nonetheless what we have to live with. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Hi, Zack Weinberg wrote: Sure, but C++98 requires size() to be O(1) for every container, so there's really no excuse for a 4-15% performance difference. Here are the results I got from this test run. It's a debian lenny machine, comparing these revisions: new: 805c482bc9bb80cd393be7d3ba01a65377d91d9c ref: d1bd931bd76507267b99e57be07125dbb2335fd5 (which is from nvm.cvsimport-branch-reconstruction, but that does only change rcs_import.cc, so annotate shouldn't be affected at all) annotate-a-ref.csv annotate-a-new.csv p annotate-avg-resident-MiB 30.12 23.72 0.00 annotate-avg-size-MiB 125.68 119.28 0.00 annotate-max-resident-MiB 40.38 34.22 0.00 annotate-max-size-MiB 136.90 130.86 0.00 annotate-num-samples2089.201982.80 0.16 annotate-system-time 0.82 0.85 0.11 annotate-user-time 4.35 3.49 0.00 annotate-wall-time 10.60 10.06 0.16 annotate-b-ref.csv annotate-b-new.csv p annotate-avg-resident-MiB 17.62 11.75 0.00 annotate-avg-size-MiB 110.95 103.95 0.00 annotate-max-resident-MiB 24.82 18.66 0.00 annotate-max-size-MiB 121.46 115.32 0.00 annotate-num-samples 702.60 599.80 0.17 annotate-system-time 0.19 0.18 0.26 annotate-user-time 0.68 0.51 0.00 annotate-wall-time 3.59 3.05 0.16 annotate-c-ref.csv annotate-c-new.csv p annotate-avg-resident-MiB 18.42 12.45 0.00 annotate-avg-size-MiB 111.05 104.89 0.00 annotate-max-resident-MiB 24.48 18.30 0.00 annotate-max-size-MiB 121.06 114.96 0.00 annotate-num-samples 778.40 712.40 0.05 annotate-system-time 0.25 0.24 0.67 annotate-user-time 0.95 0.74 0.00 annotate-wall-time 3.95 3.63 0.06 annotate-d-ref.csv annotate-d-new.csv p annotate-avg-resident-MiB 34.34 28.24 0.00 annotate-avg-size-MiB 130.00 124.07 0.00 annotate-max-resident-MiB 42.30 35.93 0.00 annotate-max-size-MiB 138.82 132.57 0.00 annotate-num-samples3443.203213.50 0.00 annotate-system-time 1.02 1.02 0.84 annotate-user-time 8.85 7.82 0.00 annotate-wall-time 17.48 16.29 0.00 This leads me to think that the STL implementation doesn't provide an O(1) implementation for size()... savings is avg memory consumption seems to confirm this, no? Other explanations? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Hi, Zack Weinberg wrote: Sure, but C++98 requires size() to be O(1) for every container, so there's really no excuse for a 4-15% performance difference. Hm.. I didn't know that, thanks. Very strange. I'm just re-running the annotate benchmarks... Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
On Mon, Sep 22, 2008 at 2:18 PM, Markus Wanner <[EMAIL PROTECTED]> wrote: >> I'm honestly surprised .empty() and .size() == 0 don't generate >> identical code, but hey. Thanks! > > For example for doubly linked lists, it's pretty simple to tell whether they > are empty or not, but counting the number of elements in the list requires > traversing the list. Sure, but C++98 requires size() to be O(1) for every container, so there's really no excuse for a 4-15% performance difference. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Spooky. On Mon, Sep 22, 2008 at 11:18:14PM +0200, Markus Wanner wrote: > Hi, > > Zack Weinberg wrote: >> I'm honestly surprised .empty() and .size() == 0 don't generate >> identical code, but hey. Thanks! > > For example for doubly linked lists, it's pretty simple to tell whether > they are empty or not, but counting the number of elements in the list > requires traversing the list. > > I'm not sure how other containers are affected. Plus some STL > implementations might have optimizations for .size() to not require it to > traverse the elements. However, its an optimization not required by the > standard, AFAIK. > > Regards > > Markus > > > > ___ > Monotone-devel mailing list > Monotone-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/monotone-devel -- I'm Mr. T and this is my Nightelf Mohawk. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
On Mon, Sep 22, 2008 at 02:14:25PM -0700, Zack Weinberg wrote: > I'm honestly surprised .empty() and .size() == 0 don't generate > identical code, but hey. Thanks! Imagine a linked list implementation. Finding out whether the pointer to the first element is NULL is simple, and enough to answer whether the list is empty. Finding out the number of elements requires traversing the list. Of course you can implement a linked list differently, but that'd be how a very simple implementation might behave. At least some STL list implementations behave in a similar fashion. Jens ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
Hi, Zack Weinberg wrote: I'm honestly surprised .empty() and .size() == 0 don't generate identical code, but hey. Thanks! For example for doubly linked lists, it's pretty simple to tell whether they are empty or not, but counting the number of elements in the list requires traversing the list. I'm not sure how other containers are affected. Plus some STL implementations might have optimizations for .size() to not require it to traverse the elements. However, its an optimization not required by the standard, AFAIK. Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] using empty() instead of size()
On Mon, Sep 22, 2008 at 1:26 PM, Markus Wanner <[EMAIL PROTECTED]> wrote: > in rev 805c482bc9bb80cd393be7d3ba01a65377d91d9c I've replaced lots of > .size() == 0 (and similar) calls with .empty(). For one thing, I personally > find it clearer and easier to read. And it's considered good practice > because the implementation for most STL containers is simpler and faster. > > I didn't notice any improvement with the commit benchmark, but the annotate > one from nvm.cbench showed speedups between 4% and 15%. I'm honestly surprised .empty() and .size() == 0 don't generate identical code, but hey. Thanks! zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
