Is this, in the light of far new processors, a compiler optimisation worth ticking?
Printable View
Is this, in the light of far new processors, a compiler optimisation worth ticking?
Was it ever?
Actually, take a look at this.
Nowadays, does anyone have opinions about it ? (check / uncheck?)Quote:
Originally Posted by yrwyddfa
https://codereview.stackexchange.com...-string-in-vb6
Quote:
Can we make it even faster?
One quick and easy way to speed up the code is to change the compiler flags. Too few people do this in VB 6, since it is so well hidden. When building your EXE (File → Make *.exe), click the Options button to bring up a dialog. Switch to the "Compile" tab. "Compile to Native Code" is selected by default, and so is "Optimize for Fast Code", which are both good for speed. However, you should also turn on "Favor Pentium Pro" and "Create Symbolic Debug Info".
Creating debug info is just a good idea, in case you ever have to debug your application, and it is impossible to generate it later. This is arguably less useful for a strictly VB programmer who wouldn't know how to use another debugger with a gun to his head, but it is a skill that is truly worth learning, and if you ever have to call in an expert, a PDB file is invaluable. It doesn't hurt anything to generate it and ignore it.Why favor the Pentium Pro? Granted, this sounds like a hyper-specific option to favor a certain obsolete family of microprocessor, and indeed it was at the time that VB 5 was released, but it is actually the best general choice because all modern processors bear far more similarity to the Pentium Pro than they do to other generations of processors (with the exception of the Pentium 4, but VB 6 can't optimize for that anyway, and optimizing for PPro is still not a pessimization). The Pentium Pro was a unique processor in a number of ways, but two things were most important from an optimization sense. First, it supported out-of-order execution, where individual instructions could be dynamically re-ordered by the processor to overcome instruction-level data dependencies. Thus, it is better if the compiler generates shorter sequences of instructions (RISC-style), because these can be better reordered. Second, the Pentium Pro has a stall for certain partial-register accesses. The details are complicated and beyond the scope of this answer, but the important fact is that while the earlier Pentium didn't have these, all modern processors do, so having the optimizer generate code accordingly is a good idea.
Other important checkboxes are buried behind the "Advanced Optimizations" button. The UI tries to make these sound scary, but if you understand what they do, and your code has been truly and correctly debugged, some of them are worth enabling. Most obviously, you can turn on the bottom option, "Remove Safe Pentium FDIV Checks". The early Pentium processors with the infamous FDIV bug are long dead now, so this is just pointless baggage to carry around. The other options actually can be slightly unsafe, but it is worth considering turning on the "Remove Integer Overflow Checks" option, and possibly the "Remove Floating Point Error Checks" and "Allow Unrounded Floating Point Operations" options. These three options have a massive impact on the object code that is generated by the compiler, and enabling them can cause a correspondingly massive speed-up in the execution time of your code.
Started in '06 (what IS that, like SIXTEEN years ago???); resurrected in '19 (Three years ago), and raised from the dead again in '22????
I'm still laughing at the misspelling. "Faye voor" huh?
Quote:
Originally Posted by SamOscarBrown
So what?
Aren't you inerested about speed?
Did you know it?Quote:
The Pentium Pro was a unique processor in a number of ways, but two things were most important from an optimization sense. First, it supported out-of-order execution, where individual instructions could be dynamically re-ordered by the processor to overcome instruction-level data dependencies. Thus, it is better if the compiler generates shorter sequences of instructions (RISC-style), because these can be better reordered. Second, the Pentium Pro has a stall for certain partial-register accesses. The details are complicated and beyond the scope of this answer, but the important fact is that while the earlier Pentium didn't have these, all modern processors do, so having the optimizer generate code accordingly is a good idea.
(and no one has ever written anything ..... so what does it bother you?)
it is just one more little piece of information
just out of curiosity How many and what languages can you speak / read / write / understand besides your own?Quote:
Originally Posted by dilettante
Yes - though the block you quoted is ambigous in parts, e.g. in:Quote:
Originally Posted by reexre
Un-ambigously formulated - it should be:Quote:
Thus, it is better if the compiler generates shorter sequences of instructions (RISC-style),...
"Thus, it is better if the compiler generates longer sequences of shorter instructions (RISC-style),..."
And it is also kind of "misleading", because the last part:
...is nothing but speculation (when we talk about C2.exe and the compiler-switch in question)...Quote:
...having the optimizer generate code accordingly is a good idea.
I've never seen any proof so far, that C2.exe generates "anything different in the PE-file",
when the Pentium-Pro-Option is checked (at least not, when checked in addition to "Optimize for speed").
Just did a cheap test here on the compiler-output of RC6.dll (which is quite large, so smaller differences should sum up) -
but the bytesize of the produced PE-file remains absolutely identical (no matter if the Pentium-Pro-Option was checked or not).
HTH
Olaf
Honestly? NO! I'd be more interested in making sure I speeled things correctly. :bigyello:Quote:
Aren't you inerested about speed?
I find the below to be quite missleading
The only way you are going to see massive speed up is if your code is doing a huge amount of math in some routine. In most cases you will notice no difference in speed at all but are prone to crashes.Quote:
The other options actually can be slightly unsafe, but it is worth considering turning on the "Remove Integer Overflow Checks" option, and possibly the "Remove Floating Point Error Checks" and "Allow Unrounded Floating Point Operations" options. These three options have a massive impact on the object code that is generated by the compiler, and enabling them can cause a correspondingly massive speed-up in the execution time of your code.
Btw, when you use something like MyArray(i + 1) you get overflow check on i + 1 so this optimization does not concern math heavy modules only.Quote:
Originally Posted by DataMiser
cheers,
</wqw>