Здравствуйте, FR, Вы писали:
VD>>Это чушь. По той же логике, что предъявляют фанаты С++ ассемблер как раз дает больше возможностей для оптимизаций. Например, самые новые инструкции можно заюзать и т.п. Когда там компиляторы до них подтянутся.
FR>Логика таже только ступенька на порядок выше.
Кто измерял этот порядок?
FR>Разница принципиальная между ассемблером и ЯВУ это порядок, внутри майнстримовых языков в лучшем случае разы.
Между С++ и теми же Немерле или Хаскель тот же порядок. Конечно если всеми тремя инструментами хорошо владеть.
С другой стороны это уже сближение позиций. Разница уже заключается только в оценке степени превосходства в уровне и отстования в скорости. Так?
FR>Зависит еще от размеров проекта, его сферы применения и квалификации исполнителей.
От размеров конечно зависит. Чем больше проект, тем менее рентабельно реализовывать его на С++. От сферы не зависит. По крайней мере я эту зависимость не ощущаю. Квалификация вообще показатель отдельный. Сравнивать нужно только при условии, что квалификация идентична. Иначе к затратам нужно прибавлять затраты на обучение или формирование новой команды разработчиков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Да ладно меряли уже не раз, даже если писать шаблоный qsort один в один с сишным плюсовый все-равно выигрывает, за счет агрессивного инлайнинга.
Это чушь хотя бы потому, что компиляторы С и С++ — это в большинстве случаев одни и те же компиляторы. По крайней мере лидеры MS и Intel поступают именно так.
VD>>Кстати, на пример C vs. C++ можно можно спроецировать все сказанное о C++ vs. C#. Ведь на С всегда можно написать код не медленнее чем на С++. Проблема только в трудоемкости.
FR>Можно, и кстати не мало пишут, но опять таки разница между C++ и Си тоже не так велика, хотя и больше чем между С++ и шарпом.
Опять вопрос оценок. Я считаю, что ка раз разница примерно сравнима. В одном случае нам дают ООП и обобщенное программирование, в другом компонентность, автоматическое управление памяти, встроенные в язык запросы, полноценные лямбды.
В прочем, важен сам факт, что ты согласился по существу и оспариваешь только коэффициенты влияния.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>От размеров конечно зависит. Чем больше проект, тем менее рентабельно реализовывать его на С++. От сферы не зависит.
ИМХО чушь. Чем крупнее проект, тем меньше значение какого-то конкретного высокоуровневого языка. А уж разница в скорости разработки конечного продукта вообще становится малоактуальна по сравнению с другими факторами.
Здравствуйте, NikeByNike, Вы писали:
NBN>А уж разница в скорости разработки конечного продукта вообще становится малоактуальна по сравнению с другими факторами.
Скажи это заказчикам.
FR>>Функторы в виде классов лучше инлайнятся чем свободные функции. Хотя современные компиляторы уже и одиночные функции инлайнить умеют, но функторы все-равно позволяют большую гибкость не теряя в скорости.
VD>Махровый бред! VD>Не потрудишься его обосновать?
Здравствуйте, VladD2, Вы писали:
FR>>Неубедительно учитывая горячую любовь игроделов к интеловскому компилятору, который подобные вещи хорошо векторизует, плюс не менее горячую любовь к интрисикам тех игроделов которые не любят интеловский компилятор
VD>Кстати, рассуждения о любви подкреплены какой-то статистикой или как всегда высасывание из пальца?
Влад ты перестал пить коньяк и бить жену по утрам?
Здравствуйте, samius, Вы писали:
NBN>>А уж разница в скорости разработки конечного продукта вообще становится малоактуальна по сравнению с другими факторами. S>Скажи это заказчикам.
Нормальным заказчикам мелкие программерские дрязги вообще пофигу.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, samius, Вы писали:
NBN>>>А уж разница в скорости разработки конечного продукта вообще становится малоактуальна по сравнению с другими факторами. S>>Скажи это заказчикам. NBN>Нормальным заказчикам мелкие программерские дрязги вообще пофигу.
я не про дрязги, а про скорость разработки.
Здравствуйте, NikeByNike, Вы писали:
NBN>ИМХО чушь. Чем крупнее проект, тем меньше значение какого-то конкретного высокоуровневого языка. А уж разница в скорости разработки конечного продукта вообще становится малоактуальна по сравнению с другими факторами.
Чушь — твое ИМХО. От уровня языка зависят и проектные решения, и объем кода который требуется написать, отладить и документировать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, VladD2, Вы писали:
FR>>>Неубедительно учитывая горячую любовь игроделов к интеловскому компилятору, который подобные вещи хорошо векторизует, плюс не менее горячую любовь к интрисикам тех игроделов которые не любят интеловский компилятор
VD>>Кстати, рассуждения о любви подкреплены какой-то статистикой или как всегда высасывание из пальца?
FR>Влад ты перестал пить коньяк и бить жену по утрам?
Что вопрос о статистике некорректен? Я же прошу ответить "да" или "нет". Я прошу ссылки на информацию о том какие игры (особенно топовых) скомпилированы с использованием каких компиляторов?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, samius, Вы писали:
NBN>>>>А уж разница в скорости разработки конечного продукта вообще становится малоактуальна по сравнению с другими факторами. S>>>Скажи это заказчикам. NBN>>Нормальным заказчикам мелкие программерские дрязги вообще пофигу. S>я не про дрязги, а про скорость разработки.
Суммарная скорость разработки крайне мало зависит от выбранного высокоуровневого языка.
Здравствуйте, VladD2, Вы писали:
FR>>Да ладно меряли уже не раз, даже если писать шаблоный qsort один в один с сишным плюсовый все-равно выигрывает, за счет агрессивного инлайнинга.
VD>Это чушь хотя бы потому, что компиляторы С и С++ — это в большинстве случаев одни и те же компиляторы. По крайней мере лидеры MS и Intel поступают именно так.
Угу только в Си приходится пользоватся как параметром указателем на функцию, который умеют инлайнить только последние компиляторы и то не всегда, а в C++ параметр шаблона, который инлайнил даже VC 6.
Ну и частичную специализацию тоже не стоит сбрасывать со счетов.
VD>>>Кстати, на пример C vs. C++ можно можно спроецировать все сказанное о C++ vs. C#. Ведь на С всегда можно написать код не медленнее чем на С++. Проблема только в трудоемкости.
FR>>Можно, и кстати не мало пишут, но опять таки разница между C++ и Си тоже не так велика, хотя и больше чем между С++ и шарпом.
VD>Опять вопрос оценок. Я считаю, что ка раз разница примерно сравнима. В одном случае нам дают ООП и обобщенное программирование, в другом компонентность, автоматическое управление памяти, встроенные в язык запросы, полноценные лямбды.
Ну шаблоны многое компенсируют или хотя бы сглаживают.
VD>В прочем, важен сам факт, что ты согласился по существу и оспариваешь только коэффициенты влияния.
Здравствуйте, gandjustas, Вы писали:
G>Я имею ввиду не использование компилятора С, а неиспользование возможностей C++ — классов, шаблонов, динамической памяти и прочего. G>Для числомолотилок оно и не нужно.
Во-первых, ты так и не объяснил мотивы, во-вторых, без нормального инлайна любая числомолотилка отсосет. Вот возьми класс complex, не представляю себе код для него без переопределённых инлайн операций. Вызывать что-ли ф-ии типа complex_add_double(arg1, arg2)? Это будет уже не числомолотилка, а тормозилка.
Здравствуйте, gandjustas, Вы писали:
V>>Ты еще забыл кодеки, мультимедиа, реалтайм протоколы и т.д. И еще забыл, что последние года 4 тактовая частота процов практически не растет, а обсуждаемого скачка оптимизации JIT-а при переходе на 3.0 версию не было ВООБЩЕ
G>Ну да, всего-то научились инлайнить вызовы со структурами, а также ускорили работу GC, несмотря на то что версия CLR не поменялась.
Угу, версия метаданых не изменилась, а на самом деле, и либы подшаманили нехило (и не только в приватной реализации, местами в публичных интерфейсах), и рантайм подкрутили. Согласен, GC стал более шустр, заметно что теперь он практически незаметен.
G>С учетом этих ускорений код на .NET, который проигрывал плюсовому в 1,5-2 раза стал выигрывать у плюсовго по скорости. G>И это даже бех перекомпиляции программ.
Это от сценариев зависит, там, где была нагрузка на GC, общая производительность действительно выросла. Лично я ожидал оптимизаций по доступу к массивам, тем более, что о возможностях подобной оптимизации JIT-компилятора тогда не говорил только ленивый, однако никаких изменений в этом плане не было, поэтому на числомолотилках C# продолжает сосать.
Здравствуйте, VladD2, Вы писали:
VD>Чушь — твое ИМХО.
Твоё ИМХО бред.
VD>От уровня языка зависят и проектные решения
Чушь.
VD>и объем кода который требуется написать
Единственный реальный фактор, правда переоцениваемый некоторыми религиозными ребятами.
VD>отладить
Основная часть времени отладки (и той же настройки) не зависит от языка (если конечно код писали не совсем нубы, а они могут запороть любой проект, вне зависимости от любого языка).
VD>и документировать.
Объём документации так же не зависит, если конечно какой-то не слишком грамотный ПМ не заставляет документировать собственно исполняемый код.
Объём интерфейсов и функциональности всёравно будут одинаковым и требовать схожего времени на документирование.
Это да сильно субъективно.
FR>>Разница принципиальная между ассемблером и ЯВУ это порядок, внутри майнстримовых языков в лучшем случае разы.
VD>Между С++ и теми же Немерле или Хаскель тот же порядок. Конечно если всеми тремя инструментами хорошо владеть.
В общем да приближается, хотя по моему все таки чуть меньше.
VD>С другой стороны это уже сближение позиций. Разница уже заключается только в оценке степени превосходства в уровне и отстования в скорости. Так?
Так оно всегда только в этом было.
Просто сейчас у меня нет старого пыла отстаивать С++ да и у тебя C# не в фаворитах
Ну и следует учесть что когда мы ругались C# (еще 1.x) был сильно слабее современного.
FR>>Зависит еще от размеров проекта, его сферы применения и квалификации исполнителей.
VD>От размеров конечно зависит. Чем больше проект, тем менее рентабельно реализовывать его на С++.
Угу, до опреденных размеров, у монстров уже язык мало что значит.
VD>От сферы не зависит. По крайней мере я эту зависимость не ощущаю. Квалификация вообще показатель отдельный. Сравнивать нужно только при условии, что квалификация идентична. Иначе к затратам нужно прибавлять затраты на обучение или формирование новой команды разработчиков.
От сферы сильно зависит, про драйверы и ядерные ректоры не будем, но коробочный софт что мелкий (шараварки) что крупный до сих пор выгоднее делать на нативных языках.
Квалификация для C++ более важна, так как порог вхождения достаточно высок.
