Skip to main content


Showing posts from October, 2005

The road to performance

Why is it that every time a developer has to go optimize something in assembler, they have to re-learn the darn language again? Okay, you've optimized the, to use a technical term, crap out of that loop in C/C++ and it is not calling any functions what-so-ever any more...and it still has lousy performance. So, now you have to make the tough call to move to assembler. It will instantly tie your application to a single compiler and architecture and make it that much harder to port. Any reasonable business person will look at the potential millions lost and will decide that the product is "good enough" if it means getting it cross-platform faster to gain an extra 20% market share sooner and then go back later to "fix" the problem. Unfortunately, in this case, there is only one platform and the performance is abysmal. The program should be operating at 10 times the speed it is actually performing at. And I've forgotten just about everything assembler in a

Rubber melts

I discovered today that rubber can melt just sitting in one place and that putting a graphing calculator under running water causes it to stop functioning. I picked up my calculator today that I've had for forever and my hand stuck to it. Removing my hand from the sticky revealed that the sticky had gotten on my hand. So, I went to the restroom to see if I could do something about it. Then I got back and realized that the sticky was everywhere. So, not thinking clearly, I took the calculator and ran it under water. And soap. Soap seemed pretty effective against the melted rubber pad and the only really good way to remove soap is with running water. Now each TI-82 graphing calculator that Texas Instruments manufacturers comes with four rubber pads. Only one of the four has melted so far. I'm letting it air dry for the next few days in the hope that nothing is seriously wrong (i.e. a short). I've never been very good with electronics, but I do know that water doesn