> Modern optimizing compilers are already effective black boxes Not the way DL models are. You can step through a forest of switch / if statements. You can eve

> Modern optimizing compilers are already effective black boxes Not the way DL models are. You can step through a forest of switch / if statements. You can even step through something like a lex / yacc state table, as unpleasant as that prospect is. You cannot meaningfully step through an algorithm that passes your data through a series of multiplications with large floating point matrices. > The paper in question also uses DL for two things that have nothing to do with optimization, benchmark generation and fuzzing I agree, those two applications seem unobjectionable. > "Is representation A cheaper than representation B, in this context?" is a very different problem than "Magically generate programs equivalent to A." Agreed. I was more concerned about the latter application (and some other commenters in this discussion apparently had the same expectation). > one tiny tweak to the source will magically tank your performance [...] But this is already the case today No the same way, I suspect. A DL model could, for instance, tank your performance because of the way a particular variable is named because of some spurious correlation it learned from its training set.