# How much time would be needed to compute an algorithm with time complexity $O(n^k)$?

How much time would be needed to compute a minimum k-cut, which has time complexity $O(n^k)$ on a graph with $n=5000$ and $k=30$? Consider using a basic 2GHz and 8GB RAM laptop.

• If you think about for a little, you'll realize the question isn't really answerable. – Juho Jun 30 '18 at 13:54
• But I have no idea of why... if you know why, and have the time, please answer with an explanation of why. Then what does time complexity stands for? – mickkk Jun 30 '18 at 13:55
• Maybe e.g., this question and its answer provide a good starting point. – Juho Jun 30 '18 at 14:05
• Code an algorithm to the best of your abilities, and time it. – Yuval Filmus Jun 30 '18 at 14:14

An algorithm has time complexity $O(n^k)$ if there exists a constant $C>0$ such that the number of operations that the algorithm performs in the RAM model on an input of length $n$ is at most $Cn^k$.

There are several reasons why this doesn't allow you to determine how much time the algorithm will take on a given machine for a given value of $n$:

• $Cn^k$ is only an upper bound.
• We don't know the value of $C$.
• Your machine differs from the abstract model of computation used to analyze the algorithm.

Therefore the only way to really know how much time a certain algorithm would take is to code it and empirically measure its running time.

What good is asymptotic analysis, then? The abstract machine is a reasonable model of real computers, so it is likely that the running time will scale like $n^k$ (assuming $O(n^k)$ is a tight upper bound). If $k$ is large, then likely the algorithm isn't practical. So asymptotic analysis allows you to compare different algorithms on paper rather than in practice. Of course, sometimes this comparison will result in the wrong conclusion. This is the case for fast matrix multiplication, for instance.

Let's make the unrealistic assumption that each step of your algorithm takes in your machine just one cpu cycle. That means that each step takes 0.5 ns. In the worst case the running time will be $5 \cdot 10^{-10} \cdot (5 \cdot 10^3)^{30} s \approx 4.7\cdot 10^{101}$ seconds which is about $1.5\cdot 10^{85}$ billion years or about $10^{84}$ times the life of universe. So I wouldn't suggest to actually measure it. The only hope is for average case the algorithm to be asymptotically more efficient, but I don't know much of this algorithm to help you further.

• Why unrealistic? A lot of algos today require less than one cpu cycle because 1) multiple cores, 2) multiple ALUs per core, 3) SIMD – Bulat Jun 30 '18 at 18:40
• A rough estimate, such as in this case (where I had a hunch an almost infinite time was required) is all I was asking. I am not sure whether to accept your answer or @Yuval Filmus' since he also clarified the concept. Thanks to both of you. – mickkk Jun 30 '18 at 20:48
• @Bulat I made a simplification where I supposed a non parallel machine. Even in the case we consider a machine with SIMD instructions or a lot of parallel machines, the best we can hope is to reduce the time by p, where p is the number of parallel machines. Again 5*10^(-10) or1/p, are all contributing to constant C that Yuval Filmus refer to. In this problem with these settings n = 5000 and k = 30 constant have to be extremely small to dominate exponential growth. – Curious_Dim Jun 30 '18 at 23:44
• @mickkk I think this is a case of a problem where asymptotic has meaning, i.e. for big n (and k in this case). For small n and k, then constants have more contribution and should be considered before choosing among algorithms even with big asymptotic difference. – Curious_Dim Jun 30 '18 at 23:46
• even a single core Haswell without use of SIMD executes 4 instructions per cycle. It's modern reality. I have enough code that executes in 2-4 cpu cycles per byte, f.e. Robin-Karp string match algo. Various hashes process 4-16 bytes per cycle. So one cycle per step is pretty usual today for high--optimized code. – Bulat Jul 1 '18 at 0:48

You can't really say how long it will take. Look at Curious_Dim's answer, which is not at all unrealistic. However, I have a different algorithm that has a different result and the same asymptotic behaviour:

"Given n items, first apply a O(n) algorithm which keeps at most n/10000 items, and then calculate a minimum k-cut for these items". Same asymptotic behaviour, but with a time constant that is smaller by a factor $10^{120}$. So for n = 5,000 the runtime is practically zero..