Соответствует ли действительности то, что компилятор Object Pascal в
Delphi лучше компилятора C++ в C++Builder? Для эксперимента я создал два
проекта на С++Builder и Delphi соответственно, и всего навсего в процедуре
обрабатывающей нажатие на кноку задал пустой цикл от 1 до 1 миллиарда:
В С++Builder соответсвующая функция выглядела сл. образом:
void __fastcall TForm1::Button1Click(TObject *Sender)
{
for (int i = 0; i < 1000000000; i++);
}
а в Delphi соответствующая процедура выглядела так:
procedure TForm1.Button1Click(Sender: TObject);
var i : integer;
begin
for i:= 0 to 1000000000 do;
end;
И что же оказывается - Программа на Delphi выполняется в 5 раза быстрее(4
сек., а на С++Builder - 20 cек.)! ??
Тогда я решил выяснить в чём разница в конечном коде, генерируемом
компиляторами C++Builder и Delphi. Для этого я просто установил точки
останова(breakpoint) напротив циклов и во время выполнения заглянул в
Debug Windows/CPU и что оказалось:
код сгенерированный компилятором С++Builder, соответсвующий пустому циклу
в ассемблерном представлении выглядит сл. образом:
xor edx, edx
mov [ebp-0x34], edx
inc dword ptr [ebp-0x34]
mov ecx, [ebp-0x34]
cmp ecx, 0x3b9aca00
jl -0x0e
А у Delphi получился такой код:
mov edx, $3b9aca00
dec edx
jnz TForm1.Button1Click + $5
Т.О. отсюда уже понятны причины почему программа на Delphi быстрее
выполняется. Помимо того что бросается в глаза большее количество команд
видно ещё принципиальное отличие - в коде первой программы в качестве
переменной-счётчика используется ячейка памяти, а компилятор Delphi
сгенерировал код в котором используется регистр процессора в качестве
счётчика. Хорошо, можно и устранить последнее отличее сл. образом:
void __fastcall TForm1::Button1Click(TObject *Sender)
{
for (register int i = 0; i < 1000000000; i++);
}, т.е. перед переменной-счётчиком i указали спецификатор register,
предварительно в настройках компилятора разрешив использование Register
Variables(Project/Options/Advanced Compiler/Register Variables).
Действительно тогда код сгенерированный компилятором С++Builder изменится
к виду:
mov eax, 0x3b9aca00
dec eax
test eax, eax
jnle -0x05
Как видим теперь уже почти не отличается от кода сгенерированного
компилятором Delphi! За исключением одной лишней команды - test eax,
eax(зачем она нужна??) и команды jnle вместо jnz. Вот за счёт этой лишней
команды test eax, eax, кот. выполняется в цикле и увеличивается время
выполнения (на 15 сек. становится дольше). Так что же это?! Низкое
качество генерируемого кода компилятором C++Builder в сравнении с
компилятором Delphi?? Специалисты! Помогите! Проясните ситуацию. Какой же
компилятор лучше - C++Builder или компилятор Delphi?? Или возможно как-то
добиться той же эффективности кода, настроив как-то компилятор С++ в
С++Builder? Очень благодарен за ответы с пояснением!
PS Ещё заметил такой прикол, что если в С++Builder вместо просто цикла от
1 до миллиарда использовать 2 равносильных цикла, т.е. один вложенный в
другой: внешний от 1 до миллиона, а внутренний от 1 до тысячи, вот тогда
как ни парадоксально скорость выполнения 2х циклов быстрее в 5 раз чем
просто одного от 1 до миллиарда! Т.Е. вариант:
for (int i = 0; i < 1000000000; i++);
много медленее, чем вариант:
for(int i = 1; i < 1000000; i++)
for(int j = 1; j < 1000; j++);
!!?? Получается что если нам надо выполнить какие-то действия в
программе миллиард раз, нужно это сделать не в одном цикле, а задать
внешний цикл от 1 до миллиона и внутренний от 1 до тысячи, например, и в
теле внутреннего описать все действия!!??
Максим
Всего в теме 346 сообщений
Добавить свое сообщение
Отслеживать это обсуждение 
- Средства разработки. Языки программирования.
- Delphi 4 or Delphi 5
- Что приобрести в качестве средства разработки?
- Delphi6
- Delphi vs PowerBuilder
- Вот и вышла Delphi 7... Вы рады?
- Функциональное программирование
346—337 | 336—327 | ...>>>
Всего сообщений в теме: 346; страниц: 35; текущая страница: 1
| № 346 08-09-2008 08:24 |   |
М-дя... Видимо, разработчиков достало нытье отдельных сиобразномыслящих товарищей по поводу неудобства строгой типизации. Вот и решили сделать им приятное. А жаль. Языков программирования с нестрогой типизацией и так выше крыши. В том числе и паскалеобразных. Так что нет смысла делать еще один.
| № 345 08-09-2008 07:36 | |
Ответ на »сообщение 344« (panda)
___________________________
Т.е. он считает, что тип определяется исключительно первым операндом Смелое предположение :)
| № 344 08-09-2008 07:22 | |
Ответ на »сообщение 343« (Cepгей Poщин)
___________________________
А на cmp ax, ebx компилятор генерирует cmp ax, bx. Т.е. он считает, что тип определяется исключительно первым операндом.
| № 343 08-09-2008 06:19 | |
Недавно заметил такую вещь:
program Project4;
uses
SysUtils;
begin
try
Asm
cmp eAx, Bx //Delphi 5: [Error] Project4.dpr(11): Operand size mismatch
//Delphi 2007 создаётся код: cmp eAx, eBx
End;
except
on E:Exception do
Writeln(E.Classname, ': ', E.Message);
end;
end.
Один и тот же код в Delphi 5 не компилируется, а в Delphi 2006+ компилируется безо всяких Hint`ов. На мой взгляд нельзя однозначно утверждать, что программист имелл ввиду сравнение именно 32-разрядных операндов, а при работе с 16-разрядными операндами в старшей части возможно и будет 0, но строго говоря, там может быть случайное значение. В результате получим программу которая будет случайным образом работать то правильно, то не правильно, что особо затрудняет отладку. Как ваше мнение это просто ошибка компилятора, или такая работа продиктована некими неизвестными мне причинами?
| № 342 10-10-2007 16:31 | |
| № 341 10-10-2007 08:59 | |
| № 340 10-10-2007 08:44 | |
Ответ на »сообщение 339« (Beginner)
___________________________
>>> Толко что читал слова Дейкстры о том, что будущее за лаконичными языками...
Осталось только объяснить это мелкомягким
*смотрит на MS-стандарт HTML, на XML и прочие "прелести" последннего времени*
| № 339 10-10-2007 07:50 | |
Ответ на »сообщение 338« (Антон Григорьев)
___________________________
Толко что читал слова Дейкстры о том, что будущее за лаконичными языками...
| № 338 10-10-2007 06:40 | |
| № 337 29-08-2007 09:59 | |
Ответ на »сообщение 331« (Alexander)
___________________________
My:=TMy.Create;
My.A;
My.B;
My.C;
My.F; И от себя добавлю пять копеек :) Допустим гипотетически компилятор не станет компилировать этот код. Тогда нет ни какой возможности протестировать работу других абстрактных методов (A, B, C, ... очень много), до тех пор, пока все не создаш. Это приведет к тому, что программист будет создавать пустышки и обязательно парочку так и оставит, т.е. смысл служебного слова abstract теряется. При этом вообще нельзя будет разобраться какая из этих пустышек оставлена по забывчивости, а какая по тому, что так надо.
346—337 | 336—327 | ...>>>
Всего сообщений в теме: 346; страниц: 35; текущая страница: 1
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
