> And even if it were slower in practice, research like this is very useful, because it helps gives other researchers inspiration, ever since someone thought of looking at these problems like electrical flow in 2010, there have been ever faster approximations for it, while others will find ways to implement the algorithm efficiently, just in case a naive implementation of the offered algorithm isn't efficient enough.
> Dismissing such research without having found any actual extreme inefficiencies in the proposed algorithm is not an attitude suited to anyone who wants to see progress.
I never dismissed this research or said it's not useful; on the contrary, it's very interesting. I was just arguing against the usefulness of benchmarking results for such algorithms, when the main improvement is the lower complexity.
EDIT:
> And finally, the actual speed increase in the past decades hasn't been from O(N^2) to O(N^1.9) but from O(VE^2) to O(VE), which obviously does have a real impact, and even with a non-realistic 10000 times bigger constant it would still be far faster in any graph with more 10000 edges. And graphs with billions of edges aren't unusual anymore.
One concrete example I had in mind is Strassen's algorithm, which reduces matrix multiplication from O(N^3) to O(N^2.8) or O(N^log 7). It doesn't seem to be worth it to use Strassen over the simple algorithm for relatively small matrices.
There are other examples of algorithms and data structures that offer an O(N log log N) time, where the previous algorithm needed O(N log N) to solve the same problem. You need a very large data set to justify using the former, especially if the latter are much simpler to implement.
> As you are talking about reasonably sized input, your constant examples should also be reasonable. 10000 times difference in the constant is not reasonable. You wouldn't even get that from going from all data in the level 1 cache to random memory access with 10 times more instructions.
10000 was just an example, I guess it was unrealistic. In practice, I think an 100x slowdown from an algorithm that has bad cache behavior makes some sense. [1] says that an L3 cache hit has a latency of 1-300 cycles, as opposed to a L1 hit that is only 4 cycles. That's almost an 100x difference, so theoretically a cache-friendly algorithm can be that much faster (and that's just the difference between L3 and L1, main memory takes even longer to access).
> Dismissing such research without having found any actual extreme inefficiencies in the proposed algorithm is not an attitude suited to anyone who wants to see progress.
I never dismissed this research or said it's not useful; on the contrary, it's very interesting. I was just arguing against the usefulness of benchmarking results for such algorithms, when the main improvement is the lower complexity.
EDIT:
> And finally, the actual speed increase in the past decades hasn't been from O(N^2) to O(N^1.9) but from O(VE^2) to O(VE), which obviously does have a real impact, and even with a non-realistic 10000 times bigger constant it would still be far faster in any graph with more 10000 edges. And graphs with billions of edges aren't unusual anymore.
One concrete example I had in mind is Strassen's algorithm, which reduces matrix multiplication from O(N^3) to O(N^2.8) or O(N^log 7). It doesn't seem to be worth it to use Strassen over the simple algorithm for relatively small matrices.
There are other examples of algorithms and data structures that offer an O(N log log N) time, where the previous algorithm needed O(N log N) to solve the same problem. You need a very large data set to justify using the former, especially if the latter are much simpler to implement.
> As you are talking about reasonably sized input, your constant examples should also be reasonable. 10000 times difference in the constant is not reasonable. You wouldn't even get that from going from all data in the level 1 cache to random memory access with 10 times more instructions.
10000 was just an example, I guess it was unrealistic. In practice, I think an 100x slowdown from an algorithm that has bad cache behavior makes some sense. [1] says that an L3 cache hit has a latency of 1-300 cycles, as opposed to a L1 hit that is only 4 cycles. That's almost an 100x difference, so theoretically a cache-friendly algorithm can be that much faster (and that's just the difference between L3 and L1, main memory takes even longer to access).
1 - http://stackoverflow.com/questions/4087280/approximate-cost-...