Computer Program Fixes Old Code Faster Than Expert Engineers
An anonymous reader writes: Less than two weeks after one group of MIT researchers unveiled a system capable of repairing software bugs automatically, a different group has demonstrated another system called Helium, which "revamps and fine-tunes code without ever needing the original source, in a matter of hours or even minutes." The process works like this: "The team started with a simple building block of programming that's nevertheless extremely difficult to analyze: binary code that has been stripped of debug symbols, which represents the only piece of code that is available for proprietary software such as Photoshop. ... With Helium, the researchers are able to lift these kernels from a stripped binary and restructure them as high-level representations that are readable in Halide, a CSAIL-designed programming language geared towards image-processing. ... From there, the Helium system then replaces the original bit-rotted components with the re-optimized ones. The net result: Helium can improve the performance of certain Photoshop filters by 75 percent, and the performance of less optimized programs such as Microsoft Windows' IrfanView by 400 to 500 percent." Their full academic paper (PDF) is available online.
Does that mean the program responds in negative time? even before you click the button it's already done what you wanted? Sounds impractical...
When you read the actual paper, it seems to analyse the code, and take advantage of vectorization in modern hardware to do the equivalent act in a more parallel way increasing performance. So it strips off local optimization, analyses the action, then recreates it in a form better suited to the processor its compiled for, resulting in a speedup.
Sort of reminds me of Transmeta, the processor Linus was involved with, that ran microcode, analysed the execution of the x86 code, and did little mini compiles of microcode to simulate that. aka 'Code Morphing',
https://en.wikipedia.org/wiki/Transmeta
It did well on Benchmarks (and filters) because of the repetitive nature of them, it could recreate those loops more efficiently.
Interesting, pity its all full of boastful fluff, and vague bitrot claims, it sounds like a proper paper otherwise. Of course for most software if it has value, it is a competition and its worth re-optimizing for each new platform otherwise you lose market to competitors. So actual programmers would rework those parts of the code rather than a general tool hack.
So this would only be a stopgap for dead end software you're locked into that isn't being maintained.
Actually, copyright is violated when you copy the work without permission and the purpose for copying the work does not otherwise make it exempt from infringement. If you don't distribute at all, and you do not profit from it in any way, then nobody else is necessarily even going to know you copied it, let alone want to prosecute you for it, but that does not necessarily mean it is necessarily legal (some jurisdictions even have private copying as exempt from infringement anyways, or for example, in Canada, have private-use copying exempt only so long as a mechanism for compensating at least some percentage private-use copies exists, such as levies on blank media where such copied content is considered by said controlling agencies to be likely to be copied onto).
Distribution of unauthorized copies is usually taken as gold-bar standard proof of infringement, since it establishes, in an objectively verifiable way, a non-private-use purpose for making those copies which can be presented by the copyright holder as a basis for the claim against the infringer. The action of distributing unauthorized copies is generally considered illegal as well, a crime related to infringement and no less than at least evidence of conspiracy to commit copyright infringement, but is not technically copyright infringement, not is it absolutely required to commit infringement... at most it may only be required to be held accountable for infringement.
File under 'M' for 'Manic ranting'
Read the instructions, loop optimize, branch optimize etc. rinse repeat. It's not novel, I mean we've had JIT optimization and others for a few years now. It does nothing with "code" but with the binaries generated from code.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
Is that even a thing? How do bits rot?
Yes, it's a thing. An important one, well-known to all software developers with a few years of experience.
Barring some sort of hardware failure the bits themselves don't change, of course. What changes is the context in which the bits are used. The article seems to be focusing mostly on performance, and that's one area of bit rot, a minor one. As hardware changes, the best performance optimization methods change, but the bits don't. Updating the code can improve performance. More important forms of bit rot have to with supporting libraries, or even business context. Causes and effects vary, but at bottom some assumption made by the old code is no longer true. If the assumption was never true, or for some reason the developer should not have expected it to be true, we call this a bug. But sometimes the code did make perfect sense as it was... but no longer. It's a bug now, but was correct previously.
That is bit rot.
Wikipedia has a fairly decent article if you want to read more: https://en.wikipedia.org/wiki/...
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.