21 ms·

Deepmind Alphadev: Faster sorting algorithms discovered using deep RL

• hamilyon2 3y ago
  I want this for sql compilation, plan choosing. So much effort is wasted on suboptimal database performance and trying to improve that. I think even sorting pales in comparison.
• sebstefan 3y ago
  If they went for an integration in LLVM I wonder why they tuned their model on x86 instead of LLVM IR, the intermediate representation the compiler uses
• Upvoter33 3y ago
  The only thing that's really weird here is that this is published in Nature. It should be sent to a systems or database conference. Nature publishing minor CS results is weird.
• alexnewman 3y ago
  A cool way to describe this is, faster compiler discovered using deep RL
• anadim5 3y ago
  GPT-4 knows the answer. No RL needed https://twitter.com/DimitrisPapail/status/1666843952824168465 https://twitter.com/DimitrisPapail/status/166684395282416846...
• deleted 3y ago
  [deleted]
• sossunday 3y ago
  Wow, that's really cool - I wonder what's next for CPU optimizations
• mgaunard 3y ago
  Articles were making bold claims, but it's just optimizing libc++ and abseil's implementations. There are already known implementations faster than either of these in the right scenarios. As always, speed depends on the use case. What's optimal for a sorting algorithm depends on the size of the data, its distribution, and also how it fits into the rest of the program and how that program fits into what else the machine is doing. For example, you can make things faster by using more hardware resources, but that would penalize the rest of your program that doesn't have access to them anymore. I've frequently seen cases where a function was made faster in a microbenchmark by using all of the registers available, but then real programs ended up slower because the rest of the code had to spill to call it.
• Cold_Miserable 3y ago
  They haven't even found an optimal sort for a ymm of 8 or zmm of 16 integers? Just 5 elements? That's completely and utterly useless.
• thraidh 3y ago
  Can someone explain why the sort3 function produced by Alphadev is correct? The instruction that was removed was: `P=min(A,C)`, which means that `P=A` at that point. The next instructions: cmp S Q cmovg Q P with `S=min(A,C)` and `Q=B` can be translated into if S>Q: P=Q or if min(A,C)>B: P=B which means: if B is the smallest, then `P=B`. Otherwise P stays as before, meaning `P=A` for Alphadev and `P=min(A,C)` for the original. So, the end result for sorting A,B,C=3,2,1 would be 3,2,3 for Alphadev's code. I can't believe, I'm the first one to notice, so I'm probably wrong, but I cannot see where.
  • thraidh 3y ago
    Found my mistake. I wrongly assumed the algorithms shown in the paper were the original sorting algorithm and the one improved by Alphadev. Apparently it just shows some algorithm that was modified and resulted in a different one, neither being a sorting algorithm, but the original still being better. The text praises Alphadev by saying it makes "moves" that look like a mistake, but are actually brilliant. After that passage the code is shown that does not corroborate that statement, and just illustrates that Alphadev can make changes to code.
• SethTro 3y ago
  LLVM merge: https://reviews.llvm.org/D118029 https://reviews.llvm.org/D118029 Benchmark: https://bit.ly/3AtesYf https://bit.ly/3AtesYf Benchmark seems to be in the range of a 1-5% improvement for 80% of sizes.
  • andreamichi 3y ago
    And for the hashing patch this is the commit to Abseil: https://github.com/abseil/abseil-cpp/commit/74eee2aff683cc7dcd2dbaa69b2c654596d8024e https://github.com/abseil/abseil-cpp/commit/74eee2aff683cc7d...
• jonbaer 3y ago
  "AlphaDev uncovered new sorting algorithms that led to improvements in the LLVM libc++ sorting library that were up to 70% faster for shorter sequences and about 1.7% faster for sequences exceeding 250,000 elements."
  • dheera 3y ago
    > up to 70% faster So O(0.3(N log N))? That's still O(N log N)
    • dekhn 3y ago
      In the real world, we care about runtime as much as, if not more than, computational complexity.
      • boomanaiden154 3y ago
        Definitely more. There are lots of things that might be more optimal in terms of raw complexity but end up having abysmal performance due to things like cache locality. Anything with pointer chasing usually kills performance.
        • xdavidliu 3y ago
          for example, matrix multiplication has all sorts of algorithms with exponent significantly less than 3, but they are nearly all curiosities. In practice, the straightforward N^3 algo is used nearly everywhere
          • dekhn 3y ago
            I had a long discussion with Rob Pike once that ended with me saying "you know, I don't think people actually use Strassen on supercomputers" (we were discussing how somebody had managed to show an N*2.37 algorithm or something like that and "it was a new world's record").
            • 3y ago
• mellosouls 3y ago
  Broken link. Ok it's there now, maybe a Nature snafu. News Release: https://www.deepmind.com/blog/alphadev-discovers-faster-sorting-algorithms https://www.deepmind.com/blog/alphadev-discovers-faster-sort...
• finitestateuni 3y ago
  The most interesting part of this paper to me is that they let the agent guess how efficient it’s own solutions were and only had the model experimentally verify it’s guesses in 0.002% of cases. This allowed the model to search much faster than another program that didn’t guess and had to run every program.
  • Zamicol 3y ago
    That sounds like intuition.
    • Filligree 3y ago
      Intuition is the only thing we've figured out how to automate. Reason turns out to be higher hanging fruit.
      • the_other 3y ago
        Like humans’ “slow” and “fast” thinking, then?
        • fragmede 3y ago
          If you tell ChatGPT "show your work", you get better answers
        • Filligree 3y ago
          There's likely a connection. Either way, I like to describe AIs like ChatGPT / diffusion models, etc. as operating 100% on intuition. It gives people a better intuition of their weaknesses... For GPT you can kind of prompt it to do chain-of-thought reasoning, but it doesn't work very well; not if you compare it to what humans do. Once again it seems like what we thought was hard, is easy; what we thought was easy and computer-like turns out to be hard.
        • munchler 3y ago
          The Google Bard folks have a blog post today making exactly that connection: https://blog.google/technology/ai/bard-improved-reasoning-google-sheets-export/ https://blog.google/technology/ai/bard-improved-reasoning-go...
• greenflag 3y ago
  Does anyone have high level guidance on when (deep) RL is worth pursuing for optimization (e.g. optimizing algorithm design) rather than other approaches (e.g genetic)?
  • AndrewKemendo 3y ago
    Less of a scale problem than a type problem usually in my experience. My rule of thumb is when it’s easy to specify a reward function but infinite ways to traverse the action space - versus having a constrained state and action space (small n solution traversal pathways) and only a few possible paths to traverse.
  • jeffbee 3y ago
    Start with a planet-scale computer that makes the marginal cost of RL be nearly zero, and at the same time spend a lot of money on hashing and sorting so the micro-optimization pays off.
• lumb63 3y ago
  This is really cool. I’ll be interested to see if the team can produce useful and provably hard cryptographic hash functions with this tech. The other interesting application that this inspires is use of this tech to optimize the optimization algorithms used by compilers. Perhaps we can all benefit from optimized optimizers.
  • boomanaiden154 3y ago
    There’s already been quite a bit of work done on replacing compiler heuristics with ML models. Google has productionized it with MLGO and there have been quite a few papers/experiments on the topic.
• deleted 3y ago
  [deleted]
• lngnmn2 3y ago
  Not general or universal. Only for pre-trained data and with abysmal worst cases.
  • caturopath 3y ago
    I'm not positive what you mean here. Are you saying the discovered algorithm isn't actually good? Didn't LLVM accept it?
  • deleted 3y ago
    [deleted]
• ComputerGuru 3y ago
  RL: Reinforcement Learning
• hexomancer 3y ago
  > The confidence intervals are represented as latency ± (lower, upper), in which latency corresponds to the fifth percentile of latency measurements across 100 different machines. Lower and upper refer to the bounds of the 95% confidence interval for this percentile. Does anybody know why they chose fifth percentile? I though we should always choose the fastest time when measuring performance.
  • gcr 3y ago
    Because they want to make sure that the sorting algorithm works well for all possible workloads, not just the most preferable ones. If we measured sorting algorithms by the fastest measurement, we might conclude that BubbleSort is the fastest possible sort algorithm on some inputs. (Bubblesorting an already-sorted list makes at most one comparison per list element)
    • hexomancer 3y ago
      I don't think that's what they meant (or I have misunderstood). Running the same algorithm on the same input still has variations because of OS/CPU idiosyncrasies. When measuring performance we usually run the algorithm on the same input multiple times and report the fastest performance.
  • ajuc 3y ago
    Usually you discard extreme values to reduce noise, and in fact they wrote that's why they did it: > We then take the fifth percentile as our final measurement, because we assume that most noise sources are one-sided (for example, cache misses, pre-emptions and so on). During training we process the measurements across ten machines for computational efficiency. > I though we should always choose the fastest time when measuring performance. Depends. For games you usually do sth similar to what they did - exclude small percentage of worst results to reduce influence of noise and then optimize the worst scenario to make the game run consistent and smooth.
    • janwas 3y ago
      One possibility which seems not so well-known is that clocks with per-core state might not be perfectly synchronized. If your initial measurement is from core0, then we migrate to core1, the end measurement could even be 'before' the initial. Then there are manufacturing differences between cores that affect e.g. their leakage current and thus the (turbo) frequency at which they can run. So the measurement noise is indeed not one-sided, that is to say: measurements are not always overestimates. Thus a trimmed mean on both sides is a good idea, and pinning threads to a core when measuring is also helpful.
• air7 3y ago
  Can anyone explain how this worked? as per the paper (which I TLDRed): "A single incorrect instruction in the AssemblyGame can potentially invalidate the entire algorithm, making exploration in this space of games incredibly challenging." What did it do if it didn't have a useful partial score function? How did it avoid brute force?
  • blackbear_ 3y ago
    This paragraph: > To better estimate latency, we implemented a dual value function setup, whereby AlphaDev has two value function heads: one predicting algorithm correctness and the second predicting algorithm latency. The latency head is used to directly predict the latency of a given program by using the program’s actual computed latency as a Monte Carlo target for AlphaDev during training. This dual-head approach achieved substantially better results than the vanilla, single head value function setup when optimizing for real latency. Briefly, they use a neural network to predict whether a given sequence of instructions is correct, and how fast it is. Then they used this neural network to guide the program generation via Monte Carlo tree search [1]. It is this procedure that keeps track of the partial score functions at each node. [1] https://en.wikipedia.org/wiki/Monte_Carlo_tree_search https://en.wikipedia.org/wiki/Monte_Carlo_tree_search
• computing 3y ago
  *Google DeepMind
• whywhywhydude 3y ago
  It is astounding how something as well as studied as sorting still has opportunities for further improvements!
  • zzbn00 3y ago
    It is not the sorting per-se which was improved here, but sorting (particularly short sequences) on modern CPUs with really the complexity being on the difficulty of predicting what will work quickly on these modern CPUs. Doing an empirical algorithm search to find which algorithms fit well on modern CPUs/memory systems is pretty common, see e.g. FFTW, ATLAS, https://halide-lang.org/ https://halide-lang.org/
  • jackmott42 3y ago
    Part of it is because hardware properties are always changing. The instructions available, the relative speed of CPU to memory and the various caches, how big and numerous and fast the various caches are, etc etc.
    • GravityLabs 3y ago
      I am curious why things can't just get better on a base that doesn't change, until the base changes because the improvements with the new base are just that much better... Or is that why hardware properties change so much?
      • zerodensity 3y ago
        For a time that is what happened. Every year you would get a new CPU and that would be faster at pretty much everything than the version the year before. But then we hit the clockspeed wall and the only way of making faster CPUs was to add complexity to the internals of the CPUs. So branch prediction, micro code pipelining, larger caches, simd instructions more CPU cores ect was the result. So nowadays a new CPU might not be better at everything then the previous version but it will most likely have more cache and some internal improvements to pipelining/concurrency. Given this, for newer versions it can be useful to add instructions to take advantage of extra pipelining or using a different instruction that happen to be faster now.
• mmaunder 3y ago
  In 2023 we saw the first glimpse of machines becoming better at programming than humans when an AI created a new sorting algorithm that was faster than anything humans had yet created.
• bgirard 3y ago
  The title implies it found an entirely new algorithmic approach to sorting (like quick sort) which would have been a fantastic discovery. But it feels a lot like micro-optimizing the control flow and codegen.
  • GravityLabs 3y ago
    Still a fantastic discovery, because now there are more powerful automated algorithm improvement discovery pipelines. I wonder what will happen when those improvements are added to the processing that found the improvements. :D
    • bgirard 3y ago
      Yes, I'm not discounting the results. I think it's a very interesting approach. I just think the language is important here. If you ask a CS class turn in their own quick sort implementation, you have n implementations of 1 algorithm, not n new algorithms.
  • fwlr 3y ago
    I'm not sure there is a new algorithmic approach to sorting like you're thinking of. From a high level you can divide sorting algorithms into roughly two camps, "those that use divide-and-conquer", and "those that do not". The divide-and-conquer (split into smaller sub-lists, sort the sub-lists, and merge them while preserving sort order) algorithms are better. From this perspective, algorithms that we think of as quite distinct like quicksort and mergesort are not that different - quicksort just does the "divide" step of divide-and-conquer in a smarter way. In the end, no matter what divide-and-conquer sorting algorithm you pick, you will be doing lots of "small sorts". And it is those small sorts that DeepMind has optimized here.
    • pxeger1 3y ago
      Indeed, it's easy to prove that any sorting algorithm that works by comparing elements (unlike e.g. radix sort) requires Ω(n log n) time in the worst case.
    • 3y ago
• deleted 3y ago
  [deleted]
• fwlr 3y ago
  Some very cool improvements found in already highly optimized algorithms. They found that in a sorting network handling 3 inputs, the AI found a way to save an instruction by reducing a "min(A, B, C)" operation to just "min(A, B)" by taking advantage of the fact that previous operations guaranteed that B <= C. They also found that in a sorting network handling 4 inputs, when it is part of a "sort 8" network, there are similar guarantees (D >= min(A, C) in this case) that can be taken advantage of to remove an instruction as well. The compiler may not be able to compete with hand-written assembly, but it seems an AI can hand-write assembly code that's even better in some cases. Another improvement is also very cool. They discuss VarSort4, which takes a list that may be 2, 3, or 4 elements long, and sorts it. The existing algorithm is if (len = 4) { sort4 } elif (len = 3) { sort3 } elif (len = 2) { sort2 } The AI found an algorithm that looks totally different: if (len = 2) { sort2 } else { sort3 if (len = 4) { sortspecial } } It's pretty wild! It immediately runs Sort3 on something that may be either 3 elements or 4 elements long, and only afterwards does it check to see how long it really is. If it's 3 elements long, we're done; otherwise, run Sort4 - but because (having already run Sort3) you know the first three elements are sorted, you can use a special and much simpler algorithm to simply put the 4th element in the right spot. Very cool. Improving on core LLVM sorting algorithms that have already been heavily hand-optimized by the best in the world is definitely a "it's 1997 and Deep Blue defeats the World Champion in chess" kind of feeling.
  • thomasahle 3y ago
    I'm surprised they only report results up to sort5. It seems at that level, you could just iterate through all possible programs. AI generated code seems more interested once you get to 10+ values, where classical methods break down.
    • cypherpunks01 3y ago
      I believe that's because above 5 elements, fixed sorting networks are no longer used. Introsort takes over and dispatches to insertion sort, quicksort, or heap sort as appropriate. Divide and conquer strategies are used for larger sorts, and the smaller arrays could include the fixed lengths 3, 4, 5.
• danlark 3y ago
  You can see hashing optimizations as well https://www.deepmind.com/blog/alphadev-discovers-faster-sorting-algorithms https://www.deepmind.com/blog/alphadev-discovers-faster-sort..., https://github.com/abseil/abseil-cpp/commit/74eee2aff683cc7dcd2dbaa69b2c654596d8024e https://github.com/abseil/abseil-cpp/commit/74eee2aff683cc7d... I was one of the members who reviewed expertly what has been done both in sorting and hashing. Overall it's more about assembly, finding missed compiler optimizations and balancing between correctness and distribution (in hashing in particular). It was not revolutionary in a sense it hasn't found completely new approaches but converged to something incomprehensible for humans but relatively good for performance which proves the point that optimal programs are very inhuman. Note that for instructions in sorting, removing them does not always lead to better performance, for example, instructions can run in parallel and the effect can be less profound. Benchmarks can lie and compiler could do something differently when recompiling the sort3 function which was changed. For hashing it was even funnier, very small strings up to 64 bit already used 3 instructions like add some constant -> multiply 64x64 -> xor upper/lower. For bigger ones the question becomes more complicated, that's why 9-16 was a better spot and it simplified from 2 multiplications to just one and a rotation. Distribution on real workloads was good, it almost passed smhasher and we decided it was good enough to try out in prod. We did not rollback as you can see from abseil :) But even given all that, it was fascinating to watch how this system was searching and was able to find particular programs can be further simplified. Kudos to everyone involved, it's a great incremental change that can bring more results in the future.
  • lukeplato 3y ago
    > optimal programs are very inhuman sounds revolutionary
  • brundolf 3y ago
    Thought: optimizing JIT compilers like V8 already observe code behavior and use that to choose how to optimize things as they go. I wonder if one day V8 will incorporate some ML to help study and optimize the running code
  • ks84 3y ago
    I haven’t read the paper, but it sounds like this is a sort of similar approach to genetic algorithms? Create lots of agents with random changes and pick the ones that produce the most promising results? Is my impression wrong?
• GreedClarifies 3y ago
  Deepmind shouldn’t be part of a for profit entity. There I said it. They are clearly focused on moving technology forward and helping humanity. That’s great. However, pulling down 1M+ salaries (for L6+ developers) and using hundreds of millions or billions in borg resources while adding nothing to the bottom line is not in the interest of Google. Not to mention the negative effects on productivity as other Googlers attempt to replicate the “publish everything to support my brand” strategy of Deepmind. I know Google is not a normal company in that Larry and Sergey have complete control of the company, but sooner or later they have to realize that Deepmind needs to be spun off, and further that Demis is entirely the wrong person to run Google’s AI. He doesn’t care a whit about Google, it is only a vessel to fund his research. Products. A company is about products and customers not research papers. Academia or non-profits are about papers.
  • benlivengood 3y ago
    I think Google's biggest net positives in the world at this point are Waymo and DeepMind. Way better than spending money on new chat apps. Google's history has been having a very lucrative bottom line that allows for very beneficial research with absolutely no hardships on anyone. Supremely better than lining shareholder pockets; shareholders can't think enough quarters ahead for long-term human benefit. Salaries are just the way to attract and retain quality folks.
    • GreedClarifies 3y ago
      The billions who use their search everyday would likely disagree. The billions who use YouTube per day would likely disagree. The billions who use android would likely disagree. The hundreds of millions who use gmail, or gsuite would disagree. Products.
      • casey2 3y ago
        Products are at best optimization of a yesterday's technology, in tech you realistically can't peek into the future without spending billions on r&d. Having smart people work on any of the things you listed is a (further) waste of their time.
• usgroup 3y ago
  “ The fixed sort solutions for sort 3, sort 4 and sort 5 discovered by AlphaDev have been integrated into the standard sort function in the LLVM standard C++ library3.” Not exactly what the title would lead you to believe.
• EGreg 3y ago
  Almost all ML is basically searching through a (latent) space of possible answers and indexing the results. So it outperform most known methods. Like when AlphaGo using MCTS beat Rybka, etc. I would be interested to know if ML can be used to reverse hashes, such as to more quickly solve the numbers that satisfy the Bitcoin Hash challenge. Maybe it can even get P and NP closer together! Are there theoretical results on SHA-256 or something that preclude finding an ML algorithm that, with a billion parameters, can speed up the search for a Bitcoin Hash input?
• cypherpunks01 3y ago
  This was educational because I learned about Sorting Networks. I didn't hear of them in CS undergrad algorithms, perhaps because they can be thought of as a special case or optimization, rather than fundamental and generic variable-length sort algos. It's a simple concept, and forms the basis of all the sort optimizations described here. https://en.wikipedia.org/wiki/Sorting_network https://en.wikipedia.org/wiki/Sorting_network
• jeffbee 3y ago
  The sorting seems cool but I am more interested in the varint decoder. Does anyone know where the source code of that landed, if it did?
• VikingCoder 3y ago
  Dumb question - Where are the machine learning de-compilers? Given an executable program, give me human-readable code that generates the executable exactly. With machine learning guessed function, type, variable names...? I get that it's a very hard problem. But... Does it just not work? Or have people not done it yet? Or have I missed it?
  • optimalsolver 3y ago
    https://arxiv.org/abs/2010.00770 https://arxiv.org/abs/2010.00770
  • sundarurfriend 3y ago
    I don't understand WebAssembly much other than superficially, but if wasm is going to be a new, harder level obfuscation for websites, making them harder to customize locally, then I hope ML/AI can counteract that and preserve the Web as a user-customizable space.
  • VMG 3y ago
    You can already do that to some extent with ChatGPT. Paste in the assembly and it gives pretty good results
  • sl-1 3y ago
    That is a good question! Training datasets should be pretty trivial for this, all open source software that is buildable on the internet could provide training sets (source code & compiled code). But I guess it would have to be trained specifically for every architechture.
  • xwdv 3y ago
    This is the killer app for me with AI. A way to get a non-copyrighted code for any program you already have binary code for.
    • ealexhudson 3y ago
      That sounds obviously transformative and on any non-trivial scale I can't see why copyright would be avoided.
• gfd 3y ago
  Can someone summarize how it achieves "provable correctness"?
• dontupvoteme 3y ago
  From "It can't Code" to publishing articles in Nature.
• orlp 3y ago
  > AlphaDev uncovered new sorting algorithms that led to improvements in the LLVM libc++ sorting library that were up to 70% faster for shorter sequences and about 1.7% faster for sequences exceeding 250,000 elements. As someone that knows a thing or two about sorting... bullshit. No new algorithms were uncovered, and the work here did not lead to the claimed improvements. They found a sequence of assembly that saves... one MOV. That's it. And it's not even novel, it's simply an unrolled insertion sort on three elements. That their patch for libc++ is 70% faster for small inputs is only due to the library not having an efficient implementation with a *branchless* sorting network beforehand. Those are not novel either, they already exist, made by humans. > By open sourcing our new sorting algorithms in the main C++ library, millions of developers and companies around the world now use it on AI applications across industries from cloud computing and online shopping to supply chain management. This is the first change to this part of the sorting library in over a decade and the first time an algorithm designed through reinforcement learning has been added to this library. We see this as an important stepping stone for using AI to optimise the world’s code, one algorithm at a time. I'm happy for the researchers that the reinforcement learning approach worked, and that it gave good code. But the paper and surrounding press release is self-aggrandizing in both its results and impact. That this is the first change to 'this part' of the sorting routine in a decade is also just completely cherry-picked. For example, I would say that my 2014 report and (ignored patch of) the fact that the libc++ sorting routine was QUADRATIC (https://bugs.llvm.org/show_bug.cgi?id=20837 https://bugs.llvm.org/show_bug.cgi?id=20837) finally being fixed late 2021 https://reviews.llvm.org/D113413 https://reviews.llvm.org/D113413 is quite the notable change. If anything it shows that there wasn't a particularly active development schedule on the libc++ sorting routine the past decade.
  • usmansk 3y ago
    The claim "faster sorting algorithm" is wrong. They have to show the time-complexity. They have to prove that their algorithm is faster than linear sorting algorithms. Otherwise, they have to accept that their claim is wrong.
  • usmansk 3y ago
    Can anyone refute the claim of orlp that it is unrolled insertion sort
• reocha 3y ago
  Pretty impressive, I'm looking forward to optimizations in other commonly used algorithms.
• graycat 3y ago
  "Faster sorting"? Heap sort achieves the Gleason bound and, thus, is the fastest possible sort by comparing pairs of keys. For keys not too long, radix sort can be faster. These facts have been very well known for decades. There might be more to do in sorting with some different records, keys, computer architecture, concerns about caches and locality of reference, but otherwise, thankfully, sorting is a well solved problem.
  • CyberDildonics 3y ago
    Heap sort gets beat by sorting algorithms with better locality. You can't be the fastest while skipping through memory for every operation.
    • janwas 3y ago
      Agreed. And I am not aware of a heapsort that can take advantage of SIMD, so our not very well-tuned heapsort is about 20 times slower in practice than our VQSort (vectorized quicksort).
  • CaptainNegative 3y ago
    Heap sort's worst- and average-case running time are both provably within a constant factor of optimality (both in running time and number of comparisons), but it's either likely or straight up provably not actually optimal in any of the four categories.
• shpx 3y ago
  I (don't) want to see an agent learn to rowhammer the memory address storing its reward quantity.
  • orlp 3y ago
    You'll love this list of examples where the AI successfully accomplished reward hacking: https://docs.google.com/spreadsheets/d/e/2PACX-1vRPiprOaC3HsCf5Tuum8bRfzYUiKLRqJmbOoC-32JorNdfyTiRRsR7Ea5eWtvsWzuxo8bjOxCG84dAg/pubhtml https://docs.google.com/spreadsheets/d/e/2PACX-1vRPiprOaC3Hs...
• MagicMoonlight 3y ago
  Now do it for compression
• skellington 3y ago
  So clickbait to claim a faster algorithm when all it did was find a faster machine optimization for a particular CPU. It's fun/cool, but not the leap they seem to be representing.
• Havoc 3y ago
  I like the high impact dynamic of this thinking. If that can be done say OS wide I could see that having an actual impact on global energy usage
• ayakang31415 3y ago
  Shouldn't the paper named faster sorting algorithm "optimized" using deep RL instead since no new sorting algorithm is introduced at all?
• deleted 3y ago
  [deleted]
• keiuseki 3y ago
  Try make BERT better. So far it is much worse than ChatGPT.
• keiuseki 3y ago
  How about focus on making BERT better. So far BERT is much worse than ChatGPT.
  • HereBePandas 3y ago
    ? BERT was 5 years ago. Of course it's worse than anything introduced more recently (both inside and outside Google). https://en.m.wikipedia.org/wiki/BERT_(language_model) https://en.m.wikipedia.org/wiki/BERT_(language_model)