in reply to Re^6: Longest Increasing Subset
in thread Longest Increasing Subset
wow... so I implemented the wiki page's pseudocode, and benchmarked my code vs the Longest Increasing Subsequence:
results:
20 [953 317 563 582 789 629 613 918 9 680 276 163 119 915 967 426 820 +227 256 650] lis: [ 317 563 582 613 680 915 967 ] pryrt: [ 317 563 582 629 680 915 967 ] Benchmark: running lis, pryrt for at least 10 CPU seconds ... lis: 10 wallclock secs (10.51 usr + 0.00 sys = 10.51 CPU) @ 25 +210.27/s (n=265086) pryrt: 11 wallclock secs (11.26 usr + 0.00 sys = 11.26 CPU) @ + 0.18/s (n=2) (warning: too few iterations for a reliable count) s/iter pryrt lis pryrt 5.63 -- -100% lis 3.97e-005 14197064% --
With a random list just twenty elements long, it went from 5-6s per run for my code, to better than 25_000 runs per second with the efficient algorithm: that's almost 150_000 times faster, and that's just with 20 elements in the array. (My original benchmark tried cmpthese() on random length arrays, using the defaults to my genarray() function, but after a minute, I didn't feel like waiting that long, so switched to a 10sec timethese()/cmpthese() pair. Multiple runs give similar results.)
When run-time is money, it pays to search for known-good algorithms, rather than just trusting that you've thought of an efficient algorithm!
Thanks ++gilthoniel for an interesting thread, and ++BrowserUK, for once again bringing his knowledge of efficient coding practices to help us all.
To all who come upon this thread: definitely use the efficient code, rather than my original code!
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^8: Longest Increasing Subset
by BrowserUk (Patriarch) on Oct 24, 2016 at 16:06 UTC |