Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: Re: Re: Advanced Sorting - GRT - Guttman Rosler Transform

by Anonymous Monk
on Nov 17, 2003 at 02:49 UTC ( #307540=note: print w/replies, xml ) Need Help??

in reply to Re: Re: Advanced Sorting - GRT - Guttman Rosler Transform
in thread Advanced Sorting - GRT - Guttman Rosler Transform

Be careful which Perl version you are using. I ran the (corrected) benchmark under perl v5.6.1 and got this:
Rate st grt bare bare 4.55/s -- -51% -66% st 9.32/s 105% -- -31% grt 13.5/s 196% 44% --
But under perl v5.8.0 I got this:
Rate st grt bare st 9.43/s -- -15% -37% grt 11.1/s 18% -- -26% bare 15.0/s 59% 35% --
which seems to negate the use of GRT or ST sorting.

Replies are listed 'Best First'.
Re: Re: Re: Re: Advanced Sorting - GRT - Guttman Rosler Transform
by demerphq (Chancellor) on Nov 27, 2003 at 00:16 UTC

    which seems to negate the use of GRT or ST sorting.

    Seems being the key word here. :-)

    Its true that signifigant work was done to Perls sorting code between 5.6.1 and 5.8.0. Its true that many special cases have now been optmized. In fact it turns out that some of the optimisations that have occured in this period would cause the benchmark I originally posted show bad results for ST and GRT. The switch from quicksort to mergesort means that on average less comparisons are performed per sort and as the "bare" variant does the tr/// per comparison this has a adirect effect on the results. It also appears that optimisations have occured that make the ST _much_ more competitive with the GRT (GRT still wins in the benchmarks I have done however.) Also it appears optimisations have been done on tr/// in count mode, making it a most unsuitable benchmark candidate. Even worse (for the benchmark that is, everybody else gets a win :-) is that mergesort behaves particularly well on almost ordered data. As my test set is relatively ordered (due to the repetive elements) this has a particularly signifigant effect. Simply shuffling the records before the sort (after the replication) causes a dramatic change in the performance.

    What all of this means is not that the ST and GRT are "negated" but rather that the circumstances under which they are useful is reduced. This is a good thing. However, the fact still remains that given a relatively expensive comparison function the ST and GRT still win, and the GRT still beats the ST. This can be clearly seen by replacing the calls to tr/// with a subroutine that does the same thing.

    Yes, perl has gotten "better" at sorting. No, the ST and GRT are not redundant now. However given the test results I've seen so far I would probably not bother with the GRT. The ST would appear to be nearly the same performance, and a lot easier to handle.When you play around with things, using different comparsion functions, different data sets and distributions, etc you see that the GRT and ST still beat the "bare" sort. And thats the point here. If the comparsion function is expensive, precalculate it. Optimisations in perl may make a given example not behave as expected (which just reinforces the point that benchmarking should happen after the code is complete and not before) but overall, reducing the cost of the comparison still wins you some time. Thus IMO the ST and its derivatives (GRT) will be useful tools for a long time to come.



      First they ignore you, then they laugh at you, then they fight you, then you win.
      -- Gandhi

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://307540]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (1)
As of 2023-05-31 22:44 GMT
Find Nodes?
    Voting Booth?

    No recent polls found