Trying to take this literally: Can anyone know how to make algorithm2 faster than the easiest method? and // You need focus on algo2 function., with algorithm2 finding the runner-up among the champion's opponents in a tournament.
The straightforward way to find the k-max values of an unordered collection is to feed a priority queue of size k with its elements.
The cases with k <= 2 are special in not warranting an explicit priority queue: after initialising k candidates from the first k elements, just compare each of the remaining elements to the current k-max candidate. If the current element is greater: if looking for the top two elements, compare to the max candidate: if greater, keep that value as the new runner-up and make the current element the max candidate, else just replace the runner-up.
This requires kN+O(1) assignments, worst case, and kN-O(1) comparisons.
The tournament approach to 2-max requires N+ld(N)-O(1) comparisons and N+O(ld(N)) assignments.
According to this, algorithm2 may use slightly more than half the comparisons and assignments algorithm1 does. Then again, for "random input", I'd expect the number of assignments in the simplistic approach to grow in the ballpark of c*lg(N) to c*sqrt(N) - strictly lower than N/2 for "non-trivial" values of N.
For any contemporary sequential machine implementation, I'd expect simplistic to win hands down against tournament. Design, test, analysis and measurement of parallel renditions left as an exercise…

Trying to take this literally: Can anyone know how to make algorithm2 faster than the easiest method? and // You need focus on algo2 function., with algorithm2 finding the runner-up among the champion's opponents in a tournament.

The straightforward way to find the k-max values of an unordered collection is to feed a priority queue of size k with its elements.

The cases with k <= 2 are special in not warranting an explicit priority queue: after initializing k candidates from the first k elements, just compare each of the remaining elements to the current k-max candidate. If the current element is greater: if looking for the top two elements, compare to the max candidate: if greater, keep that value as the new runner-up and make the current element the max candidate, else just replace the runner-up.

This requires \$kN+O(1)\$ assignments, worst case, and \$kN-O(1)\$ comparisons.

The tournament approach to 2-max requires \$N+ld(N)-O(1)\$ comparisons and \$N+O(ld(N))\$ assignments.

According to this, algorithm2 may use slightly more than half the comparisons and assignments algorithm1 does. Then again, for "random input", I'd expect the number of assignments in the simplistic approach to grow in the ballpark of \$c*lg(N)\$ to \$c*sqrt(N)\$ - strictly lower than \$N/2\$ for "non-trivial" values of \$N\$.

For any contemporary sequential machine implementation, I'd expect simplistic to win hands down against tournament. Design, test, analysis and measurement of parallel renditions left as an exercise…

Trying to take this literally: Can anyone know how to make algorithm2 faster than the easiest method? and // You need focus on algo2 function., with algorithm2 finding the runner-up among the champion's opponents in a tournament.
The straightforward way to find the k-max values of an unordered collection is to feed a priority queue of size k with its elements.
The cases with k <= 2 are special in not warranting an explicit priority queue: after initialising k candidates from the first k elements, just compare each of the remaining elements to the current max candidate. If the current element is greater: if looking for the top two elements, keep the max candidate value as the new runner-up, make the current element the max candidate.
This requires kN+O(1) assignments, worst case, and N-1 comparisons.
The tournament approach to 2-max requires N+ld(N)-O(1) comparisons and N+O(ld(N)) assignments.
According to this, the number of comparisons is slightly higher for algorithm2, while the number of assignments may be not much more than half that required with the "implicit priority queue". Then again, for "random input", I'd expect the number of assignments in the simplistic approach to grow in the ballpark of c*lg(N) to c*sqrt(N) - strictly lower than N/2 for "non-trivial" values of N.
For any contemporary sequential machine implementation, I'd expect simplistic to win hands down against tournament. Design, test, analysis and measurement of parallel renditions left as an exercise…

Trying to take this literally: Can anyone know how to make algorithm2 faster than the easiest method? and // You need focus on algo2 function., with algorithm2 finding the runner-up among the champion's opponents in a tournament.
The straightforward way to find the k-max values of an unordered collection is to feed a priority queue of size k with its elements.
The cases with k <= 2 are special in not warranting an explicit priority queue: after initialising k candidates from the first k elements, just compare each of the remaining elements to the current k-max candidate. If the current element is greater: if looking for the top two elements, compare to the max candidate: if greater, keep that value as the new runner-up and make the current element the max candidate, else just replace the runner-up.
This requires kN+O(1) assignments, worst case, and kN-O(1) comparisons.
The tournament approach to 2-max requires N+ld(N)-O(1) comparisons and N+O(ld(N)) assignments.
According to this, algorithm2 may use slightly more than half the comparisons and assignments algorithm1 does. Then again, for "random input", I'd expect the number of assignments in the simplistic approach to grow in the ballpark of c*lg(N) to c*sqrt(N) - strictly lower than N/2 for "non-trivial" values of N.
For any contemporary sequential machine implementation, I'd expect simplistic to win hands down against tournament. Design, test, analysis and measurement of parallel renditions left as an exercise…