Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
Sounds great, thanks again! Doug On 06/29/2012 02:20 PM, Oleg Moskalenko wrote: Doug, --nthreads option corresponds to --parallel option of NGNU and it will be renamed. The other four proprietary options will be marked as non-portable in the man page. After nthreads==parallel renaming, NBSD will support all NGNU options. Thank you for the suggestion. Oleg -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Friday, June 29, 2012 2:02 PM To: Oleg Moskalenko Cc: FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=... (multi-threaded build only) Oleg, First, thank you very much for providing both the performance numbers, and the breakdown in the differences in command line options. Everything looks great, my only concern is the above. Are there similar/identical options in NGNU that correspond to the options above? If so, I would be hesitant to add new names for them because it hurts portability between platforms. If these are totally new features then my assumption is that you have clearly marked them as non-portable in the man page? Once again, I really appreciate you addressing my concerns, and your hard work on this project. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
I am going to post the ministat results of my tests: 1) Text sort of 167-Mb file (1,000,000 random lines, each contains several fields, each field is either a floating point number or a binary string with random symbols between 0 and 255). Sorted on second field (-k 2,2 option): x OGNU + NGNU * NBSD (multi-threaded) +--+ | x* + | | x x * +++ | |x x * ** * +++* * **| | |_A_| |___M_|AA___| | +--+ N Min MaxMedian AvgStddev x 10 5.758 5.937 5.8485.8508 0.057276716 + 10 6.29 6.366 6.3326.33020.02123833 Difference at 95.0% confidence 0.4794 +/- 0.0405862 8.19375% +/- 0.693687% (Student's t, pooled s = 0.0431954) * 10 6.067 7.228 6.2256.34490.35979422 Difference at 95.0% confidence 0.4941 +/- 0.242055 8.445% +/- 4.13713% (Student's t, pooled s = 0.257616) == 2) Same file, numeric sort on the same field (-k 2,2 -n option): x OGNU.n + NGNU.n * NBSD.n (multi-threaded) +--+ | * x x x +++| | * xx x x | | |MA_| |__A_| |A | +--+ N Min MaxMedian AvgStddev x 10 7.142 7.338 7.2167.2179 0.066727389 + 10 8.231 8.307 8.2718.2677 0.022701199 Difference at 95.0% confidence 1.0498 +/- 0.0468287 14.5444% +/- 0.648785% (Student's t, pooled s = 0.0498392) * 10 6.91 7.094 6.986.9864 0.061449528 Difference at 95.0% confidence -0.2315 +/- 0.0602683 -3.2073% +/- 0.834983% (Student's t, pooled s = 0.0641428) = On these two tests, all three program produced the same output. So, on text sort, NBSD is slightly slower than GNU; on simple numeric sort, NBSD is slightly faster. I did not use ministat for complex numeric sort (-g) because the performance difference is huge (in favor of NBSD) and it would make no sense. Thanks Oleg -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Oleg Moskalenko Sent: Wednesday, June 27, 2012 6:45 PM To: FreeBSD Current Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT Hi As promised, I am supplying an example of comparison between several sort programs. The test file is a randomly generated 1,000,000 lines, each line contain a single floating point number. We are going to sort it three ways - as text, as -n numeric sort, and as -g numeric sort, with 4 programs: 1) Old BSD/GNU sort 5.3.0 2) New GNU sort 8.15 3) New BSD sort, single threaded 4) New BSD sort, multi-threaded The system is a 3-CPUs system, 1.5Gb of RAM, FreeBSD version 8.2. All times are in seconds. Locale C. == TEXT SORT sys user real Old BSD/GNU sort:0.0 1.692 2.008 New GNU sort:0.0 2.279 1.605 New BSD sort, st:0.0 1.964 2.300 New BSD sort, mt:0.0 2.385 1.897 == NUMERIC SORT -n sys user real Old BSD/GNU sort:0.0 4.357 4.674 New GNU sort:0.0 8.839 5.134 New BSD sort, st:0.0 5.308 5.592 New BSD sort, mt:0.0 4.581 2.489 == NUMERIC SORT -g sys user real Old BSD/GNU sort:0.0 45.37845.630 New GNU sort: ~450~121 ~300 New BSD sort, st:0.334.334 5.992 New BSD sort, mt:11.140 4.624 8.983 === Thanks Oleg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
Now I am going to provide the second informational part about the new BSD sort: the differences between the new BSD sort and the GNU sort programs. Below: NBSD - new BSD sort; OGNU - old BSD/GNU sort, version 5.3.0; NGNU - new GNU sort, version 8.15. There are several areas: 1) -k option (sort fields/keys), with single byte locales. The -k option functionality is described in POSIX standard with deceitfully simple wording. Unfortunately, the real meaning is rather complex, and sometimes it defies the common sense. For example, a sort key can spread across boundaries with subsequent sort keys. A common-sense-based implementation would fail the POSIX standard. The OGNU implementation fails to follow the standard. In our tests, there are thousands various use cases when it does not work properly. The OGNU exact algorithm and the failure pattern is a mystery for us. The NGNU implements the POSIX algorithm properly, and the NBSD is compatible with NGNU when using -k in single-byte locales. 2) -k option (sort fields/keys), with multi-byte locales. Here the situation is reverse. During the -k calculation, NGNU basically ignores the symbol sizes (but it does not ignore the symbol sizes when it compares the fields). The result is that the sort keys are not calculated correctly by the NGNU. OGNU, on the other hand, seems to use the correct symbol sizes, but it is still using incorrect algorithm. So, the overall picture is: - OGNU uses wrong algorithm, but it uses correct symbol sizes; - NGNU uses correct algorithm, but it uses wrong symbol sizes; - NBSD uses NGNU-compatible algorithm with correct symbol sizes. So, for big majority of users who are using only single-byte locales, the NBSD sort key calculation is compatible with NGNU. For the multi-byte locales (like zh_HK.Big5HKSCS), we believe that only NBSD provides the correct results with -k option. 3) NGNU does not allow options -d and/or -i together with numeric sorting. OGNU and NBSD allows that. 4) NBSD adds NGNU-compatible options, which are absent in OGNU: -C (silent version of -c) -h (human numeric sort) -R (random sort) -V (version sort) --batch-size --compress-program --random-source --debug --files0-from 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=... (multi-threaded build only) 6) NBSD does not support option --parallel of NGNU. It has roughly the same meaning as --nthreads in NBSD. This difference will be fixed soon. Thanks Oleg -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Oleg Moskalenko Sent: Wednesday, June 27, 2012 6:45 PM To: FreeBSD Current Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT Hi As promised, I am supplying an example of comparison between several sort programs. The test file is a randomly generated 1,000,000 lines, each line contain a single floating point number. We are going to sort it three ways - as text, as -n numeric sort, and as -g numeric sort, with 4 programs: 1) Old BSD/GNU sort 5.3.0 2) New GNU sort 8.15 3) New BSD sort, single threaded 4) New BSD sort, multi-threaded The system is a 3-CPUs system, 1.5Gb of RAM, FreeBSD version 8.2. All times are in seconds. Locale C. == TEXT SORT sys user real Old BSD/GNU sort:0.0 1.692 2.008 New GNU sort:0.0 2.279 1.605 New BSD sort, st:0.0 1.964 2.300 New BSD sort, mt:0.0 2.385 1.897 == NUMERIC SORT -n sys user real Old BSD/GNU sort:0.0 4.357 4.674 New GNU sort:0.0 8.839 5.134 New BSD sort, st:0.0 5.308 5.592 New BSD sort, mt:0.0 4.581 2.489 == NUMERIC SORT -g sys user real Old BSD/GNU sort:0.0 45.37845.630 New GNU sort: ~450~121 ~300 New BSD sort, st:0.334.334 5.992 New BSD sort, mt:11.140 4.624 8.983 === Thanks Oleg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=... (multi-threaded build only) Oleg, First, thank you very much for providing both the performance numbers, and the breakdown in the differences in command line options. Everything looks great, my only concern is the above. Are there similar/identical options in NGNU that correspond to the options above? If so, I would be hesitant to add new names for them because it hurts portability between platforms. If these are totally new features then my assumption is that you have clearly marked them as non-portable in the man page? Once again, I really appreciate you addressing my concerns, and your hard work on this project. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
Doug, --nthreads option corresponds to --parallel option of NGNU and it will be renamed. The other four proprietary options will be marked as non-portable in the man page. After nthreads==parallel renaming, NBSD will support all NGNU options. Thank you for the suggestion. Oleg -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Friday, June 29, 2012 2:02 PM To: Oleg Moskalenko Cc: FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/29/2012 01:50 PM, Oleg Moskalenko wrote: 5) NBSD adds several of its own new proprietary options: --mergesort --qsort --heapsort --radixsort --nthreads=... (multi-threaded build only) Oleg, First, thank you very much for providing both the performance numbers, and the breakdown in the differences in command line options. Everything looks great, my only concern is the above. Are there similar/identical options in NGNU that correspond to the options above? If so, I would be hesitant to add new names for them because it hurts portability between platforms. If these are totally new features then my assumption is that you have clearly marked them as non-portable in the man page? Once again, I really appreciate you addressing my concerns, and your hard work on this project. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/27/12 08:04, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor ... so, can I delete the entry WITH_BSD_SORT=yes in /etc/src.conf then? Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Has this been thoroughly regression-tested against the old version, option by option? Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
-Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Tuesday, June 26, 2012 11:18 PM To: Gabor Kovesdan Cc: FreeBSD Current; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Of course it was performance-tested. As this is a totally different program with different algorithms, it has totally different performance profile on different tests, comparing to the old sort. In the default compilation mode (single thread sort) the performance is on the same level as the old sort (sometimes faster, sometimes slower). The new sort is often significantly faster in numeric sort tests. In experimental multi-threading mode, the new sort is much faster than the old sort on multi-CPU systems. The sort speed comparison is not actually fair because the old sort cuts some corners and has a number of bugs. The concrete figures do not have much sense because you change the sort file and you get a totally different performance ratio. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Has this been thoroughly regression-tested against the old version, option by option? Of course we have the regression tests. We have an overnight test that runs through probably 17 millions various sort option combinations. But we actually had to compare the new sort against a fresh GNU sort implementation (version 8.15), because the old BSD GNU sort is very buggy and testing against the old GNU sort has no sense. Oleg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/26/2012 11:48 PM, Oleg Moskalenko wrote: -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Tuesday, June 26, 2012 11:18 PM To: Gabor Kovesdan Cc: FreeBSD Current; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Of course it was performance-tested. Great, can you post the results somewhere? I understand what you're saying below that there are situations where worse performance may need explanation, but it would be helpful if we had the data to look at. As this is a totally different program with different algorithms, it has totally different performance profile on different tests, comparing to the old sort. In the default compilation mode (single thread sort) the performance is on the same level as the old sort (sometimes faster, sometimes slower). The new sort is often significantly faster in numeric sort tests. In experimental multi-threading mode, the new sort is much faster than the old sort on multi-CPU systems. This sounds encouraging. Is there a knob to enable the threaded build? The sort speed comparison is not actually fair because the old sort cuts some corners and has a number of bugs. Understood, but the existing sort is what we're changing away from, so that's what we have to test against. What we don't want is a situation where we are switching to the new sort by default without understanding what the tradeoffs are. (IOW, we don't want a repeat of the situation with grep.) The concrete figures do not have much sense because you change the sort file and you get a totally different performance ratio. I'm assuming that you'd run the performance tests on various different input files, and report the different results. Has this been thoroughly regression-tested against the old version, option by option? Of course we have the regression tests. We have an overnight test that runs through probably 17 millions various sort option combinations. This sounds great, but ... But we actually had to compare the new sort against a fresh GNU sort implementation (version 8.15), because the old BSD GNU sort is very buggy and testing against the old GNU sort has no sense. ... this not so much. The existing sort is what people have now, and what they rely on, particularly for scripts. Comparing apples to oranges doesn't help us understand how things are going to be different with the new version. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
Doug, I'll post some performance figures, probably tomorrow. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. If some old scripts are relying on buggy behavior (and I hope they are not) then the old scripts must be fixed. Period. The system cannot grow replicating the old bugs. All system scripts that I've seen are using pretty basic sort features. In the basic area, the old sort and the new sort are 100% compatible. The incompatibilities are in more complex areas (numeric sorts and unusual key-based sorts). I am actually tested the new sort against the old GNU sort. There are some incompatibilities. All of them are due to the bugs of the old GNU sort. The new BSD sort program is compatible with the new GNU sort, a much cleaner program than the old GNU sort. Try to install the new GNU coreutils. If the scripts can work with the new GNU sort (version 8.15 and later) than they will work with the new BSD sort. There is a POSIX standard, and the program must be compatible with the POSIX standard. Take care, Oleg -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Wednesday, June 27, 2012 1:35 AM To: Oleg Moskalenko Cc: Gabor Kovesdan; FreeBSD Current Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/26/2012 11:48 PM, Oleg Moskalenko wrote: -Original Message- From: Doug Barton [mailto:do...@freebsd.org] Sent: Tuesday, June 26, 2012 11:18 PM To: Gabor Kovesdan Cc: FreeBSD Current; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 06/26/2012 11:04 PM, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Has this been performance tested vs. the old one? If so, where are the results? Of course it was performance-tested. Great, can you post the results somewhere? I understand what you're saying below that there are situations where worse performance may need explanation, but it would be helpful if we had the data to look at. As this is a totally different program with different algorithms, it has totally different performance profile on different tests, comparing to the old sort. In the default compilation mode (single thread sort) the performance is on the same level as the old sort (sometimes faster, sometimes slower). The new sort is often significantly faster in numeric sort tests. In experimental multi-threading mode, the new sort is much faster than the old sort on multi-CPU systems. This sounds encouraging. Is there a knob to enable the threaded build? The sort speed comparison is not actually fair because the old sort cuts some corners and has a number of bugs. Understood, but the existing sort is what we're changing away from, so that's what we have to test against. What we don't want is a situation where we are switching to the new sort by default without understanding what the tradeoffs are. (IOW, we don't want a repeat of the situation with grep.) The concrete figures do not have much sense because you change the sort file and you get a totally different performance ratio. I'm assuming that you'd run the performance tests on various different input files, and report the different results. Has this been thoroughly regression-tested against the old version, option by option? Of course we have the regression tests. We have an overnight test that runs through probably 17 millions various sort option combinations. This sounds great, but ... But we actually had to compare the new sort against a fresh GNU sort implementation (version 8.15), because the old BSD GNU sort is very buggy and testing against the old GNU sort has no sense. ... this not so much. The existing sort is what people have now, and what they rely on, particularly for scripts. Comparing apples to oranges doesn't help us understand how things are going to be different with the new version. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. If some old scripts are relying on buggy behavior (and I hope they are not) then the old scripts must be fixed. Period. With respect, that's not your decision (or mine for that matter). We first need the data, then as a project we decide how many old bugs we want to be compatible with, if any. The system cannot grow replicating the old bugs. And the project cannot grow if we lose users due to gratuitous differences in core utilities. All system scripts that I've seen are using pretty basic sort features. The system scripts are only a tiny fraction of how FreeBSD users use sort. In the basic area, the old sort and the new sort are 100% compatible. The incompatibilities are in more complex areas (numeric sorts and unusual key-based sorts). So here's one to add to your regression test. I use the following to sort IPv4 addresses in a list: sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4 When used with GNU sort that will sort a list of IPv4 addresses into a humanly-recognizable numeric order. Please ensure that this works the same way with the new sort. I am actually tested the new sort against the old GNU sort. There are some incompatibilities. All of them are due to the bugs of the old GNU sort. Please list all of those explicitly. The new BSD sort program is compatible with the new GNU sort, a much cleaner program than the old GNU sort. That's good, but not really relevant to the users of what we have in the base now. I realize that these questions may seem discouraging, but they need to be answered. It would have been nice if Gabor had posted a we think we're ready to make the new sort the default, any last concerns? message, but deal with where we are at and move forward. thanks, Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? I believe we do not make this kind of work with any vendor code that is being updated in the base; I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. -- Kind regards Daniel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
Daniel Gerzo dan...@freebsd.org: On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? I believe we do not make this kind of work with any vendor code that is being updated in the base; I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. Seconded for -CURRENT. I think, we should at least provide some brief document, whatsoever on incompatibilities with the sort implementation that is currently active in RELENG_9, no matter how buggy it is. This allows adopters and people, who have to migrate their production systems to identify and quantify the areas to change and perform some risk management. This also allows them to move more quickly to the new release, since they can start with the necessary changes earlier and plan ahead. We provide such changes usually in the release notes for various tools, we updated and I think that giving out such a document earlier will be extremely benefitial for companies, which have to deal with more than one or two servers running FreeBSD, especially if we know that the currently shipped implementation is buggy and people most likely will have their own workarounds for that. Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/27/2012 03:02 AM, Daniel Gerzo wrote: On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? If the compatibility with the existing version were so dramatically different as Oleg claims, then yes, that would be a basic element of the replacement project. I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. The first question is, where is it not compatible with the existing sort that's already in the base. The second question is, how well does it perform vs. the existing sort. I think those are perfectly reasonable questions to ask, and frankly they should have been answered before the switch was made. We already went through this with BSD grep, I hope we can avoid a repeat. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
--- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto: ... I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. Really?? I guess you are speaking for bind, because the idea behind updating and piece of software is precisely shaking bugs. New functionality counts but fixing bugs takes the priority. We have three serious bug reports concerning GNU sort and I even submitted an update but no one cared to apply it. I would think only the maintainer of the package has the authority to make any request in the lines of being bug-for-bug compatible and in the case of GNU sort and GNU grep they are both unmaintained and replacements are welcome. Please let's stop being an obstacle towards people bringing real progress to FreeBSD! Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 06/27/2012 07:30 AM, Pedro Giffuni wrote: --- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto: ... I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. Really?? I guess you are speaking for bind, Nope. because the idea behind updating and piece of software is precisely shaking bugs. Nope. I would think only the maintainer of the package has the authority to make any request in the lines of being bug-for-bug compatible You have a seriously wrong idea of maintainer. The community owns the software, it's up to the community to decide how it should work. Historically we have looked at the maintainer as the person who volunteers to take care of code, not the person who has the exclusive lock on it. and in the case of GNU sort and GNU grep they are both unmaintained and replacements are welcome. Actually both are maintained, it's just that we don't want to import the new GNU versions. And yes, having BSD versions of these core tools is a nice goal, but it's not one we should pursue for its own sake. Please let's stop being an obstacle towards people bringing real progress to FreeBSD! In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
--- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto: ... Nope. I would think only the maintainer of the package has the authority to make any request in the lines of being bug-for-bug compatible You have a seriously wrong idea of maintainer. The community owns the software, it's up to the community to decide how it should work. You have a serious wrong idea of ownership. No one really owns the code and only few people actually take the time to take care of it. Historically we have looked at the maintainer as the person who volunteers to take care of code, not the person who has the exclusive lock on it. The maintainer, in this context, doesn't have to be a committer but it has to be someone that spends time fixing bugs or enhancing the code. You might think that because you use the code and are used to certain bug that you depend on that you somehow have a say on how it shall behave in the future but that is simply an illusion. and in the case of GNU sort and GNU grep they are both unmaintained and replacements are welcome. Actually both are maintained, it's just that we don't want to import the new GNU versions. Our forks of such packages are unmaintained. I did the work (TM) of updating GNU sort and no one cared to commit it. Oleg, took as reference the latest upstream sort implementation. And yes, having BSD versions of these core tools is a nice goal, but it's not one we should pursue for its own sake. Having something that we can maintain is a goal we should pursue for it's own sake. Please let's stop being an obstacle towards people bringing real progress to FreeBSD! In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. Performance was an issue and in general it was a good decision that even the coder involved agreed upon. Once the issue is within acceptable limits, and there has been progress on this as I understand, BSD grep will be back. Don't expect BSD grep to support something different than posix behaviour though. So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? How about rationally pointing out your issues with the new BSD sort? Any regression that you want to report? Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
-Original Message- But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. The problem is that the sort program has huge number of possible options combination. I can list some, but I cannot promise to catch all of them. It would be enormous work. If some old scripts are relying on buggy behavior (and I hope they are not) then the old scripts must be fixed. Period. With respect, that's not your decision (or mine for that matter). We first need the data, then as a project we decide how many old bugs we want to be compatible with, if any. This is an incorrect approach. You never want old bugs we want to be compatible with in a clean POSIX-compliant system. The system cannot grow replicating the old bugs. And the project cannot grow if we lose users due to gratuitous differences in core utilities. There are users that we are loosing because the utilities do not work as expected. For example, a common complain is about a situation like that: try run a trivial command like $ ls -l /usr/bin | env LANG=en_US.UTF-8 sort -n -k 5 and see what it yields for the old BSD/GNU sort. I suspect that when you are talking about the old sort compatibility you are really do not know what you are talking about. Once you start digging, you prospective may change. All system scripts that I've seen are using pretty basic sort features. The system scripts are only a tiny fraction of how FreeBSD users use sort. This is even stronger emphasizes the need in a standard-compliant implementation. In the basic area, the old sort and the new sort are 100% compatible. The incompatibilities are in more complex areas (numeric sorts and unusual key-based sorts). So here's one to add to your regression test. I use the following to sort IPv4 addresses in a list: sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4 When used with GNU sort that will sort a list of IPv4 addresses into a humanly-recognizable numeric order. Please ensure that this works the same way with the new sort. First, this is a pretty trivial use case. Don't expect anything different in the trivial cases. I think that 99% of users will never see the difference between the old sort and the new sort - for a usual non-expert usage the two are almost always compatible. Second, do you really think that I need lecturing which use cases to test ? I am actually tested the new sort against the old GNU sort. There are some incompatibilities. All of them are due to the bugs of the old GNU sort. Please list all of those explicitly. see above. The new BSD sort program is compatible with the new GNU sort, a much cleaner program than the old GNU sort. That's good, but not really relevant to the users of what we have in the base now. I bet many of them are installing the new GNU coreutils exactly for the reasons of better performance and compatibility. I realize that these questions may seem discouraging, but they need to be answered. It would have been nice if Gabor had posted a we think we're ready to make the new sort the default, any last concerns? message, but deal with where we are at and move forward. He actually did. You probably missed the messages. Thanks, Oleg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
Marcus, I'll provide some incompatibilities description, as many as I can do. Thanks Oleg -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] On Behalf Of Marcus von Appen Sent: Wednesday, June 27, 2012 3:40 AM To: freebsd-current@freebsd.org Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT Daniel Gerzo dan...@freebsd.org: On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? I believe we do not make this kind of work with any vendor code that is being updated in the base; I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. Seconded for -CURRENT. I think, we should at least provide some brief document, whatsoever on incompatibilities with the sort implementation that is currently active in RELENG_9, no matter how buggy it is. This allows adopters and people, who have to migrate their production systems to identify and quantify the areas to change and perform some risk management. This also allows them to move more quickly to the new release, since they can start with the necessary changes earlier and plan ahead. We provide such changes usually in the release notes for various tools, we updated and I think that giving out such a document earlier will be extremely benefitial for companies, which have to deal with more than one or two servers running FreeBSD, especially if we know that the currently shipped implementation is buggy and people most likely will have their own workarounds for that. Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current- unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On Wed, Jun 27, 2012 at 9:56 AM, Doug Barton do...@freebsd.org wrote: On 06/27/2012 07:30 AM, Pedro Giffuni wrote: --- Mer 27/6/12, Doug Barton do...@freebsd.org ha scritto: ... I believe we do not make this kind of work with any vendor code that is being updated in the base; Au contraire, we frequently avoid updating the old versions of things we have in the base precisely because they are not bug-for-bug compatible with existing behaviors that we count on. Really?? I guess you are speaking for bind, Nope. because the idea behind updating and piece of software is precisely shaking bugs. Nope. I would think only the maintainer of the package has the authority to make any request in the lines of being bug-for-bug compatible You have a seriously wrong idea of maintainer. The community owns the software, it's up to the community to decide how it should work. Historically we have looked at the maintainer as the person who volunteers to take care of code, not the person who has the exclusive lock on it. and in the case of GNU sort and GNU grep they are both unmaintained and replacements are welcome. Actually both are maintained, it's just that we don't want to import the new GNU versions. And yes, having BSD versions of these core tools is a nice goal, but it's not one we should pursue for its own sake. Please let's stop being an obstacle towards people bringing real progress to FreeBSD! In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? Doug, I think you need to give it a chance. I do not see any problem for anyone to switch the default and if the problems discover then switch the default back. It's a bleeding edge branch where more people can test it. The issue with grep was very harmeless and it was not difficult to switch the default between GNU and BSD. It's not like they threw GNU grep/sort away quickly. How come that I haven't heard anything from you about the jemalloc update? If you did then I must have missed it. It was very clearly that it was not test and he doesn't handle it very well, but got fixed evenly with the multi-commit. It was worst than grep/sort and other projects. If you are wondering why it's you. Because lately you are starting to whine a lot without give the things chance. If we are doing your way and nothing will moving on. Doug -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
I officially withdraw from the discussion. I hope it all works out well. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
Ah, I just tried sort on freebsd (5.3.0) versus sort on macosx 10.6 (5.93) - what a strange bug. We _could've_ fixed this with an import of the latest gnu sort and then migrated to a feature/bug compatible bsdsort, but I do see your point(s). :-) There's a fine line to walk between keeping POLA and making progress. Just be careful you don't stray too far to the Linux side of that. (And be careful of staying too close to the POLA side of it.) 2c, and great work! adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 2012-06-27 08:04, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor Thanks, I'm running textproc/bsdsort now a view weeks as BASE replacement on 8.3 and haven't seen any issues even on files with a view GB. Are you planing to update the port with your latest version? -- Regards, olli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On Jun 27, 2012, at 8:56 AM, Doug Barton wrote: So can we please stop pretending that it's me who's the problem, and start looking at these things rationally? What is your short list of issues? From a high level there appear to be none, but the devil is in the details, eh? From earlier in the thread, bsdsort and gnu sort are compatible. old, crunchy, unmaintained gnu sort that we have in the tree isn't compatible with either new gnu sort nor bsdsort. this means it isn't compatible with what the linux crowd is using, which is another consideration given the number of shell scripts that originate there these days. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
Olli, Thanks for the feedback. We are working on some minor improvements and fixes, when we are done we will commit them to the ports and to the base system. If you see any problems and inconsistencies, please let us know ASAP so we can fix that. Regards, Oleg -Original Message- From: olli hauer [mailto:oha...@gmx.de] Sent: Wednesday, June 27, 2012 10:56 AM To: FreeBSD Current Cc: Gabor Kovesdan; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 2012-06-27 08:04, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor Thanks, I'm running textproc/bsdsort now a view weeks as BASE replacement on 8.3 and haven't seen any issues even on files with a view GB. Are you planing to update the port with your latest version? -- Regards, olli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 2012-06-27 21:02, Oleg Moskalenko wrote: Olli, Thanks for the feedback. We are working on some minor improvements and fixes, when we are done we will commit them to the ports and to the base system. If you see any problems and inconsistencies, please let us know ASAP so we can fix that. Regards, Oleg Hi Oleg, until now I haven't found any issues, and I'm already in love with the new '-h' parameter which is really useful for some reporting scripts :) Regards, olli -Original Message- From: olli hauer [mailto:oha...@gmx.de] Sent: Wednesday, June 27, 2012 10:56 AM To: FreeBSD Current Cc: Gabor Kovesdan; Oleg Moskalenko Subject: Re: [HEADS-UP] BSD sort is the default sort in -CURRENT On 2012-06-27 08:04, Gabor Kovesdan wrote: Hi Folks, as I announced before, the default sort in -CURRENT has been changed to BSD sort. Since the import, the reported minor bugs have been fixed and BSD sort has passed the portbuild test. If you encounter any problems or incompatibility with the old GNU version, please report. Gabor Thanks, I'm running textproc/bsdsort now a view weeks as BASE replacement on 8.3 and haven't seen any issues even on files with a view GB. Are you planing to update the port with your latest version? -- Regards, olli ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 2012.06.27. 10:34, Doug Barton wrote: Great, can you post the results somewhere? I understand what you're saying below that there are situations where worse performance may need explanation, but it would be helpful if we had the data to look at. If something is buggy than it is not comparable in terms of performance because usually those bugs are the exact problem of the better performance because of the negligence of some checks or aspects that were not well considered. And the project cannot grow if we lose users due to gratuitous differences in core utilities. There are more Linux users than FreeBSD users and they all use GNU sort. A great percent of FreeBSD users also manages Linux systems at work so they may also be using new GNU sort features. So in short, what people more usually expect is the behavior of the latest GNU version and POSIX-conformance, not an obsolete, buggy behavior. Losing users because something works better does not seem to be a real threat. But if this is a problem then we should stop fixing bugs and adding features at all since it may discourage someone from using FreeBSD. In the case of grep, there were a fairly large number of people who agreed that a BSD grep with orders of magnitude worse performance than the previous version was not something we, as a project, were willing to stomach. Sufficiently such that the default was switched back. These are relevant critics. But remember that it lived together with GNU grep so the switch back didn't have a great impact. It was slow but at least it worked. Recently the build is so regularly broken that it makes much more harm. With BSD sort, it is the same case, if there are problems that are hard to solve, we will switch back easily. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
On 2012.06.27. 8:11, O. Hartmann wrote: ... so, can I delete the entry WITH_BSD_SORT=yes in /etc/src.conf then? Yes. BSD sort will still be the default. And if you want default GNU sort, you can add WITH_GNU_SORT=yes. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: [HEADS-UP] BSD sort is the default sort in -CURRENT
Hi As promised, I am supplying an example of comparison between several sort programs. The test file is a randomly generated 1,000,000 lines, each line contain a single floating point number. We are going to sort it three ways - as text, as -n numeric sort, and as -g numeric sort, with 4 programs: 1) Old BSD/GNU sort 5.3.0 2) New GNU sort 8.15 3) New BSD sort, single threaded 4) New BSD sort, multi-threaded The system is a 3-CPUs system, 1.5Gb of RAM, FreeBSD version 8.2. All times are in seconds. Locale C. == TEXT SORT sys user real Old BSD/GNU sort:0.0 1.692 2.008 New GNU sort:0.0 2.279 1.605 New BSD sort, st:0.0 1.964 2.300 New BSD sort, mt:0.0 2.385 1.897 == NUMERIC SORT -n sys user real Old BSD/GNU sort:0.0 4.357 4.674 New GNU sort:0.0 8.839 5.134 New BSD sort, st:0.0 5.308 5.592 New BSD sort, mt:0.0 4.581 2.489 == NUMERIC SORT -g sys user real Old BSD/GNU sort:0.0 45.37845.630 New GNU sort: ~450~121 ~300 New BSD sort, st:0.334.334 5.992 New BSD sort, mt:11.140 4.624 8.983 === Thanks Oleg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
