For benchmarking the efficiency of different algorithms for a simple task and comparing them, the way I find most often is to set a constant number of times to iterate over the task, and measure the time interval spent for each algorithm.
But, if the number of times is set too small, the interval difference among the algorithms will be too small, and may be masked by external factors. If you set the number of times too large, then it will take too much time to execute. So you have to guess the right number of times by trial end error.
Rather than doing it this way, I think it makes more sense to set a constant time interval that you want to run each algorithm, and then measure how many iterations can be made in that interval for each algorithm.
By doing so, the reliability of the benchmark will be more stable. In the conventional way, the benchmark will be more reliable for tasks that take time.
I haven't seen this way of benchmarking. Do people actually do this way, and is there a benchmarking framework for this way of measurement? I am asking this as a non-language-specific question, but if there is such framework, especially for Ruby, please introduce some. Or am I wrong about this idea?
I found this gem: benchmark/ips.
Take a look at perfer:
https://github.com/jruby/perfer
This has a couple of mechanisms including iterations/s. Don't worry that this is a jruby repo, it works on all Ruby implementations and was written as part of GSoC 2012.
Related
I've been doing a lot of studying from many different resources on algorithm analysis lately, and one thing I'm currently confused about is why time complexity is often defined in terms of the number of steps/operations an algorithm performs.
For instance, in Introduction to Algorithms, 3rd Edition by Cormen, he states:
The running time of an algorithm on a particular input is the number of primitive operations or “steps” executed. It is convenient to define the notion of step so that it is as machine-independent as possible.
I've seen other resources define the time complexity as such as well. I have a problem with this because, for one, it's called TIME complexity, not "step complexity" or "operations complexity." Secondly, while it's not a definitive source, an answer to a post here on Stackoverflow states "Running time is how long it takes a program to run. Time complexity is a description of the asymptotic behavior of running time as input size tends to infinity." Further, on the Wikipedia page for time complexity it states "In computer science, the time complexity is the computational complexity that describes the amount of computer time it takes to run an algorithm." Again, these are definitive sources, things makes logical sense using these definitions.
When analyzing an algorithm and deriving its time complexity function, such as in Figure 1 below, you get an equation that is in units of time. It CAN represent the amount of operations the algorithm performs, but only if those constant factors (C_1, C_2, C_3, etc.) are each a value of 1.
Figure 1
So with all that said, I'm just wondering how it's possible for this to be defined as the number of steps when that's not really what it represents. I'm trying to clear things up and make the connection between time and number of operations. I feel like there is a lot of information that hasn't been explicitly stated in the resources I've studied. Hoping someone can help clear things up for me, and without going into discussion about Big-O because that shouldn't be needed and misses the point of the question, in my opinion.
Thank you everyone for your time and help.
why time complexity is often defined in terms of the number of steps/operations an algorithm performs?
TL;DR: because that is how the asymptotic analysis work; also, do not forget, that time is a relative thing.
Longer story:
Measuring the performance in time, as we, humans understand the time in a daily use, doesn't make much sense, as it is not always that trivial task to do.. furthermore - it even makes no sense in a broader perspective.
How would you measure what is the space and time your algorithm takes? what will be the conditional and predefined unit of the measurement you're going to apply to see the running time/space complexity of your algorithm?
You can measure it on your clock, or use some libraries/API to see exactly how many seconds/minutes/megabytes your algorithm took.. or etc.
However, this all will be VERY much variable! because, the time/space your algorithm took, will depend on:
Particular hardware you're using (architecture, CPU, RAM, etc.);
Particular programming language;
Operating System;
Compiler, you used to compile your high-level code into lower abstraction;
Other environment-specific details (sometimes, even on the temperature.. as CPUs might be scaling operating frequency dynamically)..
therefore, it is not the good thing to measure your complexity in the precise timing (again, as we understand the timing on this planet).
So, if you want to know the complexity (let's say time complexity) of your algorithm, why would it make sense to have a different time for different machines, OSes, and etc.? Algorithm Complexity Analysis is not about measuring runtime on a particular machine, but about having a clear and mathematically defined precise boundaries for the best, average and worst cases.
I hope this makes sense.
Fine, we finally get to the point, that algorithm analysis should be done as a standalone, mathematical complexity analysis.. which would not care what is the machine, OS, system architecture, or anything else (apart from algorithm itself), as we need to observe the logical abstraction, without caring about whether you're running it on Windows 10, Intel Core2Duo, or Arch Linux, Intel i7, or your mobile phone.
What's left?
Best (so far) way for the algorithm analysis, is to do the Asymptotic Analysis, which is an abstract analysis calculated on the basis of input.. and that is counting almost all the steps and operations performed in the algorithm, proportionally to your input.
This way you can speak about the Algorithm, per se, instead of being dependent on the surrounding circumstances.
Moreover; not only we shouldn't care about machine or peripheral factors, we also shouldn't care about Lower Order Terms and Constant Factors in the mathematical expression of the Asymptotic Analysis.
Constant Factors:
Constant Factors are instructions which are independent from the Input data. i.e. which are NOT dependent on the input argument data.
Few reasons why you should ignore them are:
Different programming language syntaxes, as well as their compiled files, will have different number of constant operations/factors;
Different Hardware will give different run-time for the same constant factors.
So, you should eliminate thinking about analyzing constant factors and overrule/ignore them. Only focus on only input-related important factors; therefore:
O(2n) == O(5n) and all these are O(n);
6n2 == 10n2 and all these are n2.
One more reason why we won't care about constant factors is that they we usually want to measure the complexity for sufficiently large inputs.. and when the input grows to the + infinity, it really makes no sense whether you have n or 2n.
Lower order terms:
Similar concept applies in this point:
Lower order terms, by definition, become increasingly irrelevant as you focus on large inputs.
When you have 5x4+24x2+5, you will never care much on exponent that is less than 4.
Time complexity is not about measuring how long an algorithm takes in terms of seconds. It's about comparing different algorithms, how they will perform with a certain amount if input data. And how this performance develops when the input data gets bigger.
In this context, the "number of steps" is an abstract concept for time, that can be compared independently from any hardware. Ie you can't tell how long it will take to execute 1000 steps, without exact specifications of your hardware (and how long one step will take). But you can always tell, that executing 2000 steps will take about twice as long as executing 1000 steps.
And you can't really discuss time complexity without going into Big-O, because that's what it is.
You should note that Algorithms are more abstract than programs. You check two algorithms on a paper or book and you want to analyze which works faster for an input data of size N. So you must analyze them with logic and statements. You can also run them on a computer and measure the time, but that's not proof.
Moreover, different computers execute programs at different speeds. It depends on CPU speed, RAM, and many other conditions. Even a program on a single computer may be run at different speeds depending on available resources at a time.
So, time for algorithms must be independent of how long a single atomic instruction takes to be executed on a specific computer. It's considered just one step or O(1). Also, we aren't interested in constants. For example, it doesn't matter if a program has two or 10 instructions. Both will be run on a fraction of microseconds. Usually, the number of instructions is limited and they are all run fast on computers. What is important are instructions or loops whose execution depends on a variable, which could be the size of the input to the program.
I am working on a project and would like to know if there's a way to roughly estimate the time required for the process to finish.
My very bad estimate for how many operations would it takes is somewhere between 10^70 and 10^100. I know, huge numbers and I'm almost certain that my computer won't be able to finish in a short time period. (Or ever). How could I get around to knowing how long would it take. (For any project, this is more of an example)
Something with that many operations certainly is looping thru things, possibly in a multi-levelled nested fashion.
If you can find the run time of any of the loops, multiply it by the number of times it loops to get your answer.
Say one loop has 10^10 operations, or 10 billion operations. Say this takes 10 minutes. Well, you can do the math from here.
Here you can find nicely explained material on the topic. This is a short version of the corresponding book chapter ("Algorithms 4th Edition" by Robert Sedgewick and Kevin Wayne, chapter "Analysis of Algorithms").
As a rule of thumb, modern computers should be able to do 10^8, or 100 000 000 more complex operations in a few seconds.
So if you program competitively, it shouldn't go much over that.
Also, this is just a rule of thumb and slow computers may do significantly worse while there are chips (designed for mining) that can do much much more much faster.
Still a good rule of thumb
I have heard a lot about time complexity.Time complexity itself is an Aproximation,since we are concerned about Worstcase(Big-Oh),Bestcase(Big-Omega) and Average(Theta).
Each programming language includes lots of built-in-functions.I really dont know if there is a way to check th time complexity of these functions.
Since we are using buit-in-functions,
Do we really need to Consider the Time complexity while coding?
What about the space complexity?
Is there any way to check the time complexity of these functions.
Since we are using buit-in-functions?
Do we really need to Consider the Time complexity while coding?
If your application needs to be able to scale up to larger problems, then yes. Otherwise no.
What about the space complexity?
Same answer.
Is there any way to check the time complexity of these functions. Since we are using built-in-functions?
Read the documentation. The complexity of methods for standard classes is often documented.
Use your knowledge of algorithmics. For example, you should have been taught in your algorithmic unit in your CS course that sorting is O(NlogN) for decent sort algorithms, or that finding an element in a list is O(N) on average. (If you didn't take an algorithmics uint, there are lots of good textbooks ...)
Inspect, and if necessary analyze, the source code of the builtin functions.
(Note: I do not recommend the "empirical" approach of estimating complexity. It can give you the wrong answer ... even ignoring the standard issues with measurement methodology.)
Is there any way to check the time complexity of these functions. Since we are using built-in-functions?
Yes.
The most common way is to run it in a loop (10,000 - 10,000,000 times, depending on the function, software, precision of timers etc.) with timers (timestamp before and after, stopwatch, etc.) and then compare it to your other options.
EDIT:
You need to use many different input sizes, and note the potentially confusing effect of caching on measurements.
I have a randomized recursive backtracking algorithm to generate Sudoku puzzles (see here). It works fast enough on average, but the worst-case runtime is unacceptably slow. Here is a histogram of the runtime in milliseconds for 100 trials (the "More" is about 200,000 ms!):
I would like to improve the algorithm by simply timing it out after t ms, and restarting with a new random seed. To prevent this from repeating infinitely, I would either stop after n tries or increase t after each failed try. If t is much larger than the median, there's a good chance of getting a much faster run on a subsequent try.
Questions:
How can I adjust the timeout period t for different processors? Is there a fast, reliable way to benchmark processor performance prior to each run? Alternatively, should I adapt to the processor over several runs, for instance using the mean runtime of all previous runs? I am running this on Android, if that's relevant.
Is there a better strategy entirely to avoid the long tail in the distribution of the runtimes?
Since your algorithm is recurisve, why not establish a maximum recursion depth? If the particular random seed leads to a recursion depth that you have empirically established to be high enough that you will hit the long tail, abort at that point.
By visual approximation, it looks like after 4500ms you will not get significant returns on your investment for the given seed. Rerun that benchmark also tracking recursion depth, and see what that number is. I would run more than 100 samples, though.
That solution is CPU speed independent.
Yes there is, it is called confidence interval. By running the algorithm several time in pre-processing (or on the fly), you can determine with x% confidence (where x is a parameter) what is the interval where the median of running time lays in.
You can reduce the interval size by decreasing x or increasing the number of times the algorithm runs.
Of course if you cannot really run the algorithm itself, you can try to benchmark it on some machine and find the confidence interval (let it be I), and create some function f(I,s) that given a timing of a different algorithm (the timing of it is s) on a different machine (M), predicts what should be the interval for the machine M.
finding s is done in a similar manner - using confidence interval.
Your approach seems fine, I'd probably do the same - I will first set up a small factor, and increase it after each failing attempt. Note that this is somehow similar to the congestion control in the TCP protocol (from the field of networks) to find the accepted rate of transfer of packages over the net.
i have learned that a program is measured by it's complexity - i mean by Big O Notation.
why don't we measure it by it's absolute running time?
thanks :)
You use the complexity of an algorithm instead of absolute running times to reason about algorithms, because the absolute running time of a program does not only depend on the algorithm used and the size of the input. It also depends on the machine it's running on, various implementations detail and what other programs are currently using system resources. Even if you run the same application twice with the same input on the same machine, you won't get exactly the same time.
Consequently when given a program you can't just make a statement like "this program will take 20*n seconds when run with an input of size n" because the program's running time depends on a lot more factors than the input size. You can however make a statement like "this program's running time is in O(n)", so that's a lot more useful.
Absolute running time is not an indicator of how the algorithm grows with different input sets. It's possible for a O(n*log(n)) algorithm to be far slower than an O(n^2) algorithm for all practical datasets.
Running time does not measure complexity, it only measures performance, or the time required to perform the task. An MP3 player will run for the length of the time require to play the song. The elapsed CPU time may be more useful in this case.
One measure of complexity is how it scales to larger inputs. This is useful for planning the require hardware. All things being equal, something that scales relatively linearly is preferable to one which scales poorly. Things are rarely equal.
The other measure of complexity is a measure of how simple the code is. The code complexity is usually higher for programs with relatively linear performance complexity. Complex code can be costly maintain, and changes are more likely to introduce errors.
All three (or four) measures are useful, and none of them are highly useful by themselves. The three together can be quite useful.
The question could use a little more context.
In programming a real program, we are likely to measure the program's running time. There are multiple potential issues with this though
1. What hardware is the program running on? Comparing two programs running on different hardware really doesn't give a meaningful comparison.
2. What other software is running? If anything else running, it's going to steal CPU cycles (or whatever other resource your program is running on).
3. What is the input? As already said, for a small set, a solution might look very fast, but scalability goes out the door. Also, some inputs are easier than others. If as a person, you hand me a dictionary and ask me to sort, I'll hand it right back and say done. Giving me a set of 50 cards (much smaller than a dictionary) in random order will take me a lot longer to do.
4. What is the starting conditions? If your program runs for the first time, chances are, spinning it off the hard disk will take up the largest chunk of time on modern systems. Comparing two implementations with small inputs will likely have their differences masked by this.
Big O notation covers a lot of these issues.
1. Hardware doesn't matter, as everything is normalized by the speed of 1 operation O(1).
2. Big O talks about the algorithm free of other algorithms around it.
3. Big O talks about how the input will change the running time, not how long one input takes. It tells you the worse the algorithm will perform, not how it performs on an average or easy input.
4. Again, Big O handles algorithms, not programs running in a physical system.