Здравствуйте, OdesitVadim, Вы писали:
OV>[!] Для компиляции FAR Manager использовался Borland C/C++ 5.02. MSVC 6 SP4 OV> не оправдал ожиданий (FAR 1.70 beta 1) и добавил тормозов (работа с OV> выделением памяти для мелкими объектов). OV>[/q]
Здравствуйте, WiseAlex, Вы писали:
SI>>может и не в тему, но подобные проблемы замечал, кажется, Александреску в своем Modern C++ design — в разделе, посвященному SmallObjectsAllocator. Уверен на 99,9% что ваши тормоза связаны с выделением памяти, советую испробовать аллокатор от Александреску (он входит в состав библиотеки Loki). Уверен, разберешься как использовать его со строками, веторами и прочей красотой от STL WA>как вариант плавного перехода можно попробовать VC + stlport WA>AFAIK в stlport есть оптимизация для мелких объектов WA>кстати может стоит использовать VC7.1 (компиляция быстрее и оптимизация на уровне)
У меня, как это говорится, на STLPort "не стоит". Я с ним поигрался в свое время (на билдере) и охладел. Мне от STL нужен только минимум — навороты у меня в собственной плюсовой библиотеке. Так сложилось.
Ладно фиг с ним. Но я вот что думаю. BCB5 компилирует раза в три быстрее VC8 (в два — точно). Родной RW-STL, получается, тоже достаточно эффективен. И все это дело датируется 2000 годом. Но народ упорно, с пеной у рта доказывал, что BCB — тормоз
PS. Я с компиляторами борланда более чем на ты. После всего того, что я с ними делал, остается только жениться
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[2]: Производительность и смешивание компиляторов
Здравствуйте, OdesitVadim, Вы писали:
OV>Здравствуйте, Коваленко Дмитрий: OV>Почитайте на сайте FAR, почему они отказались от майкрософтовского компилятора и остались на борландовском
AFAIK они сейчас его VC 7.1 собирают...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: Производительность и смешивание компиляторов
Здравствуйте, Smal, Вы писали:
S>Здравствуйте, OdesitVadim, Вы писали:
OV>>Здравствуйте, Коваленко Дмитрий: OV>>Почитайте на сайте FAR, почему они отказались от майкрософтовского компилятора и остались на борландовском S>Можно ссылку? http://pravoznavec.com.ua/rules.html
Основное
~~~~~~~~
[!] Для компиляции FAR Manager использовался Borland C/C++ 5.02. MSVC 6 SP4
не оправдал ожиданий (FAR 1.70 beta 1) и добавил тормозов (работа с
выделением памяти для мелкими объектов).
КД>PS. Профайлера у меня нет, так что даже и не предлагайте
А всё-таки предложу, хотя бы http://www.codersnotes.com/sleepy/
хотя бы одним глазком взглянуть всё равно полезно.
Re[5]: Производительность и смешивание компиляторов
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, OdesitVadim, Вы писали: R>>MSVC 6 SP4 немного отличается от MSVC 8 SP1
FR>Угу только тромозить на выделении мелких объектов не перстал
Давайте разберемся. Принцип работы борландовского менеджера памяти — сразу стребовать от системы здоровенный кусок памяти, а потом уже по запросам из кода отрезать каждому инстансу по чутка. Когда этот лапоть заканчивается, будет стребован еще один здоровый кусок. Минус — излишние пожирания памати процессом (на что всегда тыкают апологеты MS VS), но плюс — это высокая скорость инстанциирования объектов на куче. MS VS идет другим путем, и в этом тоже есть здравое зерно. Просто забота о выборе подходящего аллокатора переходит на программиста. Да, типовой аллокатор MS VS будет тормозить на выделении памяти под мелкие объекты, особенно на многопоточных проектах. Но с другой стороны, не нравится — пользуйте кастомный аллокатор. Ибо нарисовать системный сервис а-ля hello world, который по дефолту сожрет под себя мегабайт эдак десять-двадцать рабочей памяти "так просто, на будущее" — приятного мало.
Тема сообщения, конечно, немного сумбурная, но лучше сформулировать не смог
Ситуация такая.
Есть большой программный комплекс, состоящий из множества COM-модулей. Изначально все компилировалось на BCB5 (практически без оптимизации). В течении многих лет комплекс шлифовался во всех направлениях. Производительность была более менее приемлемая. Тут, в свете увядания любви к BCB, пересобрали модуль с сервисными COM-объектами на VC8 (speed-оптимизация по максимуму). Объекты из этого модуля юзаются практически повсеместно.
Ну дык вот. Производительность упала на глазах — раз в пять. Видно прямо при перерисовке окон (сделаны на BCB5) — отображаемые данные тащатся из объектов, обcлуживаются именно этим сервисным модулем, откомпилированным на VC8. Если этот модуль заново пересобрать на BCB5 — все нормально.
Модуль c GUI (собран на BCB5) компилируется со статической библиотекой.
Сервисный модуль всегда компилировался с использованием динамической библиотекой — сс3250mt.dll (BCB5) и MSVCP80.dll,MSVCR80.dll (VC8).
То есть, каждый модуль всегда жил со своей собственной кучей.
Я вот чего думаю. BCB5 юзает RW-STL, а VC8 — другую STL. Сдается мне главное различие в том, что в RW-STL basic_string юзает счетчики ссылок, а VC8-STL всегда копирует строки. В результате получается ахтунг.
С удовольствием выслушаю другие гипотезы о причинах такого резкого снижения производительности.
PS. Профайлера у меня нет, так что даже и не предлагайте
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Ну дык вот. Производительность упала на глазах — раз в пять. Видно прямо при перерисовке окон (сделаны на BCB5) — отображаемые данные тащатся из объектов, обcлуживаются именно этим сервисным модулем, откомпилированным на VC8. Если этот модуль заново пересобрать на BCB5 — все нормально.
Здравствуйте, OdesitVadim, Вы писали:
OV>Здравствуйте, Коваленко Дмитрий: OV>Почитайте на сайте FAR, почему они отказались от майкрософтовского компилятора и остались на борландовском
Можно ссылку?
С уважением, Александр
Re[2]: Производительность и смешивание компиляторов
Здравствуйте, Smal, Вы писали:
КД>>Ну дык вот. Производительность упала на глазах — раз в пять. Видно прямо при перерисовке окон (сделаны на BCB5) — отображаемые данные тащатся из объектов, обcлуживаются именно этим сервисным модулем, откомпилированным на VC8. Если этот модуль заново пересобрать на BCB5 — все нормально.
S>Надеюсь в восьмерке Вы clr с корнями отключили?
Не, ну я же не первый год замужем
Конечно же, я достаточно внимательно просмотрел все используемые опции компилятора.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[4]: Производительность и смешивание компиляторов
OV>Основное
OV>~~~~~~~~
OV>[!] Для компиляции FAR Manager использовался Borland C/C++ 5.02. MSVC 6 SP4
OV> не оправдал ожиданий (FAR 1.70 beta 1) и добавил тормозов (работа с
OV> выделением памяти для мелкими объектов).
Между нами, девочками — Borland C/C++ 5.x это ТАКОЕ Г (и компилятор, и библиотека), что страшно даже вспоминать. "Мечта" сапера, одним словом.
Единственное что там было реально классно сделано — менеджер проектов. До сих пор, как вспоминаю, так утираю скупую, девичью слезу
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[5]: Производительность и смешивание компиляторов
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Между нами, девочками — Borland C/C++ 5.x это ТАКОЕ Г (и компилятор, и библиотека), что страшно даже вспоминать. "Мечта" сапера, одним словом.
Мне в нём одно нравилось — примеры по С++ от Керигана, Страуструпа и прочих больших людей в нем запускались с полнинка. А причина в том, что он добавлял using namespace std; по умолчанию (тоесть просто знал о этом пространстве имён и не ругался, если я напишу просто cin или cout). А большие мира программирование почему то тоже не писали этой заветной строки. Толи книги у меня древние, толи они не тем компилятором пользовались, либо полагались , что простой новичёк сразу покурит стандарт и поймёт, почему hello world не компилиться. КД>Единственное что там было реально классно сделано — менеджер проектов. До сих пор, как вспоминаю, так утираю скупую, девичью слезу
Я только компилятором пользовался. А саму оболочку только на картинках видел...
... << RSDN@Home 1.2.0 alpha rev. 727>>
Re[3]: Производительность и смешивание компиляторов
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, OdesitVadim, Вы писали:
OV>>Здравствуйте, Коваленко Дмитрий: OV>>Почитайте на сайте FAR, почему они отказались от майкрософтовского компилятора и остались на борландовском CC>AFAIK они сейчас его VC 7.1 собирают...
Да, проверил последний билд — действительно VC7. Хотя многие плагины остались на борландовском компиляторе собраны. Удобство за счёт мегагерц. (С) — не мой
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Привет всем.
КД>...
может и не в тему, но подобные проблемы замечал, кажется, Александреску в своем Modern C++ design — в разделе, посвященному SmallObjectsAllocator. Уверен на 99,9% что ваши тормоза связаны с выделением памяти, советую испробовать аллокатор от Александреску (он входит в состав библиотеки Loki). Уверен, разберешься как использовать его со строками, веторами и прочей красотой от STL
Re[5]: Производительность и смешивание компиляторов
Здравствуйте, remark, Вы писали:
R>Здравствуйте, OdesitVadim, Вы писали:
OV>>[!] Для компиляции FAR Manager использовался Borland C/C++ 5.02. MSVC 6 SP4 OV>> не оправдал ожиданий (FAR 1.70 beta 1) и добавил тормозов (работа с OV>> выделением памяти для мелкими объектов). OV>>[/q]
R>MSVC 6 SP4 немного отличается от MSVC 8 SP1
Угу только тромозить на выделении мелких объектов не перстал
Re[2]: Производительность и смешивание компиляторов
Здравствуйте, StevenIvanov, Вы писали:
SI>может и не в тему, но подобные проблемы замечал, кажется, Александреску в своем Modern C++ design — в разделе, посвященному SmallObjectsAllocator. Уверен на 99,9% что ваши тормоза связаны с выделением памяти, советую испробовать аллокатор от Александреску (он входит в состав библиотеки Loki). Уверен, разберешься как использовать его со строками, веторами и прочей красотой от STL
как вариант плавного перехода можно попробовать VC + stlport
AFAIK в stlport есть оптимизация для мелких объектов
кстати может стоит использовать VC7.1 (компиляция быстрее и оптимизация на уровне)
Re[2]: Производительность и смешивание компиляторов
Здравствуйте, voronaam, Вы писали:
КД>>PS. Профайлера у меня нет, так что даже и не предлагайте V>А всё-таки предложу, хотя бы V>http://www.codersnotes.com/sleepy/ V>хотя бы одним глазком взглянуть всё равно полезно.
На 2000 не работает — не найдена какая-та функция (я прям как глупый юзер, сразу нажал OK и немедленно деинсталлировал , ставить заново — лень ).
Дома попробую на XP
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[3]: Производительность и смешивание компиляторов
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, voronaam, Вы писали:
КД>>>PS. Профайлера у меня нет, так что даже и не предлагайте V>>А всё-таки предложу, хотя бы V>>http://www.codersnotes.com/sleepy/ V>>хотя бы одним глазком взглянуть всё равно полезно.
КД>На 2000 не работает — не найдена какая-та функция (я прям как глупый юзер, сразу нажал OK и немедленно деинсталлировал , ставить заново — лень ).
КД>Дома попробую на XP
А у меня на XP всё время выдаёт в какой-то функции ядра, хотя программа работает и проц периодически подгружает на 100%...
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Ладно фиг с ним. Но я вот что думаю. BCB5 компилирует раза в три быстрее VC8 (в два — точно). Родной RW-STL, получается, тоже достаточно эффективен. И все это дело датируется 2000 годом. Но народ упорно, с пеной у рта доказывал, что BCB — тормоз
А ты BDS какой ни будь попробуй запустить по сравнению с ними VC8 летает
Re[5]: Производительность и смешивание компиляторов
Здравствуйте, FR, Вы писали:
КД>>Ладно фиг с ним. Но я вот что думаю. BCB5 компилирует раза в три быстрее VC8 (в два — точно). Родной RW-STL, получается, тоже достаточно эффективен. И все это дело датируется 2000 годом. Но народ упорно, с пеной у рта доказывал, что BCB — тормоз
FR>А ты BDS какой ни будь попробуй запустить по сравнению с ними VC8 летает
Давайте не будем путать компилятор и IDE. BDS (2006) я ... мучал год назад
Здравствуйте, Коваленко Дмитрий, Вы писали:
FR>>А ты BDS какой ни будь попробуй запустить по сравнению с ними VC8 летает
КД>Давайте не будем путать компилятор и IDE. BDS (2006) я ... мучал год назад
Здравствуйте, ArtDenis, Вы писали:
КД>>С удовольствием выслушаю другие гипотезы о причинах такого резкого снижения производительности.
AD>Могу предположить, что дело в какой-то глупой ошибке, которая не проявляет себя при компиляции в BCB
Смешно
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[3]: Производительность и смешивание компиляторов
Здравствуйте, ArtDenis, Вы писали:
AD>>Могу предположить, что дело в какой-то глупой ошибке, которая не прояляет себя при компиляции в BCB
AD>Кстати, надеюсь запускается именно релиз и не из под IDE?
Ржунемогу
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[4]: Производительность и смешивание компиляторов
Всё-таки похоже на память и сторки...
У меня был наобототный случай, когда я в большой проект на дельфи вставил FastMM — всё залетало.
У Borland-а вроде как куча всё равно единая могла быть — borlandMM.
Тогда просадка вполне обоснованная.
Я бы посоветывал таки пройтись профилятором VTune или AQTime.
Оба понимают отладочную инфу и от MS, и от Borland-а.
Тока для Borland-а надо указать чтобы файлом сгенерил.
Ну и всякие мелочи посмотреть, типа строковые параметры/возвраты как передаються/передавались сравнить...
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Привет всем.
КД>Тема сообщения, конечно, немного сумбурная, но лучше сформулировать не смог
КД>Ситуация такая.
КД>Есть большой программный комплекс, состоящий из множества COM-модулей. Изначально все компилировалось на BCB5 (практически без оптимизации). В течении многих лет комплекс шлифовался во всех направлениях. Производительность была более менее приемлемая. Тут, в свете увядания любви к BCB, пересобрали модуль с сервисными COM-объектами на VC8 (speed-оптимизация по максимуму). Объекты из этого модуля юзаются практически повсеместно.
КД>Ну дык вот. Производительность упала на глазах — раз в пять. Видно прямо при перерисовке окон (сделаны на BCB5) — отображаемые данные тащатся из объектов, обcлуживаются именно этим сервисным модулем, откомпилированным на VC8. Если этот модуль заново пересобрать на BCB5 — все нормально.
КД>Модуль c GUI (собран на BCB5) компилируется со статической библиотекой. КД>Сервисный модуль всегда компилировался с использованием динамической библиотекой — сс3250mt.dll (BCB5) и MSVCP80.dll,MSVCR80.dll (VC8).
КД>То есть, каждый модуль всегда жил со своей собственной кучей.
КД>Я вот чего думаю. BCB5 юзает RW-STL, а VC8 — другую STL. Сдается мне главное различие в том, что в RW-STL basic_string юзает счетчики ссылок, а VC8-STL всегда копирует строки. В результате получается ахтунг.
КД>С удовольствием выслушаю другие гипотезы о причинах такого резкого снижения производительности.
КД>PS. Профайлера у меня нет, так что даже и не предлагайте
Я может чего и невкурил, но здается мне что проблема не в опциях копилятора, а в апартаментах. Если COM-объект собран
как... блин забыл как называется, уже два года не занимался этим, типа как однопоточный. Короче точно проблема была
когда один Borland-ский компонент вызывал visual-ский то вызов шел через proxy-stub, со всеми от сюда вытекающими последствиями
(несмотря на то, что они находились в одном апартаменты). При связки visual-visual или borland-borland таких проблем
не возникает, т.к. вызовы идут напрямую. Соответственно программа ниписанная на bc юзающая vc-компоненты работает через
прокси — отсюда и падение производительности
Re[2]: Производительность и смешивание компиляторов
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, s_viy, Вы писали:
КЛ>[]
КЛ>Апартмент все-лишь определяется ключиком ThreadingModel у соответствующего CLSID. Как это может зависеть от сборки — не знаю.
Единственное, что bcc может для STA объектов считать ссылки через InterlockedXXX. Но это может быть сильно заметно только на мультипроцессорных системах.
Re[4]: Производительность и смешивание компиляторов
Здравствуйте, Константин Л., Вы писали:
КЛ>>Апартмент все-лишь определяется ключиком ThreadingModel у соответствующего CLSID. Как это может зависеть от сборки — не знаю.
КЛ>Единственное, что bcc может для STA объектов считать ссылки через InterlockedXXX. Но это может быть сильно заметно только на мультипроцессорных системах.
BCC вообще ничего не считает. Для работы со счетчиками ссылок я дейстивительно использую InterlockedXXX. Всегда.
Не замечал, чтобы это как-то влияло на производительность многопроцессорной машины Зато сплю спокойно.
Вот когда используются мьютексы вместо CS — это да. Оно и на однопроцессорной машине с однопоточной программой заметно
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[6]: Производительность и смешивание компиляторов
Здравствуйте, Константин Л., Вы писали:
КД>>Не замечал, чтобы это как-то влияло на производительность многопроцессорной машины Зато сплю спокойно.
КЛ>дык, синхронизация кешей каждого из ядер
Спасибо. Будем думать
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[3]: Производительность и смешивание компиляторов
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Здравствуйте, s_viy, Вы писали:
_>>Я может чего и невкурил, но здается мне что проблема не в опциях копилятора, а в апартаментах....
КД>Умоляю. У меня такой "страсти-ужасти" точно нет
КД>Компоненты (и интерфейсы) все мои, все в одном процессе, проксей нет, вызовы идут не через IDispatch, а напрямую.
А ты как в bc импортируешь? В bcb обычно их импортируют через среду, а не создают вручную — среда сама генерит прокси
и вызовы идут через нее. ты в дебаге смотрел пошагово как вызовов идет?
Re[4]: Производительность и смешивание компиляторов
Здравствуйте, s_viy, Вы писали:
КД>>Компоненты (и интерфейсы) все мои, все в одном процессе, проксей нет, вызовы идут не через IDispatch, а напрямую.
_>А ты как в bc импортируешь? В bcb обычно их импортируют через среду, а не создают вручную — среда сама генерит прокси _>и вызовы идут через нее.
Под проксей я понимал натуральные комовские proxy (компилируемый из файлов генерируемых midl.exe)
Работа с компонентами (точнее с их интерфейсами) ясный пень идет через обертки. Обертки всегда писал сам. Так сложилось. Если интересно, как это выглядит, то скачивай дистрибутив провайдера и посмотри файлы в каталоге lib/Components/ScriptControl.
Кстати, COM-объекты я пишу также на базе своей библиотеки. Без использования ATL. Опять же исторические причины.
Интерфейсы, аналогично, описываются руками и явно компилируются midl-ом.
Короче — "все сам, все сам, своими руками"
> ты в дебаге смотрел пошагово как вызовов идет?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>PS. Профайлера у меня нет, так что даже и не предлагайте
Прекратить гадать на кофейной гуще, а взять профайлер. Я конечно понимаю, что тот, кто без доп инструментов силой мысли найдет причину, достоин не то что уважения, а памятника, но... возьмите ж вы профайлер.
Зато сплю спокойно.
