We had the same thing with C when we were benchmarking it against B3D once... the code was set up to perform a number of mathematical operations something like ten million times, and see how long it took. It looked like C was phenomenally fast until we realised that, because the results of the calculations were never actually used for anything, the compiler was completely ignoring them and we were testing nothing!
Taking the maturity of most C compilers vs. that of blitz, that's probably not too surprising. I imagine this particular optimization might be a little more difficult to achieve under Blitz due to it's loosely typed nature. Though certainly not impossible if the compiler is keeping track of such logic bugs. This is really a case of the compiler compensating for sloppy programming rather than optimizing. Though I suppose one could argue that the compensation is an optimization itself.
I have written machine code programs but I have never heard of the term "code alignment"?
In the course of my career, I've known a lot of people who know enough to be dangerous. The ones that actually get anywhere and become the experts are the ones that concede to the fact that there's always more to learn and there just might be someone out there that knows more than you. Of course, that's a religious position, regardless of how relevant it seems here.
What does that term refer to and do you have a short example of good "code alignment" and bad "code alignment"
Ok... here goes..
Code alignment is a processor related issue that affects the way data is retrieved to process.
When the processor reads data, it reads the block of instructions/data in multi-byte chunks. This differs from processer to processer and it's bus capacity.
If you store the "start" of your data at addresses that are not multiples of that chunk size, the processor must resolve the issue by performing multiple fetches across those borders and "glue" the instructions and/or data together to emulate the alignment it prefers.
Most modern processors can handle this emulation just fine. Though sometimes, the emulation will go out to lunch, and you'll end up with a bus error, and the program will abort, or crash, or cause terrible things to happen at the OS level. The undesired outcome is really dependant upon how the program is executed.
You can usually see the biggest impact when the placement of labels and loop points starts in the middle of an alignment point, or straddles two alignment segments.
I know this used to be an issue with the Blitz compiler back in the early days of Blitz2D. People would perform benchmark tests, and see performance increase if they added a "do-nothing" type of instruction just before the loop they were testing.
What was happening was that the "do-nothing" instruction was bumping the loop start to an address that the processor could fetch without doing that emulation. The result was performance in the magnitude of 10ms vs 1500ms.
At one point in time, I know this was an issue with the VB6 compiler as well. Though that might have been corrected in a service pack. Modern processors are typically fast enough now where this code can be written sloppily, and you can get away with it without noticable impact.
However, that doesn't excuse the fact that the emulation is not nearly as performant as aligning addresses the way the processor expects, or writing code that will destabilize into a bus error if the processor munges it up.
I disagree time to execute=number of instructions executed
I guess we can agree to disagree. However, since I've already pointed out two issues that you hadn't even heard of, perhaps it wouldn't be a bad idea to re-evaluate your opinion.
Instructions carry various weights in terms of processing time, and as illustrated by the code alignment issue, they are not always apparent.