Slashdot Mirror
IBM Patents Optimization
jamie(really) writes "IBM appears to want to patent optimizing programs by trial and error, which in the history of programming has, of course, never been done. Certainly, all my optimizations have been the result of good planning. Well done IBM for coming up with this clever idea. What is claimed is: 'A method for developing a computer program product, the method comprising:
evaluating one or more refactoring actions to determine a performance attribute;
associating the performance attribute with a refactoring action used in computer code; and
undoing the refactoring action of the computer code based on the performance attribute.
The method of claim 1 wherein the undoing refactoring is performed when the performance attribute indicates a negative performance effect of the computer code.'"
IBM is on to something big here, folks. Now just try to wrap your mind around this idea: we somehow enable this optimization on ... multiple levels! Stay with me, stay with me, I know this seems like a crazy idea right now. But I imagine a future where just adding something as simple as -02 or -03 to your compile commands will increase the level of optimization at an expense of compilation time!
... what if you didn't have to type out each of your compile statements when you're compiling hundreds of files? What if, and this is totally futuristic possibility here, we introduce a build tool of some sort to the whole process? Let's call it Mack ... no, wait, Make!
Did you get all that? Because I think I just made history.
*grabs his head* Oh Jesus, oh sweet Jesus, another one's coming to me. It's gonna be big! What if
Elvis MF Christ I am going to be a rich man.
My work here is dung.
...there was a $10,000 bonus for patents at IBM in the month of April 2008, right? Alternatively, this was submitted internally at IBM on April 1, and someone missed the joke.
IBMs internal process must have slipped a lot since I was there. I was once on a team which applied for a patent which was useful and arguably non-obvious, the only problem being that IBM had actually done something similar some 20 years before (in a different language)... internal patent people shot it down.
If you're going to comment on a patent, read the patent first.
"IBM appears to want to patent optimizing programs by trial and error"... ...except that isn't what the patent claims describe. I'll grant that if your expectations have been set to believe that's what the patent covers (as mine had been by the summary), then it's possible to interpret the claims in a way that conforms to that assumption; but if you actually read the entire patent to understand the claims in context, that isn't what they really say.
What they are trying to patent is a specific optimization - that of reversing refactorings that the programmer did. If you would like to debate why this is, or isn't, a valid thing to patent, go right ahead; but please don't waste the debate by talking about all the different code optimization schemes that don't do what the patent describes and pretending they are prior art.
If you read the description, the claimed invention is not about trial and error development. The idea is that every time code is refactored, the development environment will tag the refactoring. Refactorings that could affect performance are transparently undone at compile time, so long as it wouldn't change the functional behavior of the program. Thus, the developer sees nice, neat comprehensible code, and the compiler sees more optimized, compiler-friendly code.
Also, if you look the application up on PAIR (the PTO's public patent application database, which contains more detail than the regular patent search or Google Patents), you'll see that it's a new case. That is, the Patent Office hasn't examined the application yet. It's highly likely that after a few rounds of office actions the claims will not look like the current ones. They will probably be narrower and hew more closely to the description in the specification.
This is not a method of gradually figuring out how to boost performance by trying different things.
This invention makes changes to the source code on the fly. The purpose is to allow programmers to re-factor code for readability, but un-do the process before compiling. Presumably this is built in to one of their automatic refactoring applications or IDE. It is about fixing the problems refactoring causes, specifically in this case performance issues. I assume it could work like automatic inlining of small, commonly used functions, but is open to be a lot more complex.
You click the buttons on the GUI, it refactors some things for you and maintains a history of those actions. It stores the resulting code, which you send to source control or final build kit or whatever. When building, it examines which changes had a negative impact on performance and reverts those before compiling.
To the user, the code is refactored. To the computer, it is not.
My question is, how the hell do you debug this kind of output, or store it in source control? You are clearly going to be locked in to the same IDE, and probably same IDE version, and have to check in all of the project files. Cross-compilation is going to be difficult at best, since compiling the raw code won't have the performance enhancements. Clever for a closed-process shop, but kinda impractical.
What will be more interesting is whatever people come up with to deal with the misery this will create.