6 ms·

“Those who cannot remember the past are condemned to repeat it.” I find it funny to talk to much younger developers, they get excited about some "new" technolo

“Those who cannot remember the past are condemned to repeat it.” I find it funny to talk to much younger developers, they get excited about some "new" technology and are surprised I do not feel the same. Probably they think I am old and grumpy and can't see the value in it. The truth is that a lot of it is just same verbatim or rehashed concepts that have already been known under a lot of guises for a long time. Sometimes discarded by new generation only to be re-discovered after couple of years when their software starts to suck for no obvious reason. I suggest that any person trying to do hardcore performance optimization today should invest some time learning tricks of developers that wrote software in 80s. There is wealth of useful knowledge hiding in plain sight.

ByteJockey 5y ago
Do you have any good links for starting points? I've always been interested in the subject, but articles that cover it competently are usually few and far between.
- lmilcin 5y ago
  I don't. I have either learned these a long time ago or as a side effect of paying attention to this topic for almost quarter of century. But I think it should still be possible to find old source code for things like games. Back when I was learning that stuff it was very difficult to get access to real game code, but today there is a lot of titles that have released its source code for everybody to pore over.
SCHiM 5y ago
Although I can't claim a long tenure in the software development field. One of my favorite tricks/rediscovered performance enhancer can be found in a similarity between very old-school self-modifying code, and modern day profile guided JIT optimizer. I think I read somewhere that, at some point, it was all the rage to have self-modifying code that could patch conditional branch instructions into unconditional ones (I think it was used on game consoles to save space). These days profile guided JIT compilers (or even AOT compiler) will de-virtualize calls to increase performance, which to me looks like a really similar technique.
- lmilcin 5y ago
  The value of JIT is that you do not need to pay any attention to it and it takes no effort to set up. It is still good to know it is there -- a lot of developers I work with did not understand why a Java application is slow for a bit before it becomes faster. They just take it as a fact of life. (Of course JIT is just a part of this, you also have classes loaded, various mechanisms implementing lazy initialization getting initialized the first time it is used, etc.)

ByteJockey 5y ago

Do you have any good links for starting points? I've always been interested in the subject, but articles that cover it competently are usually few and far between.

lmilcin 5y ago
I don't. I have either learned these a long time ago or as a side effect of paying attention to this topic for almost quarter of century. But I think it should still be possible to find old source code for things like games. Back when I was learning that stuff it was very difficult to get access to real game code, but today there is a lot of titles that have released its source code for everybody to pore over.

SCHiM 5y ago

Although I can't claim a long tenure in the software development field. One of my favorite tricks/rediscovered performance enhancer can be found in a similarity between very old-school self-modifying code, and modern day profile guided JIT optimizer. I think I read somewhere that, at some point, it was all the rage to have self-modifying code that could patch conditional branch instructions into unconditional ones (I think it was used on game consoles to save space). These days profile guided JIT compilers (or even AOT compiler) will de-virtualize calls to increase performance, which to me looks like a really similar technique.

lmilcin 5y ago
The value of JIT is that you do not need to pay any attention to it and it takes no effort to set up. It is still good to know it is there -- a lot of developers I work with did not understand why a Java application is slow for a bit before it becomes faster. They just take it as a fact of life. (Of course JIT is just a part of this, you also have classes loaded, various mechanisms implementing lazy initialization getting initialized the first time it is used, etc.)