Соответствует ли действительности то, что компилятор 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... Вы рады?
- Функциональное программирование
| № 26 18-11-2001 03:20 |   |
Мужики рыцари! Чего там говорить про С плас плас! Попробуйте тоже самое сделать в Visual Basic-е 6.0... VB заткнет Delphi в 2-3 раза. Я лично пробавал. Испытывал. Такой же цикл залобал, VB сделал у меня на 'тачке' в 2 раза быстрей чем Delphя. Сам я раньше тоже программирил на Делфях, но понял что ребята идут не туда перегрузили все что можно: формы, методы, объекты. Отстой полный. Microsoft хоть как то пытается выйти из положения, а Делфя наоборот поддается тому напрвлению Microsoft что Microsoft делал 1-2 года назад. ОТСТОЙ.
СПАСИБО.
| № 25 18-11-2001 02:11 | |
НАРОД! Всем благодпрен за ответ, но я вношу поправку в свой вопрос, поскольку сразу не разобрался:
Всё правильно. Понятно естественно почему такой код генерирует компилятор C++. Просто в языке Object Pascal цикл for - это проосто повторение n раз, а в С++ структура for гораздо более сложная: в ней можно указать условие окончания цикла любой сложности, а также изменять значение переменной-счётчика по любому закону, а просто структуры повторения n раз нет.
Но почему компилятор С++ не оптимизирует такой простой случай цикла for от 1 до n при изменении переменной-счётчика на единицу в каждом цикле?(естественно что оптимизация включена). Ведь даже если в Pascal задать цикл while вместо for, то компилятор Object Pascal в Delphi оптимизирует такой вариант как протой случай, и выполнится программа с while так же быстро как и с for.
Что действительно Borland дали маху с оптимизацией в компиляторе С++?
Ещё раз благодарен за ответ!
| № 24 17-11-2001 17:37 | |
НАРОД! Всем благодпрен за ответ, но я вношу поправку в свой вопрос, поскольку сразу не разобрался:
Всё правильно. Понятно естественно почему такой код генерирует компилятор C++. Просто в языке Object Pascal цикл for - это проосто повторение n раз, а в С++ структура for гораздо более сложная: в ней можно указать условие окончания цикла любой сложности, а также изменять значение переменной-счётчика по любому закону, а просто структуры повторения n раз нет.
Но почему компилятор С++ не оптимизирует такой простой случай цикла for от 1 до n при изменении переменной-счётчика на единицу в каждом цикле?(естественно что оптимизация включена). Ведь даже если в Pascal задать цикл while вместо for, то компилятор Object Pascal в Delphi оптимизирует такой вариант как протой случай, и выполнится программа с while так же быстро как и с for.
Что действительно Borland дали маху с оптимизацией в компиляторе С++?
Ещё раз благодарен за ответ!
| № 23 17-11-2001 14:10 | |
| № 22 17-11-2001 13:35 | |
Есть (в Java) такая штука, как JIT -- Just In Time, означает
компиляцию в нормальный процессорно-зависимый код непосредственно
перед исполнением. Автор пишет в конце статьи о подобной же фиче и у
C#
| № 21 17-11-2001 12:50 | |
"интерпритаторуемый" - ну и написал, самому смешно.
| № 20 17-11-2001 12:21 | |
| № 19 17-11-2001 12:04 | |
| № 18 17-11-2001 11:13 | |
При всей любви к Delphi, оптимизатор оставляет желать лучшего, а оптимизация вещественных чисел - плакать хочется.
Вопрос - почему Borland не займется оптимизацией, думаю, имеет простой ответ - ЭТО НАФИГ НИКОМУ НЕ НУЖНО.
Продукт позиционируется как "работающий с БД" и сравнивать его корректнее с VB ;-(
А заказчику просто предлагать купить комп посильнее...
Borland создает продукты для тех, кто их покупает, а покупают их не русские-насстоящие-ассемблерщики, а корпоративные-буржуины.
PS:
APR вырывается из рук санитаров и кричит:
"Borland! Сделай нормальный оптимизатор" ;-)
| № 17 17-11-2001 08:53 | |
Так, маленькое наблюдение... Писал я одну программулинку, не хотел завязываться на на конкретный тип у элемента массива. Описал так:
type
TArrItem = Byte;
И в коде потребовалось какой-то индекс умножить на его размер.
Offs := Offs * sizeof(TArrItem);
Я-то помню, что на месте Byte и Word может быть и LongWord... Понадеялся на компилятор в плане оптимизации... Помотрел asm (по памяти):
mov eax, Offs
mov Offs, eax
Т.е., умножать на единицу он всё-таки не стал, но в удовольствии подготовить для этого умножения регистры себе не отказал.
Так что я склонен верить, что Паскалевский компилятор оптимизировали хуже большинства Сишных (к Билдеровскому это не относится). Но правда и то, что сия бессмысленность не затормозит приложения сколько-нибудь заметно... Так что правы, наверное, были создатели Дельфей. :-)
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
