| Orifiel |
| Отправлено: 21.01.2004, 15:46 |
|
Не зарегистрирован
|
Наверное подавляющее большинство согласится с мнением,
что CBuilder на голову превосходит практически все известные
на сегодня IDE под Винду. Почему все же считается хорошим тоном
програмить на конченом мелкософтовском VC с его мастдайной MFC?
С интересом готов рассмотреть ваши соображения на сей счет, коллеги. |
|
| maikl |
| Отправлено: 21.01.2004, 15:58 |
|
Станционный диспетчер
Группа: Участник
Сообщений: 135
|
Согласен, на моем курсе так же несколько студентов на VC программировали свою курсовую, в общем от этого они не были в восторге, очень жалели, ругались на эту среду программирования. Короче сказали что Builder и Delphi рулят. Ну а если посмотреть шире, то каждый использует то что ему больше нравится, и где он чего больше знает, кто то возможно боится или просто не хочет осваивать что то новое. |
|
| Nick |
| Отправлено: 21.01.2004, 18:03 |
|
Машинист паровоза
Группа: Участник
Сообщений: 247
|
VC не видел но говорят код получается оптимальней. |
|
| Ламер (редкий) |
| Отправлено: 06.02.2004, 12:56 |
|
Не зарегистрирован
|
я думаю, что Borland основательно обосрется со своим CBuilderX
и вскоре сделает чей-то типа CBuilder.NET с полной поддержкой VCL
|
|
| Asher |
| Отправлено: 06.02.2004, 20:53 |
|
Мастер участка
Группа: Модератор
Сообщений: 550
|
Привет всем.
Я вот тут, в связи со всякими последнини событиями, типа BuilderX, решил посмотреть в сторону MS VC.
Попробовал написать микропримерчики и сравнить с Builder'ом.
VC получился определенно быстрей, особенно в плане создания/удаления объектов классов (читай скорость выделения/освобождения памяти) и в плане использования inline.
И виртуальные функции тормозней обычных всего на ~12%, а не на 23-25% как в Builder'e.
Визуальная часть, особенно после Builder'а, выглядит уж слишком убого, а может просто с непривычки.
P.S. Складывается впечатление, что я эти два неполных года программировавал не на том компиляторе  . хотя и в той среде. 
P.P.S. Может писать ядро на чистом С++ в VC или ICC, а потом ко всему этому хозяйству прикручивать оболочку на Builder'е? (это если ядро позволит  )
|
|
| Георгий |
| Отправлено: 07.02.2004, 00:28 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
Пьяный Жорик снова в форуме и пытается всех задавить своим снобизмом — QNX4.25 + WC10.6 это очень круто!!! а фильм "28 дней" ещё круче!!! |
|
| Asher |
| Отправлено: 09.02.2004, 13:39 |
|
Мастер участка
Группа: Модератор
Сообщений: 550
|
To Георгий:
Обоснуй.
|
|
| Zmey |
| Отправлено: 09.02.2004, 14:53 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 15
|
Код, написанный на VC++, по всем параметрам превзойдет билдеровский.
Единственный и весьма существенный недостаток VC++ неудобный IDE и бедный набор компонентов, что сильно влияет на скорость разработки.
Однако, попробуйте на Билдере написать простенький драйвер .....
Кроме того, писать код на VC++, это на 90 % работать с WIN32 API, что делает програмиста на уровень проффесиональнее, так как необходимо хорошо понимать архитектуру ОС, ее особенности и работу. В Билдере же все нюансы работы с ОС скрыты, поэтому многие, пишущие исключительно на нем ВАЩЕ не понимают как и что работает ....
Я использую Билдер исключительно для разработки прог под СУБД — быстро и просто.
Все остальное — VC++
|
|
| Георгий |
| Отправлено: 10.02.2004, 00:22 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
Zmey
очень точная характеристика! Даже придраться не к чему.
Asher
Ща трезвый... Будет трудно обосновать...
Ладно, начнём обоснование 
фильм 28 дней — давно такого прикольного не видел: на фоне а ля "Resedent Evil" разворачивается действие по сути напоминающее "Бойцовский клуб", но не столь бессмысленное. Прошлись по многим особенностям нынешнего общества и это на фоне столь сильного, кровавого и жестокого действия.
QNX4.25 + WC10.6:
к watcom компиляторам всегда питал слабость — некоторые полюбившиеся мне игры были скомпилированы на нём (например UFO1), также потрясающие возможности по оптимизации кода — современные компиляторы не сильно обогнали старичка (1996, кажется, год выпуска WC10.6).
| QUOTE | | И виртуальные функции тормозней обычных всего на ~12%, а не на 23-25% как в Builder'e |
откуда такие монстрообразные цифры???
физически виртуальные функции реализованы, как вызов по указателю(по адресу, записанному в поле структуры) и подобгный вызов всего лишь на нескольно тактов медленнее обычного (по прямому адресу) т.е. если вызов функции ~10 тактов, то на вычисление её адреса уйдёт ещё 2-3 такта (при условии, что данные лежат в кэше) т.е. +20-30%; return из функции займёт ещё ~5 тактов, и это при пустом теле функции (чего в реальной жизни не бывает) т.е. в худшем случае будет только 13-20% проигрыша во времени работы, а в реальной жизни и того меньше — если тело функции выполняется за 100 тактов, то накладные расходы на вызов по указателю будут нивелированы и составят всего лишь 2-3%.
QNX — просто порадовала — столь лаконичная и красивая идея, да и вдобавок качественно реализованная!
существует эффективная графическая оболочка для QNX4.xx — photon1.xx
и проблема эффективности компилятора в ней решена очень просто — средства разработки для photon генерируют си код который компилится стандартным компилятором (моим любимым wc). вдобавок программист может работать на 3-х уровнях абстракций:
1 — очень похоже на bcb — шмякаем элементы GUI на формы, связываем менюшки, устанавливаем обработчки. Для создания простенького отображения чего-нибудь никаких усилий не надо.
2 — без использования Application Builder`а (именно о нём шла речь в первом пункте) — создаём в програмном коде все объекты, устанавливаем обработчики и вызываем функцию PhMainLoop (название пишу по памяти, могу ошибиться), которая сама вызывает необходимые обработчики. аналоги под MS не придумывается...
3 — почти 2, но Receive теперь делаем ручками соответственно пользовательским интерфейсом распоряжаться тоже нам. Это очень сильно напоминает написание программ на си под win32 ,без использования RAD.
НО, в отличии от MS + ( bcb || vc ) это всё без потери производительности.
удалось убедить, что QNX4+WC это круто? |
|
| Asher |
| Отправлено: 10.02.2004, 10:10 |
|
Мастер участка
Группа: Модератор
Сообщений: 550
|
To Георгий: Убедил Я в принципе и не сомневался
По поводу полученных мной процентов:
пишем простенький пример
| CODE |
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
long Var, Count;
struct B {
void f();
virtual void vf();
};
struct D : B {
void vf(); // замещаем B::vf
};
void f1(B* ptr)
{
ptr->f();
}
void f2(B* ptr)
{
ptr->vf();
}
int main(int argc,char** argv)
{
if (argc>1) Count=atol(argv[1]);
clock_t c1,c2;
D d;
{
c1=clock();
for (long i=0; i<Count; i++)
for (long j=0; j<1000000; j++)
f1(&d);
c2=clock();
printf("f1(): %ld mlns calls per %.1f sec\n",Count,double(c2-c1)/CLK_TCK);
}
{
c1=clock();
for (long i=0; i<Count; i++)
for (long j=0; j<1000000; j++)
f2(&d);
c2=clock();
printf("f2(): %ld mlns calls per %.1f sec\n",Count,double(c2-c1)/CLK_TCK);
}
getchar();//
}
void B::f() { Var++; }
void B::vf() { }
void D::vf() { Var++; }
|
и cмотрим результаты. Написанно для командной строки, параметром — количество миллионов прогонов.
Мои результаты (для 500 mlns)
AXP 1800+
BCppB_5 BCppB_6 MSVCpp_6 MSVCpp_7
----------------------------------------------------------------------------
func 4.9 5.2 2.9 2.9
virtual 6.4 6.2 4.0 4.0
P3 800
BCppB_5 BCppB_6 MSVCpp_6 MSVCpp_7
----------------------------------------------------------------------------
func 11.2 11.4 6.0 6.0
virtual 13.2 13.5 6.1 6.1
Celeron — 1700
BCppB_5 BCppB_6 MSVCpp_6 MSVCpp_7
----------------------------------------------------------------------------
func 6.7 6.7 4.0 4.0
virtual 7.9 7.9 4.3 4.3
взяв калькулятор нетрудно подсчитать накладные расходы на вызов virtual
P.S. Вложенные функции сделанны на всякий случай, чтобы компилятор случайно не прооптимизировал
|
|
| Gedeon |
| Отправлено: 10.02.2004, 11:11 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
Не пойму, почему все до сих пор спорят Builder vs VC++ ведь появился C#, в котром и с интерфейсом все в порядке и со скоростью, кроме того и мой опыт работы, и просмотр тех же требований для современных программистов (в 80% уже хотят С#) показывает, что все движется именно в эту сторону. VC++ — с его скоростью это конечно хорошо, но с современными компами этого заметить практически невозможно, с тех пор как программирование из исскуства превратилось в производство скорость разработки приложений в большинстве случаев является определяющей, кроме того главным для программиста является то, что написать программу мало, ее нужно продать и современной скоростью разработки приложений, их разнообразием и количетвом сделайте некрасивый интерфейс даже для очень быстрой и хрошей программы — хрен ее кто купит. Т.К. способные это оценить деньги в основном платить не хотят (за редким исключением). В конечном итоге плательщиком и заказчиком остается юзер, а он некрасивого не любит.
|
|
| Asher |
| Отправлено: 19.02.2004, 18:03 |
|
Мастер участка
Группа: Модератор
Сообщений: 550
|
Привет.
Я не совсем в курсе, но C# вроде работает только через FrameWork?
P.S. Не у всех заказчиков современные компы свободно бегающие под XP или 2000. В промышленности у многих стоит железо гораздо слабее и дополнительная прослойка им — нож в ... Тут их с DOS , только тсс, Георгию не говори удалось сдвинуть на NT, а предлагать им теперь машины менять, где годами все работало — не поймут.
Это не потребительский рынок, где машина нужна помощней для игр, а все остальное заодно тоже быстро бегает.
P.P.S. Мы зачастую заложники сопровождения старых систем
|
|
| Георгий |
| Отправлено: 20.02.2004, 00:38 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
навскидку 3 категории придумал:
1. хорошо обслуживаемые высокопроизводительные системы (серверы и т.п.)
2. плохо обслуживаемые высокопроизводительные системы (домашние и офисные ПК)
3. плохо обслуживаемые низкопроизводительные системы (промышленные компьютеры, банкоматы и т.п.)
.net да и java смело используют только для 2й категории, а на остальных не верят этим "платформам" (пока не прошли они проверку временем), да и не всегда производительности даже си хватает...
такчто массы перейдут на C#, потом ещё куда-нибудь, а 1 и 3 (т.н. системные программисты) в лучшем случае только лет через 5-7 переползут на C++, да и то не для всех аппаратных платформ сейчас есть С++ компиляторы
PS. понимаю, конечно, что это форум для группы №2 но все начинают с малого
PPS. и куда тут C#, на ещё в реальном времени, присобачить? хорошо будет, если время отклика будет порядка секунд
| QUOTE | Новую плату формата PC/104 представила компания "Индустриальные компьютерные
системы" (ИКОС). Это процессорная плата ICOP-6072, продолжающая линейку устройств
PC/104 на базе процессорного модуля SoC Vortex86. PC/104 сегодня является одним
из основных стандартов для встраиваемых систем. Устройства, разработанные в этом
стандарте, отличаются низким потреблением энергии, малыми размерами, отсутствием
пассивной объединительной шины, широким температурным диапазоном. Кроме того,
широкий выбор представленных сегодня периферийных плат PC/104 открывает перед
разработчиками практически неограниченные возможности по модернизации и расширению
функциональных возможностей своих систем.
Кроме особенностей, присущих всем устройствам этого стандарта, плата ICOP-6072
имеет ряд особенностей, обусловленных наличием System-On-Chip Vortex86. Этот
процессорный модуль имеет интегрированные устройства, обеспечивающие поддержку
CRT/LCD, UDMA IDE, FDD и модулей ввода-вывода. Кроме того, Vortex86 имеет очень
низкий уровень потребления энергии и может работать без дополнительного охлаждения.
Плата ICOP-6072 работает в расширенном температурном диапазоне от -20 до +70°C.
Она может широко использоваться в торговых и информационных терминалах, в системах
удаленного контроля, промышленных компьютерных системах и для работы множества
критически важных приложений.
(фото http://www.icn.ru/i/a.nsf/u/icop-6072)
Сегодня эта плата доступна для заказа и предлагается по цене 227$. С полным техническим
описанием платы можно ознакомиться на сайте ИКОС www.ipc2U.ru в разделе "Процессорные
платы PC/104". В этом же разделе находятся описания всех моделей линейки одноплатных
компьютеров PC/104, поставляемых компанией ИКОС.
Ниже перечислены основные характеристики новой платы ICOP-6072:
- Форм-фактор PC/104
- Встроенный процессорный модуль System-On-Chip Vortex86 133МГц
- Установленная память 32Мб SDRAM
- Встроенный в System-On-Chip видеоконтроллер AGP 2x для CRT/LCD дисплеев. Использует
до 16Мб системной памяти.
- Порты ввода/вывода:
- 1 x RS-232/485, 1 x RS-232
- 1 x GPIO 12бит
- 1 параллельный порт
- 1 х FDD
- 2 x USB 1.1
- Часы реального времени с литиевой батареей
- Программируемый сторожевой таймер
- Напряжение питания: +5В@0,7А
- Размеры: 90х96мм
- Диапазон рабочих температур: -20...+70°C |
утром читаешь, что сам же написал и думаешь — какой же это бред
Отредактировано Георгий — 20/02/2004, 09:34 |
|
| Gedeon |
| Отправлено: 20.02.2004, 15:39 |
|
Ветеран
Группа: Модератор
Сообщений: 1742
|
| QUOTE (Георгий @ 20/02/2004, 01:40) | 3. плохо обслуживаемые низкопроизводительные системы (промышленные компьютеры, банкоматы и т.п.)
|
Позвольте трохи не согласиться по поводу банкоматов это если старые Diebold взять то да там еще даже больше полуоси ничего не приживается, но например Siemens WincorNixdorf 2000 и выше конфигурация — Intel PIII 800 MHz, RAM 128 MB, как бы вроде тоже ничего тут WinNT 4.0 SP6, то чего я там писал на билдере прекрасно работало, слабое место канал связи, но и то до появления радиоканала. А сейчас есть новые картометы, ICC по моему, так там уже стоят четвертые пни, вот только вопрос нахрена?
| QUOTE |
Не у всех заказчиков современные компы свободно бегающие под XP или 2000. В промышленности у многих стоит железо гораздо слабее и дополнительная прослойка им — нож в ... |
Тут я не спорю, такие люди умеют оценить, что для них сделал программист и на таких системах как правило программирование еще остается искусством, но как ни жаль эти заказчики как правило не могут заплатить как того бы хотелось.
|
|
| Георгий |
| Отправлено: 20.02.2004, 23:33 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
может действительно я зря кипячусь типа — с++ рулит, а остальное для остальных.
в ближайшем будущем контора, где работаю, будет использовать или спарки 500 мегагерцовые или via c3 400MHz, конечно о реальном времени (по крайней мере в плане гарантированного времени отклика) на C# и прочих черезчур объектных системах и речи быть не может, но использование даже этого железа для торговый терминалов и прочих систем, которые взаиможействуют с человеком и ждут его запросов, вполне возможно, более того, C# даже предпочтительнее. Ведь глядя на программистов на чистом си я ужасаюсь — пишут нормальные программы в плане функциональности и скорости, но с нулевыми показателями сопровождаемости и модернизируемости...
ладно — убедили ещё годик, другой поработаю как на промышленные АСУ (платят всётаки неплохо), а потом пойду оболочки для БД клепать. |
|
| Георгий |
| Отправлено: 22.02.2004, 15:59 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
вот я и созрел для аргументированного сравнения WC и BCB:
програмка, предложенная Asher, была чуть-чуть изменена и стала вот такой:
| CODE |
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
long Var, Count;
class B
{
public:
void f();
virtual void vf();
};
class D :public B
{
public:
void vf();
};
void f1(B* ptr)
{
ptr->f();
}
void f2(B* ptr)
{
ptr->vf();
}
int main(int argc,char** argv)
{
if (argc>1) Count=atol(argv[1]);
else Count=500;
clock_t c1,c2;
D d;
{
c1=clock();
for (long i=0; i<Count; i++)
for (long j=0; j<1000000; j++)
f1(&d);
c2=clock();
printf("f1(): %ld mlns calls per %.1f sec\n",Count,double(c2-c1)/CLK_TCK);
}
{
c1=clock();
for (long i=0; i<Count; i++)
for (long j=0; j<1000000; j++)
f2(&d);
c2=clock();
printf("f2(): %ld mlns calls per %.1f sec\n",Count,double(c2-c1)/CLK_TCK);
}
getchar();//
return 0;
}
void B::f() { Var++; }
void B::vf() { }
void D::vf() { Var++; }
|
на моём Athlon XP (thorobred-B 1900MHz=200x9.5) BCB с оптимизацией на скорость и использованием stdcall (почему то он глючит при указании register, поэтому пришлось использовать stdcall)
дал такие времена:
f1(): 500 mlns calls per 3.5 sec
f2(): 500 mlns calls per 4.6 sec
WC 11.0 под MS windows показал вот такие результаты:
f1(): 500 mlns calls per 0.6 sec
f2(): 500 mlns calls per 1.9 sec
WC 10.6 под QNX4.25:
f1(): 500 mlns calls per 0.5 sec
f2(): 500 mlns calls per 1.8 sec
как видите старичёк WC действительно силён.
компилировалось вот так:
| CODE | | wpp386 test.cpp -w4 -e25 -s -zp4 -zq -otexan -ob -ol -ol+ -om -oc -or -oe20 -fp6 -fpc -6r -bt=nt -mf |
дизассемблирование кода произведённого WC для MS:
| CODE | Module: D:\temp\test.cpp
GROUP: 'DGROUP' CONST,CONST2,_DATA,_BSS
Segment: _TEXT PARA USE32 000001A7 bytes
0000 void near f1( B near * ):
0000 FF 05 00 00 00 00 inc dword ptr long near Var
0006 C3 ret
0007 8D 80 00 00 00 00 lea eax,[eax]
000D 8D 52 00 lea edx,[edx]
Routine Size: 16 bytes, Routine Base: _TEXT + 0000
0010 void near f2( B near * ):
0010 52 push edx
0011 8B 10 mov edx,[eax]
0013 FF 12 call dword ptr [edx]
0015 5A pop edx
0016 C3 ret
0017 8D 80 00 00 00 00 lea eax,[eax]
001D 8D 52 00 lea edx,[edx]
Routine Size: 16 bytes, Routine Base: _TEXT + 0010
0020 main_:
0020 53 push ebx
0021 51 push ecx
0022 56 push esi
0023 57 push edi
0024 55 push ebp
0025 83 EC 04 sub esp,0x00000004
0028 8B 35 00 00 00 00 mov esi,long near Var
002E 83 F8 01 cmp eax,0x00000001
0031 0F 8F 19 01 00 00 jg L$8
0037 C7 05 00 00 00 00 F4 01 00 00
mov dword ptr long near Count,0x000001f4
0041 L$1:
0041 B9 04 00 00 00 mov ecx,offset void (near * const near __vftbl[])()+0x4
0046 31 DB xor ebx,ebx
0048 89 0C 24 mov [esp],ecx
004B E8 00 00 00 00 call clock_
0050 8B 2D 00 00 00 00 mov ebp,long near Count
0056 89 C7 mov edi,eax
0058 85 ED test ebp,ebp
005A 7E 21 jle L$4
005C L$2:
005C 8B 35 00 00 00 00 mov esi,long near Var
0062 31 C0 xor eax,eax
0064 L$3:
0064 40 inc eax
0065 46 inc esi
0066 3D 40 42 0F 00 cmp eax,0x000f4240
006B 7C F7 jl L$3
006D A1 00 00 00 00 mov eax,long near Count
0072 43 inc ebx
0073 89 35 00 00 00 00 mov long near Var,esi
0079 39 C3 cmp ebx,eax
007B 7C DF jl L$2
007D L$4:
007D E8 00 00 00 00 call clock_
0082 BB FC A9 F1 D2 mov ebx,0xd2f1a9fc
0087 29 F8 sub eax,edi
0089 B9 4D 62 50 3F mov ecx,0x3f50624d
008E E8 00 00 00 00 call __U4FD
0093 E8 00 00 00 00 call __FDM
0098 52 push edx
0099 50 push eax
009A 8B 15 00 00 00 00 mov edx,long near Count
00A0 52 push edx
00A1 68 00 00 00 00 push offset L$10
00A6 E8 00 00 00 00 call printf_
00AB 83 C4 10 add esp,0x00000010
00AE 31 DB xor ebx,ebx
00B0 E8 00 00 00 00 call clock_
00B5 8B 0D 00 00 00 00 mov ecx,long near Count
00BB 89 C7 mov edi,eax
00BD 85 C9 test ecx,ecx
00BF 7E 1D jle L$7
00C1 L$5:
00C1 31 D2 xor edx,edx
00C3 L$6:
00C3 8B 0C 24 mov ecx,[esp]
00C6 89 E0 mov eax,esp
00C8 42 inc edx
00C9 FF 11 call dword ptr [ecx]
00CB 81 FA 40 42 0F 00 cmp edx,0x000f4240
00D1 7C F0 jl L$6
00D3 8B 2D 00 00 00 00 mov ebp,long near Count
00D9 43 inc ebx
00DA 39 EB cmp ebx,ebp
00DC 7C E3 jl L$5
00DE L$7:
00DE E8 00 00 00 00 call clock_
00E3 BB FC A9 F1 D2 mov ebx,0xd2f1a9fc
00E8 29 F8 sub eax,edi
00EA B9 4D 62 50 3F mov ecx,0x3f50624d
00EF E8 00 00 00 00 call __U4FD
00F4 E8 00 00 00 00 call __FDM
00F9 52 push edx
00FA 50 push eax
00FB A1 00 00 00 00 mov eax,long near Count
0100 50 push eax
0101 68 23 00 00 00 push offset L$11
0106 E8 00 00 00 00 call printf_
010B 8B 15 04 00 00 00 mov edx,___iob+0x4
0111 83 C4 10 add esp,0x00000010
0114 85 D2 test edx,edx
0116 7E 4A jle L$9
0118 A1 00 00 00 00 mov eax,___iob
011D 31 D2 xor edx,edx
011F 8A 10 mov dl,[eax]
0121 83 EA 0D sub edx,0x0000000d
0124 81 FA FD 00 00 00 cmp edx,0x000000fd
012A 76 36 jbe L$9
012C 8B 0D 04 00 00 00 mov ecx,___iob+0x4
0132 40 inc eax
0133 49 dec ecx
0134 A3 00 00 00 00 mov ___iob,eax
0139 89 0D 04 00 00 00 mov ___iob+0x4,ecx
013F 8B 35 00 00 00 00 mov esi,long near Var
0145 31 C0 xor eax,eax
0147 83 C4 04 add esp,0x00000004
014A 5D pop ebp
014B 5F pop edi
014C 5E pop esi
014D 59 pop ecx
014E 5B pop ebx
014F C3 ret
0150 L$8:
0150 8B 42 04 mov eax,0x4[edx]
0153 E8 00 00 00 00 call atol_
0158 A3 00 00 00 00 mov long near Count,eax
015D E9 DF FE FF FF jmp L$1
0162 L$9:
0162 B8 00 00 00 00 mov eax,offset ___iob
0167 E8 00 00 00 00 call fgetc_
016C 8B 35 00 00 00 00 mov esi,long near Var
0172 31 C0 xor eax,eax
0174 83 C4 04 add esp,0x00000004
0177 5D pop ebp
0178 5F pop edi
0179 5E pop esi
017A 59 pop ecx
017B 5B pop ebx
017C C3 ret
017D 8D 40 00 lea eax,[eax]
Routine Size: 352 bytes, Routine Base: _TEXT + 0020
0180 void near B::f():
0180 FF 05 00 00 00 00 inc dword ptr long near Var
0186 C3 ret
0187 8D 80 00 00 00 00 lea eax,[eax]
018D 8D 52 00 lea edx,[edx]
Routine Size: 16 bytes, Routine Base: _TEXT + 0180
0190 void near B::vf():
0190 C3 ret
0191 8D 80 00 00 00 00 lea eax,[eax]
0197 8D 92 00 00 00 00 lea edx,[edx]
019D 8D 40 00 lea eax,[eax]
Routine Size: 16 bytes, Routine Base: _TEXT + 0190
01A0 void near D::vf():
01A0 FF 05 00 00 00 00 inc dword ptr long near Var
01A6 C3 ret
Routine Size: 7 bytes, Routine Base: _TEXT + 01A0
No disassembly errors
Segment: CONST BYTE USE32 00000046 bytes
0000 L$10:
0000 66 31 28 29 3A 20 25 6C 64 20 6D 6C 6E 73 20 63 f1(): %ld mlns c
0010 61 6C 6C 73 20 70 65 72 20 25 2E 31 66 20 73 65 alls per %.1f se
0020 63 0A 00 c..
0023 L$11:
0023 66 32 28 29 3A 20 25 6C 64 20 6D 6C 6E 73 20 63 f2(): %ld mlns c
0033 61 6C 6C 73 20 70 65 72 20 25 2E 31 66 20 73 65 alls per %.1f se
0043 63 0A 00 c..
Segment: _BSS DWORD USE32 00000008 bytes
0000 long near Var:
0004 long near Count:
BSS Size: 8 bytes
Comdat: void (near * const near __vftbl[])() SEGMENT ANY 'DGROUP:CONST2' 00000008 bytes
0000 void (near * const near __vftbl[])():
0000 00 00 00 00 ....
0004 00 00 00 00 DD void near D::vf()
|
как видите WC срезал углы и код
| CODE | c1=clock();
for (long i=0; i<Count; i++)
for (long j=0; j<1000000; j++) f1(&d);
c2=clock(); |
был реализован без единого вызова функций (см адреса 4B-7B) и работал с памятью только во внешнем цикле. Во внутреннем только регистры (адреса 64-6B)
с виртуальными функциями он был осторожнее — действительно вызывал функцию по указателю (адреса B0-DE)
если выигрыш по вызовам не виртуальных функций можно оспорить, то с виртуальными всё честно — функции действительно вызываются.
дизассемблированный код BCB не приводится ввиду его некрасивости и нелогичности.
это было о компиляторах, а теперь попробую вернуться к нервоначальному впросу — медленнее ли виртуальные функции. если заставить WC генерировать не оптимизированный код (с проверкой стека, передачей аргументов через стек, без заглядывания вперёд и т.п.) то времена будут такие:
f1(): 1000 mlns calls per 22.1 sec
f2(): 1000 mlns calls per 26.3 sec
и разница между прямым и косвенным вызовами всего 20%, что на первый взгляд достаточно много, но не следует забывать, что "пустые" функции, состоящии из 1 или 2х операций никто не делает и при вызове виртуальной функции, с телом в 20-50 операций, накладные расходы на вызов по указателю будут нивелированы и составят 1-2% которыми уже можно пожетрвовать. |
|
| Георгий |
| Отправлено: 24.02.2004, 19:52 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
неужели это правда???
тогда .NET рулит...
| CODE | WinCon (сокращение от Windows Controller) разработан на базе процессора Intel
Strong ARM 206МГц, традиционно используемом производителями карманных компьютеров
(КПК). Впервые в не PC-совместимый контроллер была встроена система программирования
контроллеров Микро TRACE MODE. Это стало возможным, благодаря применению в контроллере
операционной системы Windows CE.NET. Появление Микро TRACE MODE под Windows CE.NET
является знаковым событием, так как открывает дорогу к тиражированию решений
на базе интегрированной SCADA/HMI и Softlogic системы TRACE MODE применительно
к любым аппаратным платформам, поддерживающим данную операционную систему. По
сравнению с другими операционными системами, Windows CE.NET имеет целый ряд преимуществ:
- операционная система жесткого реального времени;
- малый размер ядра;
- высокая скорость загрузки;
- встроенная сеть TCP/IP;
- развитый графический интерфейс и низкая стоимость;
|
|
|
|
