<font color='black' size='2' face='arial'><font size="2">   Hi! br>
   I'm looking for a 64bit processor that has similar timings with the Mobile Sempron presented inside the slow if then else report. br>
   A very basic(incomplete) project is attached to the bug report that will help you identify if the CPU you are using is what I'm looking for. br>
   If the program gives abnormal timings for "then" part, which can be identified with "(0,0)" lines compared to "else" part,identified with (0,1), please present the results. br>
   I'm looking for: br>
1)Do we use many CPU models with such results or the presented one is an exception? br>
2)If the presented one is not unique, are there common things that these CPU share? For example, the same functions present the anomalies. br>
3)Is there a workaround that we can find for these CPUs? br>
There are already some hints regarding use of "jne" on a certain CPU, hints that I would like to compare with other CPUs anomalies. br>
4)Should the documentation regarding optimizing code be modified in order to inform the programmer of such anomalies? br>
   For example extras from programmer's guide, "11.4 Tips to get faster code" br>
"Write your if/then/else statements so that the code in the "then"-part gets executed most of the time (improves the rate of successful jump prediction)." br>
Yes, but also at the moment I'm writing this text it looks like gambling with lots of resources at stake when using at least one particular CPU. br>
   Even if your CPU doesn't have "spikes" like the one presented, how reliable is the above statement? You might consider these "micro-benchmarks" useless but looking a little bit in the sources will make you identify these "micro-benchmarks" all over fpc and lazarus source codes. There are so many small functions and lots of small loops... br>
   Maybe "11.2 Processor specific" needs some update. br>
5)There is also an influence on loops due to these conditional jumps. Simply replacing a "while" with a "for" loop might have a huge impact on speed due to the initial assignment(not the pure precomputed value) of the "for" loop. I wrote this because I don't want to forget it(see the link found in the bug report, where original reporter probably didn't acknowledged this impact). br>
 <br>
   Anyway... br>
   The bug report can be found at http://bugs.freepascal.org/view.php?id=26089 br>
   Most likely the direct link won't work, reason why I identify the report with: issue number is "26089", and (not a good)presentation is "Slow code generated for if...then...else". br>
 <br>
   The project attached to the bug report is a zip file "ifthenelse.zip". I tried to make it easy to use. A 800MHz CPU will take less than 6 minutes so it's not like an eternity. br>
   If any of you is "lucky" enough to have a CPU with abnormal timings like the one presented in the "AMDSempronMobile3500plusx8664.txt" file, would I ask too much if you can use Delphi to double-check the results!? I've tried my best to keep the code ugly but as easy as possible to be modified for other pascal compilers. Maybe we'll have a surprise...who knows!?</font><br>
<font size="2">   Thank You!</font><br>

</font>