DeepMind AI Develops Efficient Sorting Algorithms

Click For Summary

Discussion Overview

The discussion revolves around the development of efficient sorting algorithms by DeepMind, exploring historical perspectives on sorting practices, the relevance of optimization in modern programming, and the conditions under which specific sorting algorithms may be beneficial. Participants share insights on the practical implications of sorting algorithms in real-world applications, particularly in resource-constrained environments.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • Some participants reflect on historical practices of writing custom sorting algorithms due to limited computing resources, contrasting it with modern reliance on library sorts.
  • There is a discussion on the potential advantages of AI-generated sorting algorithms, particularly for small datasets, where execution time can be minimized.
  • One participant argues that in practical scenarios, the time spent optimizing sorting algorithms may not justify the performance gains, especially when faster hardware is available.
  • Another participant questions the frequency of knowing the number of elements to be sorted at compile time, suggesting that while some cases are stable, variability often exists.
  • Some participants provide examples where the number of elements is known, such as calculating the median of a fixed number of samples, but emphasize the need for broader optimization strategies.
  • There are contrasting views on the necessity of optimization, with one participant sharing a specific case where an optimized algorithm significantly improved performance in a time-sensitive application.

Areas of Agreement / Disagreement

Participants express differing opinions on the relevance and practicality of optimizing sorting algorithms. While some see value in AI-generated solutions for specific cases, others argue that the effort may not be worthwhile in many real-world applications. The discussion remains unresolved regarding the balance between optimization and practical implementation.

Contextual Notes

Participants highlight limitations in the discussion, such as the dependence on specific use cases, the variability of element counts, and the context in which sorting algorithms are applied. There is also acknowledgment of the trade-offs between optimization efforts and the potential benefits in execution time.

Technology news on Phys.org
Tom.G said:
Some historical perspective:

In "modern" times, programmers sort using published libraries. But there was a time, just 30+ years ago, when people wrote their own sorts (for example). They were using machines with very limited memory resources and processor power. So, in resource-critical cases, development time was spent identifying ideal solutions - and it was common to go down to the assembly/register level looking for the optimum method to apply for a that particular project.

What "deepmind" has done is to find the most optimal sort solutions for cases where there are a small number of elements to be sorted (2 through 8) and when "optimal" is defined as minimal execution time with ample code memory resources. It's an exercise I performed for element counts of 2 through 6 when I was working out the details of that Zig Zag sort (same example).

But I haven't used my own sort in decades. It rarely makes any sense anymore.

However, there is definitely an advantage to be had with this deepmind result. With modern compiler and linker optimization techniques, a library sort can be created using this result that can select sort code that is as specifically optimized as the code that was hand-selected decades ago. So if you are sorting exactly 7 elements, it will replace your "sort(7,data,comp(&a,&b));" with a more customized "sort_7(data,comp(&a,&b));".
Coding at the Assembly level was once a common optimization practice. A key goal of this kind of optimization is to make assembly as an optimization method completely unnecessary.
 
I can't possibly be old enough to re,member the times @.Scott is talking about - yet I do.

I "real life" - i.e. when someone is paying you to sort something. (or write a program to sort something) you typically have one of two problems: either the whole thing is unsorted, or it is mostly sortted with a few unsorted elements at the end.

These cases were generally identifiable "by hand" and if it made sense treated accordingly. Rareky did it make sense to try and go beyond this - the amount of time it would take to study tyhe situation to pick the right algorithm was usually large compared to the time difference between various algorithms.

It does no good to spend an hour trying to speed up a sort by 30 minutes. It may not even make sense to hire a team of programmers to speed up a sort by 30 minutes compared to just getting a faster computer.
 
.Scott said:
if you are sorting exactly 7 elements
How often will the number of elements being sorted be known at compile time?
 
.Scott said:
Coding at the Assembly level was once a common optimization practice.
I am writing assembly code at the moment because I demand time critical control of external signals while all interrupts are disabled, and exceptions impossible.

An optimising compiler can get close enough to perfection for most applications.
I do notice with these AI generated sorts that it takes more time to prepare to save a cycle than will ever be saved by the slightly improved process. KISS.
 
PeterDonis said:
How often will the number of elements being sorted be known at compile time?
Sometimes it is very, very stable. The number of hours in a day hasn't changed since the invention of computers. The number of states in the US has been stable for more than half a century. Even the number of schools in the Big Ten is constant on the time scale of compilimg.

But....

The most likely spot to find it is in a divide-and-conquer algorithm whrer you break N items into groups of M. N can vary but M can stay constant.
 
  • Like
Likes   Reactions: PeterDonis
PeterDonis said:
How often will the number of elements being sorted be known at compile time?
An easy example that answers your question, but not the general point:
You decide that you will get sufficiently reliable results if you take the median value of 7 samples.
So you sort seven results and take the middle value.

But, if optimization was that important, you could optimize the entire 7-sample median algorithm.
 
Vanadium 50 said:
It does no good to spend an hour trying to speed up a sort by 30 minutes. It may not even make sense to hire a team of programmers to speed up a sort by 30 minutes compared to just getting a faster computer.
And sometimes it does.
So I need the median value from a list of 256 integer values. The total amount of time spent developing, documenting, and implementing the final optimized algorithm is several man-weeks - and the final result is very fast but only accurate enough (perfect over 99% of the time).
The un-optimized version took about 300 usec. The optimized version takes a couple of usec.
But it gets executed 20 times per second in a consumer automobile radar unit and 300usec was way over its time budget.
 
  • Like
Likes   Reactions: Tom.G

Similar threads

  • · Replies 9 ·
Replies
9
Views
3K
  • · Replies 2 ·
Replies
2
Views
866
  • · Replies 6 ·
Replies
6
Views
2K
  • · Replies 10 ·
Replies
10
Views
2K
Replies
38
Views
3K
  • · Replies 1 ·
Replies
1
Views
643
  • · Replies 25 ·
Replies
25
Views
2K
  • · Replies 133 ·
5
Replies
133
Views
11K
  • · Replies 29 ·
Replies
29
Views
4K
  • · Replies 2 ·
Replies
2
Views
2K