void __fastcall TForm1::Button1Click(TObject *Sender)
{

 for (int i = 0; i < 1000000000; i++);

}

procedure TForm1.Button1Click(Sender: TObject);

 var i : integer;

begin

 for i:= 0 to 1000000000 do;

end;

xor edx, edx

mov [ebp-0x34], edx
inc dword ptr [ebp-0x34]
mov ecx, [ebp-0x34]
cmp ecx, 0x3b9aca00
jl -0x0e

mov edx, $3b9aca00
dec edx
jnz TForm1.Button1Click + $5

void __fastcall TForm1::Button1Click(TObject *Sender)
{

 for (register int i = 0; i < 1000000000; i++);

},

mov eax, 0x3b9aca00
dec eax
test eax, eax
jnle -0x05

 for (int i = 0; i < 1000000000; i++);

for(int i = 1; i < 1000000; i++)
    for(int j = 1; j < 1000; j++);

Ответ на »сообщение 295« (Антон Григорьев)
___________________________

Ответ на »сообщение 294« (al_mt)
___________________________

Вообще-то было бы странно, если бы .Net приложение работало бы быстрее нативного кода %)

Не все с этим согласны :)

... может оптимизировать финальный исполняемый код, используя инструкции конкретного машинного кода, предназначенные для конкретного процессора."
А вот эта вот байда - чистый маркетинг. заметьте оговорку "может" :)))) В принципе может. На деле получается, что время компиляции прибавляется к времени исполнения %) %))))))

Ответ на »сообщение 294« (al_mt)
___________________________

Вообще-то было бы странно, если бы .Net приложение работало бы быстрее нативного кода %)

Не все с этим согласны :)

"<...> Это объясняет, почему можно рассчитывать на то, что выполнение управляемого кода IL будет почти настолько же быстрым, как и выполнение родного машинного кода. Однако это не объясняет того, почему Microsoft ожидает повышения производительности. Причина состоит в том, что поскольку финальная стадия компиляции происходит во время выполнения, JIT-компилятор на этот момент уже знает, на каком типе процессора запущена программа. А это значит, что он может оптимизировать финальный исполняемый код, используя инструкции конкретного машинного кода, предназначенные для конкретного процессора."

Кристиан Нейгел, Билл Ивьен, Джей Глинн, Карли Уотсон, Морган Скиннер, Фллен Джонс "C# 2005 для прфессионалов" М.: Издательский дом "Вильямс", 2007, страница 46.

Ответ на »сообщение 293« (Марина)
___________________________

>Интересно всё таки какой нибудь более сложный тест придумать, чтобы проверить насколько сильно этот баг >влияет на скорость выполнения реальных приложений.

На Gamedev народ тоже столкнулся с проблеммой Delphi 10 работает медленнее чем Delphi 7.

http://www.gamedev.ru/flame/forum?id=66154&page=12
Вообще-то было бы странно, если бы .Net приложение работало бы быстрее нативного кода %)

>Интересно всё таки какой нибудь более сложный тест придумать, чтобы проверить насколько сильно этот баг >влияет на скорость выполнения реальных приложений.

На Gamedev народ тоже столкнулся с проблеммой Delphi 10 работает медленнее чем Delphi 7.

http://www.gamedev.ru/flame/forum?id=66154&page=12

Ответ на »сообщение 291« (DRON)
___________________________

Ну и хрен с ним (оптимизатором)

"Wipe your hand across your mouth, and laugh"

T.S.Eliot

Ответ на »сообщение 290« (Cepгей Poщин)
___________________________
Я тут слегка погуглин и нашёл вот это http://qc.codegear.com/wc/qcmain.aspx?d=8695, действительно ошибка в кодогенератор была внесена именно в D7Update1 и с тех пор не исправлена, хотя и помечена как "Closed в D2005".
Выражается она в том что оптимизатор тупит и забывает про существование некоторых регистров, в данном случае про ebp, а это приводит к интенсивным обменам с памятью (стеком). Те у кого Delphi7 ещё могут заменить DCC32.exe и DCC70.dll на оригинальные, с диска, остальные вообще в пролёте.
Правда должен сказать, что это заметно только на довольно специфическом коде где много одновременно задействованных локальных переменных и нет ничего кроме обменов и простейших операций, а если выбрать алгоритм немного посложнее, то и D5 и D7 будут генерить одинакого плохой код.
Интересно всё таки какой нибудь более сложный тест придумать, чтобы проверить насколько сильно этот баг влияет на скорость выполнения реальных приложений.

По поводу сравнения скорости работы Delphi5 и BDS2006 см. »сообщение 250 в теме №377 на БП«
Вот мои печальные выводы:
Действительно вынос кода в процедуру и замена for на while деает некоторое улучшение, но тем не менее BDS2006 работает медленнее чем Delphi5 в 1,4..1,6 раза. Было бы еще понятно, если бы это происходило на каком-нибудь Pentium-90. Но тест производился на Pentium4 3GHz
Вот тестовая программа:

program TestTime;
{$APPTYPE CONSOLE}
uses
  Sysutils,
  Windows
  ;

var
  razmer:integer;
  b:array[1..20] of integer;
  Time1,Time2,nomvar,d,m,kl,min,obmen:integer;
procedure CallFor;
var  b:array[1..20] of integer;
    d,m,kl,min,obmen:integer;
begin
  for d:=1 to 20 do
    b[d]:=d;
  nomvar:=0;
  while True do
    begin
      nomvar:=nomvar+1;
      for m:=razmer downto 2 do
        if b[m]>b[m-1] then
          break;
      if m=1 then
        Break;
      obmen:=m-1;
      for min:=obmen+1 to razmer do
        if (b[min]<b[m]) and (b[min]>b[obmen]) then
          m:=min;
      min:=b[obmen];
      b[obmen]:=b[m];
      b[m]:=min;
      for d:=obmen+1 to razmer-1 do
        begin
          m:=d;
          for kl:=d+1 to razmer do
            if b[kl]<b[m] then
              m:=kl;
          min:=b[m];
          b[m]:=b[d];
          b[d]:=min;
        end;
    end;
end;

procedure CallWhile;
var  b:array[1..20] of integer;
    d,m,kl,min,obmen:integer;
begin
  for d:=1 to 20 do
    b[d]:=d;
  nomvar:=0;
  while True do
    begin
      nomvar:=nomvar+1;
      for m:=razmer downto 2 do
        if b[m]>b[m-1] then
          break;
      if m=1 then
        Break;
      obmen:=m-1;
      for min:=obmen+1 to razmer do
        if (b[min]<b[m]) and (b[min]>b[obmen]) then
          m:=min;
      min:=b[obmen];
      b[obmen]:=b[m];
      b[m]:=min;
      for d:=obmen+1 to razmer-1 do
        begin
          m:=d;
          kl:= d + 1;
          while kl <= razmer do
          begin
            if b[kl]<b[m] then
              m:=kl;
            inc(Kl);
          end;
          min:=b[m];
          b[m]:=b[d];
          b[d]:=min;
        end;
    end;
end;


begin
  Sleep(1000);
  razmer:=12;
  CallFor;
  CallWhile;

  razmer:=13;
  Time1:=GetTickCount;
  for d:=1 to 20 do
    b[d]:=d;
  nomvar:=0;
  while True do
    begin
      nomvar:=nomvar+1;
      for m:=razmer downto 2 do
        if b[m]>b[m-1] then
          break;
      if m=1 then
        Break;
      obmen:=m-1;
      for min:=obmen+1 to razmer do
        if (b[min]<b[m]) and (b[min]>b[obmen]) then
          m:=min;
      min:=b[obmen];
      b[obmen]:=b[m];
      b[m]:=min;
      for d:=obmen+1 to razmer-1 do
        begin
          m:=d;
          for kl:=d+1 to razmer do
            if b[kl]<b[m] then
              m:=kl;
          min:=b[m];
          b[m]:=b[d];
          b[d]:=min;
        end;
    end;
  Time2:=GetTickCount;
  Writeln('Count: '+IntToStr(nomvar));
  Writeln('Time: '+IntToStr(Time2-Time1)+'(ms)');
  Time1:=GetTickCount;
  CallFor;
  Time2:=GetTickCount;
  Writeln('Count: '+IntToStr(nomvar));
  Writeln('Time: '+IntToStr(Time2-Time1)+'(ms)');
  Time1:=GetTickCount;
  CallWhile;
  Time2:=GetTickCount;
  Writeln('Count: '+IntToStr(nomvar));
  Writeln('Time: '+IntToStr(Time2-Time1)+'(ms)');
  Readln;
end.

Может я что-то делаю не так?

Прочитал сообщение Максима и удивился!!! Кто же ТАК сравнивает компиляторы, дорогой товарищ :) Господа из Борланд инфаркт бы схватил, если бы узнали о Ваше методике. Компиляторы сравниваются на реальной задаче, где активно используются мат.вычисления, постоянно используется оперативная память... Просто запустить цикл, и все? Как-то в Компьютерном обозрении была опубликована статья на тему сравнения компиляторов. Автор использвал задачу решения дифференциальных уравнений численными методами. Там был Delphi, Borland C++, MSVC++, GCC, Fortran, Intel C++, VB(!) и некоторые другие... Так вот по рещультатам забега первое место занял Intel Fortran, за ним Intel C++, GCC и все остальные. Delphi и Borland C++ показали одинаковый результат.

Кстати, в Borland C++ нужно еще выбрать конфигурацию проекта Release, вот тогда все будет работать очень быстро, быстрее чем в Delphi.

Сам я тоже такими вещами баловался когда-то... Только тест немного посложнее делал: в цикле давал вычислительную нагрузку, потом рекурсивно реализовывал вычисление числа сочетаний из n по k (C(n, k)), в общем в таком духе :) Так у меня C++ всегда ощутимо быстрее оказывался. Такие дела.

Если Вам нужна качественная оптимизация кода и поддержка современых процессоров - выбирайте компилятор Intel, не пожалеете! Он многое умеет (почитайте спецификации на сайте ИНтел), хотя и денег стоит.
p.s.: это не реклама

Просто факт.

MSVC7 и C# используют в FPU Control Word
дефолтное значение (PrecisionMode = double)
BC++ и Delphi - PrecisionMode = extended
Это, что жульничество MS или недоработка Borland?
Ведь (PrecisionMode = double) ускоряет вычисления с
плавающей точкой процентов на 10 по отношению к
(PrecisionMode = extended).