Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
FR>>>Шаблоны и классы нужны, позволяют получить более шустрый код чем чистый си. G>>Пример? FR>std::sort vs qsort
Как шаблоны как compile-time кодогенерация действительно хорошо работает. Я там образом оптимизировал библиотеку для нейронных сетей на крусовую.
В принципе runtime кодогенерация позволяет даже больше, но с большими усилиями.
А классы каким образом позволяют получить более быстрый код, на примере числомолотилки типа md5?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, IID, Вы писали:
IID>>Не уводите тему в сторону. Мы сейчас рассуждаем только о скорости получившегося кода.
VD>А тебе о скорости получаемых приложений. Она определяется не только, да и не столько скоростью выполняемого кода сколько качеством и скоростными характеристиками используемых алгоритмов.
Возьмём два абсолютно идентичных алгоритма. Что теперь у нас со скоростью ?
Здравствуйте, MxKazan, Вы писали:
MK> Не, ну это как-то не хорошо с твоей стороны. Получается ты просто игнорируешь реальные примеры. Зачем тогда спрашивать
Я просто знаком с фанатизмом Влада, чтобы не тратить время на бесполезный для меня разговор (не в обиду Владу). Мастер класса на Nemerle по рантаймом Mono я все равно не дождусь — эта задачка будет посложнее, чем просто мастер-класс на Mono, а вот ресурсов потеряю изрядно.
G>Как шаблоны как compile-time кодогенерация действительно хорошо работает. Я там образом оптимизировал библиотеку для нейронных сетей на крусовую. G>В принципе runtime кодогенерация позволяет даже больше, но с большими усилиями.
G>А классы каким образом позволяют получить более быстрый код, на примере числомолотилки типа md5?
Функторы в виде классов лучше инлайнятся чем свободные функции. Хотя современные компиляторы уже и одиночные функции инлайнить умеют, но функторы все-равно позволяют большую гибкость не теряя в скорости.
Здравствуйте, FR, Вы писали:
FR>Ассемблер сейчас дает меньший простор, кроме нескольких узких случаев, и даже для них удобнее править выхлоп сишного компилятора.
Это чушь. По той же логике, что предъявляют фанаты С++ ассемблер как раз дает больше возможностей для оптимизаций. Например, самые новые инструкции можно заюзать и т.п. Когда там компиляторы до них подтянутся.
FR>К тому же ассемблер средство другого класса, трудоемкость разработки на нем (даже учитывая чудеса макроассемблеров) на порядок ниже чем на C++.
О том я и говорил. Именно трудоемкость. То есть приципиально повышения производительности добиться конечно можно, но если сравнить затраты и получаемый выхлоп мало кого это заинтересует.
FR>Шарп и С++ по трудоемкости разработки в одном классе.
Это чушь. Трудоемкость на С++ выше очень значительно. Разница не такая огромная как в сравнении С++ и ассемблера, но тоже очень велика. А если учесть, что есть языки сильно мощнее C#, то она уже становится очень значительной. При этом с точки зрения скорости, для большинства задач разница как раз не велика (если вообще есть).
Посему если у тебя много бабла (проект высоко рентабельный), то С++ может быть подходящим, так как увеличение трудоемкости окупается конкретными преимуществами — меньшими требованиями к ресурсам компьютера, а значит расширением базы аудитории. Если же проект низкотиражный или вообще штучный, то разработка на С++ — это чистейшей воды идиотизм и бездарная трата ресурсов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Anton Batenev, Вы писали:
VD>> Что ты хочешь увидеть?
AB>Мастер-класс, я же написал
Это типа попрограммировать на публике чтобы все рты по открывали?
VD>> Компилятор Nemerle параллельно живет под двумя рантаймами: Mono и .Net. Можешь загрузить и скомпилировать. Это подойдет для "просмотра"?
AB>Nemerle — это тот же моно, только в профиль. Но, почему-то, развивать с тобой дискуссию в этом направлении у меня нет никакого желания.
А что развивать-то? Ты сморизил чушь. К Моно он отношения не имеет... кроме того, что под ним может работать.
AB>Откланиваюсь заранее.
Да, давно пора. Слив, с твоей стороны, уже произошел. Что еще обсуждать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>Ну, а главное, что есть софт который в условиях ограниченных ресурсов вообще нельзя реализовать на С++ (костьми ляжешь). NBN>Оно же верно и для шарпа, поэтому я на него так и не перешёл
Ага. Есть такие задачи. Только если расставить языки в линейку по уровню, то С++ будет сильно позади того же шарпа, так что если задача сложна для шарпа (и это не вызвано С-шным (или еще более низкоуровневым) АПИ, то она априори более сложна и для С++.
NBN>Игры, кроссплатформенные приложения, некоторые виды миддлеваре
Бредишь?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AB>>Я просто знаком с фанатизмом Влада,
VD>Чья бы корова мычала. Споришь с очевидными фактами и при этом имеешь наглость обвинять других в фанатизме.
Влад, я пришел к выводу, что спор с господами типа Антона Батенева, вдимаса, Геннадия Васильева и т.д. — местных аппологетов С++, это пустая трата времени и сил. Аргументов Вы от них все-равно не услышите, а все даже самые простые факты они буду с завидным упорством отвергать. К тому же спорят-то они о вкусе устриц...
Не тратьте время. Они все-равно будут верить только в то, во что хотят верить. Переубедить их сможет только жизнь.
Здравствуйте, FR, Вы писали:
G>>Пример?
FR>std::sort vs qsort
Подлог! Это разные алгоритмы.
Кстати, на пример C vs. C++ можно можно спроецировать все сказанное о C++ vs. C#. Ведь на С всегда можно написать код не медленнее чем на С++. Проблема только в трудоемкости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Функторы в виде классов лучше инлайнятся чем свободные функции. Хотя современные компиляторы уже и одиночные функции инлайнить умеют, но функторы все-равно позволяют большую гибкость не теряя в скорости.
Махровый бред!
Не потрудишься его обосновать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, criosray, Вы писали:
C>Не тратьте время. Они все-равно будут верить только в то, во что хотят верить. Переубедить их сможет только жизнь.
А как же трофеи?
Здравствуйте, FR, Вы писали:
FR>Неубедительно учитывая горячую любовь игроделов к интеловскому компилятору, который подобные вещи хорошо векторизует, плюс не менее горячую любовь к интрисикам тех игроделов которые не любят интеловский компилятор
А я сразу оговорился, что говорить про язык некорректно. Раз уж человек обобщил до языка, то его заключения обязаны быть корректны для всех компиляторов. Пример приведенный мной демонстрирует, что это не так. Значит и заключение не верно.
Что не так?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>Неубедительно учитывая горячую любовь игроделов к интеловскому компилятору, который подобные вещи хорошо векторизует, плюс не менее горячую любовь к интрисикам тех игроделов которые не любят интеловский компилятор
Кстати, рассуждения о любви подкреплены какой-то статистикой или как всегда высасывание из пальца?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
C>>Элементарно средствами RhinoMocks.
V>Во-первых, мне гораздо больше по душе TypeMock, по сравнению с которым рино курит, во вторых даже на нем это не элементарно.
Раньше у меня были сомнения, что Вы возможно имеете представление хоть примерно о сути разговора... Увидев ЭТО, понял, что я сильно ошибался.
Здравствуйте, samius, Вы писали:
C>>Не тратьте время. Они все-равно будут верить только в то, во что хотят верить. Переубедить их сможет только жизнь. S>А как же трофеи?
Здравствуйте, IID, Вы писали:
IID>Возьмём два абсолютно идентичных алгоритма. Что теперь у нас со скоростью ?
Получаются два абсолютно сферических коня в вакууме.
Даже два абсолютно одинаковых алгоритма на одном и том же языке можно реализовать совершенно по разному.
Если же вернуться к реальности (от сфероконей), то тут уже неоднократно замечали, что упрощение разработки позволяет в том числе потратить больше времени на тестирование, выбор подходящих алгоритмов и их оптимизацию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Ассемблер сейчас дает меньший простор, кроме нескольких узких случаев, и даже для них удобнее править выхлоп сишного компилятора.
VD>Это чушь. По той же логике, что предъявляют фанаты С++ ассемблер как раз дает больше возможностей для оптимизаций. Например, самые новые инструкции можно заюзать и т.п. Когда там компиляторы до них подтянутся.
Логика таже только ступенька на порядок выше.
FR>>К тому же ассемблер средство другого класса, трудоемкость разработки на нем (даже учитывая чудеса макроассемблеров) на порядок ниже чем на C++.
VD>О том я и говорил. Именно трудоемкость. То есть приципиально повышения производительности добиться конечно можно, но если сравнить затраты и получаемый выхлоп мало кого это заинтересует.
FR>>Шарп и С++ по трудоемкости разработки в одном классе.
VD>Это чушь. Трудоемкость на С++ выше очень значительно. Разница не такая огромная как в сравнении С++ и ассемблера, но тоже очень велика. А если учесть, что есть языки сильно мощнее C#, то она уже становится очень значительной. При этом с точки зрения скорости, для большинства задач разница как раз не велика (если вообще есть).
Разница принципиальная между ассемблером и ЯВУ это порядок, внутри майнстримовых языков в лучшем случае разы.
VD>Посему если у тебя много бабла (проект высоко рентабельный), то С++ может быть подходящим, так как увеличение трудоемкости окупается конкретными преимуществами — меньшими требованиями к ресурсам компьютера, а значит расширением базы аудитории. Если же проект низкотиражный или вообще штучный, то разработка на С++ — это чистейшей воды идиотизм и бездарная трата ресурсов.
Зависит еще от размеров проекта, его сферы применения и квалификации исполнителей.
Здравствуйте, VladD2, Вы писали:
VD>Подлог! Это разные алгоритмы.
Да ладно меряли уже не раз, даже если писать шаблоный qsort один в один с сишным плюсовый все-равно выигрывает, за счет агрессивного инлайнинга.
VD>Кстати, на пример C vs. C++ можно можно спроецировать все сказанное о C++ vs. C#. Ведь на С всегда можно написать код не медленнее чем на С++. Проблема только в трудоемкости.
Можно, и кстати не мало пишут, но опять таки разница между C++ и Си тоже не так велика, хотя и больше чем между С++ и шарпом.
