Optimization is like having a friend who does you many good favors, but is also a drug addict and occasionally steals from you. It does not if there are no bugs in the optimizer. It can still have surprises though. Our optimizer was severely tested for bugs. First of all, it started out as a relatively simple program, so there were few bugs in it. We introduced only a few changes at a time, and we had an independent test group doing the testing. First of all, we ran a suite of test programs on it designed to catch obvious bugs. As we got bug reports from other users in the company, if we could duplicate the problems, we added them to the test suite.We would compile the entire software development package, including the compiler, optimizer, assembler, run-time library, etc. with the optimizer on, and run all their test suites on them to ensure that they worked. We then compiled the UNIX kernel and all the stuff in the SVID test suite and make sure the whole thing worked. The UNIX kernel developers said it was not designed to be optimized, but we found no trouble in compiling it.Once we compiled everything with everything optimized, we took the optimized system and compiled everyting again with the optimization on and did the system testing all over again. When all was said and done, we got no errors in the testing program. (This does not mean there were no errors, but it does mean that we found none. And by adding all previous errors to the test suite, it meant we would catch any bugs that got put back in somehow.)Now the basic idea of the optimizer was that using it would not change the results of compiling a correct program. It was silent on what happened with incorrect programs. And there were a lot of those. The thing we could not manage was if a program used (dereferenced) a pointer that never had a value assigned to it. These were all bugs that would give undefined results. One of the things the optimizer did was called register overloading. We would put different values in the same register at different times for speed increases. Now if a pointer was put into a register, and the pointer had never been assigned a value, you would get whatever value was previously in that register, and it could be anything. Sloppy programmers never knew they were dereferencing a pointer that was not assigned a value. So if we optimized it, they would get a different wrong answer than they would get with an unoptimized version.Now in our version of the UNIX kernel, we arranged that the bottom page of memory was not used. And the memory mapping registers were set to fault if a reference was made to that page. In an unoptimized version of a program that used an uninitialized pointer was used, the pointer was zero, so it caused a fault that made it easy to see what the trouble was. But the idiots had this feature turned off because they were getting too many faults. Instead of fixing these errors, they ignored them. This is completely insane. I turned it on and started filing bug reports on these programs (compilers, the kernel, etc. I filed so many that the group in charge of fixing bugs blocked all bug reports from me. We hired a clerk to file bug reports on my behalf. I mean a dozen or two of bug reports a week. The "support" group got wise to this and ignored the bug reports she filed too. This is completely irresponsible and I hope they all found themselves in an ICU somewhere where the equipment used that software.
Best Of |
Favorites & Replies |
Start a New Board |
My Fool |
BATS data provided in real-time. NYSE, NASDAQ and NYSEMKT data delayed 15 minutes.
Real-Time prices provided by BATS. Market data provided by Interactive Data.
Company fundamental data provided by Morningstar<