AAV>А если честно, то считаю, что каждый язык достоин той ниши, где он расположен. Быстрые разработки — delphi,
не-а, VS2005 и IDEA — самые скоростные сейчас.
>надежность — Framework,
да. .NET и Java
>монументальность — Java,
добавь и дотнет
>быстрота работы — C++.
где? на какой аппаратной платформе?
подробную спецификацию плз...
и вообще, я бы в контексте данного разговора не стал бы разделять .NET и Java. считаю. что их тут нужно вместе рассматривать.
П.С, делфи для своего времени была классная технология. Но, в нынешних реалиях — ей совершенно нечего противопоставить .NET + Java. Развитие некогда очень хорошей технологии, к сожалению, полностью остановилось.
Только потому, что Anchors не используешь, попробуй тока начать сайзить контролы на WM_SIZE — сразу все поймешь
Много раз сайзил на WM_SIZE (однажды даже около 20 штук) и все равно ничего не моргает!
А что такое Anchors?
На обед пойду, если не забуду скину линк на статью,где ассемблерщик сравнивает компиляторы, там Borland C++ всех натягивает, правда ассемблерщик говорит, что он все-таки ненадежен, но найдите мне прогу, которая чисто из-за ненадежности компилятора постоянно падает.
Примерно такой ответ я и ожидал увидеть.
Знаешь, гдето здесь обитает любитель оберона, так вот у него он тоже всех натягивает.
Но он по крайней мере прекрасно осознает, что именно он защищает и на все смотрит со своей позиции.
Самое страшное когда у человека нет собственного мнения потому что он не в состоянии сам сравнить
и вынужден приводить доводы типа: "Мне Васька сказал, что Петька круче всех во дворе."
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, ShibaON, Вы писали:
SON>>Вот, как и обещал: Сравнительный анализ компиляторов С++ >>> Intel C++ Compiler 4.5 CC>Он еще древнее найти не мог? CC>Я к тому времени на 7-м сидел.
особенно умиляет год создания статьи 2004 г
SON>Теперь, что я думаю про Delphi: Delphi это результат многолетних трудов Borland, которая работает всю свою жизнь над компиляторами (в отличие от Майкрософт, которая написала компилатор, только для поддержания своего престижа).
Причем не один компилятор . Наверное что бы престижа больше было .
SON>И компилатор, например С, думаю меня тут поддержат все профессионалы, у Borland гораздо лучше чем у Microsoft.
Уж тут тебя врятли кто-то поддержит.
SON>Теперь сравним VCL с .NET Framework: VCL лет-то уже порядочно, он давно утвердился, а фреймворк — вещь молодая, кто ещё знает что с ней будет. C VCL — плюс 300-800 кб. к вашей проге. Фреймворк — 48 метров к вашему дистрибутиву (притензии типа: "раз установил и все" не принимаются, в VCL тоже так можно: максимум 16 метров в сжатом виде).
Здравствуйте, cod3r_200, Вы писали:
_>ненавижу всё что связано с delphi, она тормозная глючная, ужасная для средних и больших проектов. Нет никакого желания на ней писать. Нелюблю все проги которые на ней написаны. Аффтары застрелитесь с дельфей, делайте качественное, быстрое ПО. Я никогда не купил бы прогу, которая написана на дельфе, как бы хорошо она ни была написана. _>Незнаю что там с фреймворком, но он тоже не идеален. Да и вообще всё какое-то через задницу
Среды разработки Delphi и C++ Builder, насколько известно автору, не "доверяют" стандартным функциям управления кучей и реализовали свои. Здесь алгоритм другой: куча делится на несколько подкуч, каждая из которых предназначена для выделения блоков строго фиксированного размера: к примеру, одна предназначена для выделения 4-байтных блоков, вторая — 8-байтных, 3-я — для 16-байтных, и т. д. Такой подход имеет как минимум два преимущества. Во-первых, не нужно создавать дерево свободной памяти — достаточен простой список, так как нет необходимости в поиске свободного блока и можно взять просто первый попавшийся элемент списка (вспомним, что элементы фиксированного размера). Во-вторых, фрагментация практически отсутствует (по крайней мере, вероятность в какой-то момент получить отказ в выделении блока нужного размера резко снижается). Я уже не говорю о том, что в дефрагментации отпадает необходимость.
Алгоритм, примененный в Delphi и C++ Builder, оказался удачным, и его внедрили в последние версии операционной системы Windows под названием LFH (low-fragmentation heap). Теперь программист имеет возможность пользоваться как стандартной кучей, так и кучей с пониженной фрагментацией.
Здравствуйте, unreg_flex, Вы писали:
_>Много раз сайзил на WM_SIZE (однажды даже около 20 штук) и все равно ничего не моргает! _>А что такое Anchors?
А я раз разместил в окне GroupBox, над ним (сам он не может быть парентом) разместил несколько эдитов и чекбокс, всем поставил WS_CLIPSIBLING, и пипец что было .
Ценители Фреймворка знают, что такое Anchors,тоже что и Anchors в VCL.
_>Примерно такой ответ я и ожидал увидеть. _>Знаешь, гдето здесь обитает любитель оберона, так вот у него он тоже всех натягивает. _>Но он по крайней мере прекрасно осознает, что именно он защищает и на все смотрит со своей позиции. _>Самое страшное когда у человека нет собственного мнения потому что он не в состоянии сам сравнить _>и вынужден приводить доводы типа: "Мне Васька сказал, что Петька круче всех во дворе."
Я и пытаюсь сам сказать, что Delphi — это не отстой, что с помощье него можно неплохо зарабатывать, но мне наслово , почему-то никто не верит, а самому брать дизассамблер и делать тесты — у меня времени нет, да и зачем мне это нужно, меня-то ведь все устраивает. Здесь я не собираюсь навязывать свое мнение, здесь я просто им делюсь с остальными, внимательно выслушивая других. А что касается моего, конкретно, мнения про все это дело, то я за тот небольшой промежуток времени, с которого здесь зарегился, уже несколько раз высказал свое мнение "обо всем об этом": Для каждой задачи свой инструмент. Гаму, например на D3D на Delphi только пароноик писать начнет, зато небольшую офисную прогу на Delphi я сделаю гораздо быстрее, чем на MFC, но такого удовольствия, как от C++ я не получу никокда ни от какого языка программирования. И споры между кодерами на Delphi и С++ напоминают мне студенческие годы. Давайте просто говорить о достоинствах и недостатках, а не о том, что Delphi — это шит (если это шит, почему его тогда покупают, кучу книг о нем пишут?). Нет ничего идеального, правда нет, тут-то я точно сам все проверил и сравнил и идеального не нашел!
Я ни разу не сталкивался с багами компилеров Borland's. Ни разу! Где они? Покажите мне их? Некорректная работа на всяких там {{{{{{{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}}}} — это не довод!
Здравствуйте, _wah, Вы писали:
_>Здравствуйте, CreatorCray, Вы писали:
CC>>Здравствуйте, ShibaON, Вы писали:
SON>>>Вот, как и обещал: Сравнительный анализ компиляторов С++ >>>> Intel C++ Compiler 4.5 CC>>Он еще древнее найти не мог? CC>>Я к тому времени на 7-м сидел. _> особенно умиляет год создания статьи 2004 г
Для слепых выделено ЖИРНЫМ
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
M>Алгоритм, примененный в Delphi и C++ Builder, оказался удачным, и его внедрили в последние версии операционной системы Windows под названием LFH (low-fragmentation heap). Теперь программист имеет возможность пользоваться как стандартной кучей, так и кучей с пониженной фрагментацией.
Пользовался LFH. Для multithreaded проги-сервера оказалось монопенисуально.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Вот не хотелось ведь флеймить, но видимо придется!
Это анализ компиляторов?
Хотелось бы понять, а что собственно он анализировал?
Провести тестирование некоторых конструкций (например, обращение к полю объекта) не удастся из-за оптимизации на уровне компилятора: строки типа for (unsigned i=0;i<10000000;i++) dummy = obj->dummyField; все компиляторы просто выбросили из конечного бинарного кода.
Какая досада! Двумерное преобразование фурье изображения врядли бы кто нибудь выбросил.
Наличие такой нетривиальной низкоуровневой оптимизации наводит на мысль о необходимости анализа сгенерированного кода на уровне ассемблера.
Навело на мысль во время написания статьи, ибо именно в это время автор об этом узнал!
Кроме того, для Borland Builder была добавлена опция --fast-call — передача параметров через регистры (Intel Compiler, MSVC++ и gcc автоматически используют передачу параметров через регистры при использовании оптимизации по скорости).
Бред.
fastcall использует только ecx и edx, остальное через стек.
MSVC++ не использует fastcall ни при каких настройках, только если указать явно.
Тестирование было разделено на несколько независимых частей. Первая — тестирование скорости работы основных конструкций языка (виртуальные вызовы, прямые вызовы и т.д.). Вторая — тестирование скорости работы STL. Третья — тестирование менеджера памяти, поставляемого вместе с компилятором. Четвертая — разбор ассемблерного кода таких базовых операций, как вызов функции и построения цикла. Пятая — сравнение времени компиляции и размера выполняемого файла.
Особенно интересно тестирование прямых вызовов!
И как же это разные компиляторы умудряются делать их по разному
Разные компиляторы поставляются с разными версиями STL. Поэтому глупо их сравнивать.
Менеджер памяти в итоге у всех один: Win32 heap manager.
При выделении блоков размер которых варьируется в диапазоне от 16b до 16mb все работают одинаково.
А если по байтику выделять и освобождать, то результаты действительно будут разными, однако на практике это не выполняется.
И еще, здесь компиляторы сравниваются или эвристики malloc()?
Как видно, MSVC++ инвертировал цикл и for (unsigned i=0;i<16;i++) у него превратился в unsigned i=16;while (i--);, что очень правильно с точки зрения оптимизации — мы экономим на одной операции сравнения (см. следующий листинг)
Современным процессорам плевать на эту операцию сравнения, поскольку она спаривается,
а вот проход по памяти в обратном порядке может привести к большим задержкам.
VC7 и 8 по возможности разворачивают как раз наоборот в прямой порядок, даже если написать в обратном.
И еще некоторые вопросы:
Где исходные коды всех примеров?
Где тестирование на десятке различных алгоритмов (элиминатор Жордана, сортировки, поиск и тп)?
Где тестирование свертки подвыражений?
Где анализ предсказаний переходов?
Где оптимизация ветвлений?
Где рассмотрение специфических инструкций современных процессоров (SSE,SSE2)? Ах да! в билдере их нет.
Где разбор каждого примера и кода полученного каждым компилятором?
В общем автор разбирается в оптимизации и процессорах, как свинья в апельсинах.
Прочитал пару книжек (типа Юрова), и относится к тем кто с пеной у рта спорят
что быстрее работает rep stosd или rep stosw.
Казалось бы, вывод о самом эффективном компиляторе напрашивается сам собой — это Borland Builder C++.
Интересно, а ты читал с пониманием, или сразу перешел на эту строчку?
Здравствуйте, _wah, Вы писали:
_>Здравствуйте, ArhAngelVezel, Вы писали:
_>не-а, VS2005 и IDEA — самые скоростные сейчас.
ну не надо говорить о среде. Придержимся того что _стиль_ написания delphi приложений гораздо более подходит под стиль написания "надо было сделать еще вчера". Хотя, у меня знакомые пишут достаточно прогрессивные системы на delphi не используя VCL совсем. Ну любят люди Pascal, что сделать .
>>быстрота работы — C++. _>где? на какой аппаратной платформе? подробную спецификацию плз...
На любой. Не будем наивными и примим за факт что машина не может думать лучше людей (с творческой стороны). Если же как ни раз доказывалось написать хорошо на Basic и используя кривые руки написать на асме то тут можно тоже сравнивать скорости.
_>и вообще, я бы в контексте данного разговора не стал бы разделять .NET и Java. считаю. что их тут нужно вместе рассматривать.
А может не надо?. .Net более прогрессивние Java, ибо стандартных компонент в нем больше и не надо часами выбирать из GNU компонентов сторонних разработчиков (imho+Windows).
Здравствуйте, CreatorCray, Вы писали:
SON>>>>Вот, как и обещал: Сравнительный анализ компиляторов С++ >>>>> Intel C++ Compiler 4.5 CC>>>Он еще древнее найти не мог? CC>>>Я к тому времени на 7-м сидел. _>> особенно умиляет год создания статьи 2004 г CC>Для слепых выделено ЖИРНЫМ
Не хочу повторятся, но: А что у Intel C++ Compiler так координально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
Здравствуйте, ShibaON, Вы писали:
SON>Не хочу повторятся, но: А что у Intel C++ Compiler так кардинально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
Для того, чтобы капитально изменить кодогенератор не нужно переписывать весь компилер с нуля. Я начал пользоваться ICC с пятой версии и .pfk 5-7-8-9 версии. И могу уверенно сказать что качество генерируемого им кода улучшилось с тех пор в разы. Кроме того с тех пор (с 5-й версии) появилось дофига чего из процов — соотвественно менялся кодогенератор для ориентации на максимальную производительность кода для последних архитектур и т.п.
Если тебе хочется детальный changelist — вперед на intel.com
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>Здравствуйте, _wah, Вы писали:
_>>Здравствуйте, ArhAngelVezel, Вы писали:
_>>не-а, VS2005 и IDEA — самые скоростные сейчас. AAV>ну не надо говорить о среде. Придержимся того что _стиль_ написания delphi приложений гораздо более подходит под стиль написания "надо было сделать еще вчера". Хотя, у меня знакомые пишут достаточно прогрессивные системы на delphi не используя VCL совсем. Ну любят люди Pascal, что сделать .
Можно конкретные факты, что приложения на делфи писать быстрее, чем на дотнете (2.0, т.к. 1.1. уже становится практически неактуальным, большинство новых проектов начинают на второй версии) или джаве?
или это очередное мнение очередного фаната делфи?
Не хочу повторятся, но: А что у Intel C++ Compiler так координально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
Очень хочется влезть!
Генерация машинного кода на основе потоковых команд (векторизация циклов)
Поддержка новых расширений Intel-овских процессоров SSE2 SSE3.
Оптимизация под несколько процессоров, с возможностью динамического выбора на стадии выполнения.
Оптимизация под конкретные модели процессоров Up to P4
Отложенная кодогенерация на стадии сборки.
Эмулятор компилируемого кода, для расчета вероятностей выполнения переходов и узких мест на стадии компиляции. (мегафича)
Упрощение выражений, такого не видел нигде! Например sin(x)/cos(x) заменяются на tan(x)
Здравствуйте, ArhAngelVezel, Вы писали:
AAV>На любой. Не будем наивными и примим за факт что машина не может думать лучше людей (с творческой стороны). ....
Здравствуйте, unreg_flex, Вы писали:
_>Здравствуйте, ShibaON, Вы писали:
_>
_>Не хочу повторятся, но: А что у Intel C++ Compiler так координально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
_>Очень хочется влезть! _>Генерация машинного кода на основе потоковых команд (векторизация циклов) _>Поддержка новых расширений Intel-овских процессоров SSE2 SSE3. _>Оптимизация под несколько процессоров, с возможностью динамического выбора на стадии выполнения. _>Оптимизация под конкретные модели процессоров Up to P4 _>Отложенная кодогенерация на стадии сборки. _>Эмулятор компилируемого кода, для расчета вероятностей выполнения переходов и узких мест на стадии компиляции. (мегафича) _>Упрощение выражений, такого не видел нигде! Например sin(x)/cos(x) заменяются на tan(x)
Рад. А все ли это будет сказываться на моем AMD, а то меня правда заинтересовал ICC.
Здравствуйте, ShibaON, Вы писали:
SON>Здравствуйте, unreg_flex, Вы писали:
_>>Здравствуйте, ShibaON, Вы писали:
_>>
_>>Не хочу повторятся, но: А что у Intel C++ Compiler так координально изменилось? Разве его от версии к версии переписывали с нуля?. Это не риторический вопрос, это просто вопрос.
_>>Очень хочется влезть! _>>Генерация машинного кода на основе потоковых команд (векторизация циклов) _>>Поддержка новых расширений Intel-овских процессоров SSE2 SSE3. _>>Оптимизация под несколько процессоров, с возможностью динамического выбора на стадии выполнения. _>>Оптимизация под конкретные модели процессоров Up to P4 _>>Отложенная кодогенерация на стадии сборки. _>>Эмулятор компилируемого кода, для расчета вероятностей выполнения переходов и узких мест на стадии компиляции. (мегафича) _>>Упрощение выражений, такого не видел нигде! Например sin(x)/cos(x) заменяются на tan(x)
SON>Рад. А все ли это будет сказываться на моем AMD, а то меня правда заинтересовал ICC.
На любом AMD все кроме SSE, SSE2 и SSE3.
SSE Начиная c AMD AtlonXP
SSE2 На следующих прикрутили.
Здравствуйте, ShibaON, Вы писали:
SON>Рад. А все ли это будет сказываться на моем AMD, а то меня правда заинтересовал ICC.
Ну, если у тя не самый древний АМД то:
_>>Генерация машинного кода на основе потоковых команд (векторизация циклов)
будет _>>Поддержка новых расширений Intel-овских процессоров SSE2 SSE3.
Тут спорно: оптимизации часто используют нюансы архитектуры и то, что будет летать на интел процах на других такой производительности может и не покажет _>>Оптимизация под несколько процессоров, с возможностью динамического выбора на стадии выполнения.
будет в большинстве случаев _>>Оптимизация под конкретные модели процессоров Up to P4
ту вопрос. _>>Отложенная кодогенерация на стадии сборки.
будет _>>Эмулятор компилируемого кода, для расчета вероятностей выполнения переходов и узких мест на стадии компиляции. (мегафича)
будет. но эмулировать будет интел архитектуру — потому вопрос. _>>Упрощение выражений, такого не видел нигде! Например sin(x)/cos(x) заменяются на tan(x)
будет
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
, почему-то никто не верит, а самому брать дизассамблер и делать тесты — у меня времени нет, да и зачем мне это нужно, меня-то ведь все устраивает. Здесь я не собираюсь навязывать свое мнение, здесь я просто им делюсь с остальными, внимательно выслушивая других. А что касается моего, конкретно, мнения про все это дело, то я за тот небольшой промежуток времени, с которого здесь зарегился, уже несколько раз высказал свое мнение "обо всем об этом": Для каждой задачи свой инструмент. Гаму, например на D3D на Delphi только пароноик писать начнет, зато небольшую офисную прогу на Delphi я сделаю гораздо быстрее, чем на MFC, но такого удовольствия, как от C++ я не получу никокда ни от какого языка программирования. И споры между кодерами на Delphi и С++ напоминают мне студенческие годы. Давайте просто говорить о достоинствах и недостатках, а не о том, что Delphi — это шит (если это шит, почему его тогда покупают, кучу книг о нем пишут?). Нет ничего идеального, правда нет, тут-то я точно сам все проверил и сравнил и идеального не нашел!
