Соответствует ли действительности то, что компилятор 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... Вы рады?
- Функциональное программирование
<<<... | 336—327 | 326—317 | ...>>>
Всего сообщений в теме: 346; страниц: 35; текущая страница: 2
| № 336 29-08-2007 08:27 |   |
Ответ на »сообщение 334« (Alexander)
___________________________
В Delphi есть понятие метакласса (aka ссылка на класс), и с его помощью можно создавать объекты, тип которых неизвесен на этапе компиляции. Соответственно, на этапе компиляции всё равно нельзя в общем случае отследить, экземпляр какого класса создаётся, и отказ компилировать такой код будет полумерой, всё равно нужен контроль в run-time. А раз нужен такой контроль, то логичнее выполнять его не во время создания класса, а во время вызова абстрактного метода. А вот C++ может себе позволить такой контроль, потому что там нет такого замечательного инструмента как метакласс, и поэтому на этапе компиляции всегда можно определить тип создаваемого объекта :)
| № 335 29-08-2007 06:53 | |
Ответ на »сообщение 334« (Alexander)
___________________________
Ответ на »сообщение 332« (Сергей Осколков)
___________________________
Это все так. Но в С++ вообще нет смысла создавать объект типа абстрактного класса. Поэтому С++ не выдаст предупреждений, он просто не станет компилировать!
Кроме того многие начинающие программисты на предупреждения даже не смотрят (я и сам был таким, компилируется и ладно)!
В Object Pascal нет понятия абстрактного класса. Если у класса есть асбтрактный метод - это не делает его абстрактным (ведь у него есть и другие методы).
Вместо асбтрактных классов есть интерфейсы - гораздо более продуманная конструкция, и экземпляр интерфейса действительно нельзя создать. Можно создать лишь объект, реализующий интерфейс.
| № 334 29-08-2007 06:37 | |
Ответ на »сообщение 332« (Сергей Осколков)
___________________________
Это все так. Но в С++ вообще нет смысла создавать объект типа абстрактного класса. Поэтому С++ не выдаст предупреждений, он просто не станет компилировать!
Кроме того многие начинающие программисты на предупреждения даже не смотрят (я и сам был таким, компилируется и ладно)!
| № 333 29-08-2007 06:32 | |
Ответ на »сообщение 331« (Alexander)
___________________________
:) вы б еще вот так написали:
a := 0;
b := 1;
c := b / a;
компилятор не всегда может следить за содержимым переменных, он следит лишь за соответсвием типов данных (тоже не всегда, но в большиснтве случаев). В приведенной Вами конструкции компилятор не имеет права ругаться на такой вызов так как он в принципе для пременной такого типа вполне правомерен (ведь в переменной такого типа может храниться объект класса-наследника, в котором этот метод может быть перекрыт).
| № 332 29-08-2007 06:26 | |
Ответ на »сообщение 331« (Alexander)
___________________________
Если будете писать в Дельфи, то получите предупреждение компилятора типа
[Pascal Warning] Unit1.pas(70): W1020 Constructing instance of 'TMy' containing abstract method 'TMy.F'
Во время выполнения при попытке вызова абстрактного метода будет сгенерировано исключение
EAbstractError. Это же исключение получите, если попытаетесь во время проектирования поместить на форму компонент с абстрактным методом.
| № 331 29-08-2007 06:09 | |
Многие говорят о безопасности (Устойчивости к ошибкам) программ написанных на Delphi по сравнения с С++. А как на счет:
type TMy = class
public
procedure F;virtual;abstract;
end;
procedure DoF;
var My: TMy;
begin
My:=TMy.Create;
My.F;
end;
Абстрактный метод однако!?
| № 330 29-08-2007 04:12 | |
Ответ на »сообщение 329« (Alexander)
___________________________
Подскажите мне пожалуйста где можно найти инфо о реализации классов в Delphi
В книгах.
(Наследование, абстрактные методы, перегрузка операторов …).
Хм... перегрузка операторов, говорите? А отчего не closures? ;-)
Хочу сравнить их в С++ и Delphi.
Начните со статьи "Сравнение ООП языков: Java, C++, Object Pascal"
| № 329 29-08-2007 03:25 | |
Подскажите мне пожалуйста где можно найти инфо о реализации классов в Delphi (Наследование, абстрактные методы, перегрузка операторов …). Хочу сравнить их в С++ и Delphi.
| № 328 28-08-2007 08:04 | |
Ответ на »сообщение 322« (Alexander)
___________________________
Ответ на »сообщение 321« (panda)
___________________________
Я не отрицаю что в Си можно написать лабуду.
Но конечный результат зависит от самого программиста,
от его чистоплотности.
Каждый раз, когда я встречаю подобный аргумент, я вспоминаю замечательную фразу Фрэнсиса Бэкона: "Наш интеллект нуждается не в крыльях, а скорее в свинцовых гирях, дабы умерить свое движение". Суть в том, что если язык позволяет писать плохо, то многие будут писать плохо. А ещё кто-то из великих (кажется, Чехов), сказал, что тот, кто неаккруатно говорит, так же неаккуратно мыслит. Это можно распространить и на программы - кто пишет как попало, как попало и алгоритмы продумывает. И лучше, если язык будет как можно сильнее ограничивать способность программиста писать абы как, потому что в этом случае и мыслить программист будет строже, аккуратнее. Программирование должно быть способом перенести свои мысли в программу, а не борьбой с излишне многогранным синтаксисом языка.
| № 327 28-08-2007 08:00 | |
Действительность, читаемость именно ЧУЖОГО текста является неоспоримым преимуществом pascal'а, так как язык располагает к интуитивно (логически) понятным конструкциям. Вообщем, проще говоря - язык более близок к естественному (английскому математическому :)
<<<... | 336—327 | 326—317 | ...>>>
Всего сообщений в теме: 346; страниц: 35; текущая страница: 2
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
