Здравствуйте, gandjustas, Вы писали:

G>А причем тут скорость конструкций языка? тебе это помогает обманывать себя?
G>Думаешь скорость реальных программ зависит от какой-то мифической "скорости конструкций языка"?

G>Как же тогда померить скорость lisp, там из конструкций языка только скобки?

примера-подтверждения так и нет. Скоростной MD5 на C# я тоже не увидел. Слив засчитываем.

IID> так потрудись привести пример, подтверждающий твои слова. Если бы ты сказал что-то вроде "наивно думать что на С++ всё реализуется с такой же лёгкостью/гибкостью как в .NET" — не было бы таких вопросов к тебе. Раз заикнулся о скорости — давай говорить предметно. Измеряя скорость конструкций языка, а не скорость подсистем ввода вывода/сторонних парсеров/спутников на орбите/etc.

Это все синтетика. Как можно сравнивать if с if'ом?

Вон, в «декларативном программировании» привели пример считывания файлов таки. Ленивый Хаскель всех порвал.

Здравствуйте, criosray, Вы писали:

H>>Просто пример в тему: для нативной Delphi есть скриптеры с компиляцией в x86, есть компиляторы формул (похоже тема вообще популярная), есть в конце-концов бесплатные компиляторы командной строки . Не думаю, что у C++ с этим хуже.

C>Скриптеры будут заведомо менее производительны. Даже такие продвинутые как Lua — даже они в разы медленнее машинного кода, генерируемого CLR. Это конечно не значит, что их производительности не будет хватать на многих задачах — уверен, что будет, но здесь многие переживают за невидимые такты и неслышимые байты оверхеда (юношеский максимализм — что поделаешь...).

Читай внимательнее.

Здравствуйте, hattab, Вы писали:

H>>>Просто пример в тему: для нативной Delphi есть скриптеры с компиляцией в x86, есть компиляторы формул (похоже тема вообще популярная), есть в конце-концов бесплатные компиляторы командной строки . Не думаю, что у C++ с этим хуже.

C>>Скриптеры будут заведомо менее производительны. Даже такие продвинутые как Lua — даже они в разы медленнее машинного кода, генерируемого CLR. Это конечно не значит, что их производительности не будет хватать на многих задачах — уверен, что будет, но здесь многие переживают за невидимые такты и неслышимые байты оверхеда (юношеский максимализм — что поделаешь...).

H>Читай внимательнее.

Примеры?

Здравствуйте, gandjustas, Вы писали:


G>>>ЗЫ. Я уже писал в этой теме тест, который меряет выделение памяти стандартным аллокатором. .NET выигрывает.

H>>Ты так часто это повторяешь, что скоро и сам поверишь...

G>Зачем мне верить, у меня результаты тестов есть.

G>Это вот плюсистам надо верить что их код всегда быстрее.

Они верят, не сомневайтесь.

Как человек, не видивший ничего кроме крупинки Вселенной, считает себя самым разумным существом во Вселенной.

Здравствуйте, gandjustas, Вы писали:

G>>>ЗЫ. Я уже писал в этой теме тест, который меряет выделение памяти стандартным аллокатором. .NET выигрывает.

H>>Ты так часто это повторяешь, что скоро и сам поверишь...

G>Зачем мне верить, у меня результаты тестов есть.

У тебя тест не правильный Померял непонятно что у MSVC++ и экстраполируешь на весь С++... Померяй у Borland C++ Builder'а вышедшего после 2005 года, и увидишь, что Борландовое непонятно что, порвет, и MSVC++, и .NET (впрочем, я давал результаты на FastMM)

Здравствуйте, criosray, Вы писали:

H>>>>Просто пример в тему: для нативной Delphi есть скриптеры с компиляцией в x86, есть компиляторы формул (похоже тема вообще популярная), есть в конце-концов бесплатные компиляторы командной строки . Не думаю, что у C++ с этим хуже.

C>>>Скриптеры будут заведомо менее производительны. Даже такие продвинутые как Lua — даже они в разы медленнее машинного кода, генерируемого CLR. Это конечно не значит, что их производительности не будет хватать на многих задачах — уверен, что будет, но здесь многие переживают за невидимые такты и неслышимые байты оверхеда (юношеский максимализм — что поделаешь...).

H>>Читай внимательнее.

C>Примеры?

Например PaxCompiller.

Здравствуйте, gandjustas, Вы писали:


V>>Насчет порядка на Ruby? Тебе на заметку — простейший шумоподавитель на .Net работает в 3 раза медленнее, чем на С++, микшер конференции на C# — в 3-5 раз медленнее, чем на С++. Не думаю, что я сильно ошибся относительно Ruby.

G>1)Ну приведи код на C++ и C#, дающий такой результат. Хотя сомневаюсь что будет C++, будет тупо С, обернутый в класс и никаких шаблонов, STL, полиморфизма.

Там и на C# варианте никаких генериков в этом месте, полиморфизма и System.Collection.Generic. Что сказать-то хотел?
Код не приведу, качественный аудио-микшинг конференций — это одна из заметных составляющих стоимости сервера конференций, ибо остальное — практически фигня полная.


G>2)Ты писал о real-time, оно вообще говоря с производителностью не связано.

Обожаю сеансы банальностей на rsdn. Если его никто не связал, то оно и не связано. А если связали вполне конкретными требованиями прямо в ТЗ, то ты только что напрасно потряс воздух.

Здравствуйте, samius, Вы писали:

S>Вобщем так:
S>Примерно такого рода DSL, придуманный под string.Replace, чтобы без парсинга
S>

S>function Сфера { return x*x + y*y + z*z; }
S>function XPlaneFunc { return x;}
S>function YPlaneFunc { return y;}
S>function ZZZFunc
S>{
S>    double xmy = x - y; return xmy - Math.Round(xmy, 1);
S>}
S>

Не увидел где там string.Replace, но тем не менее код (как тестовая платформа) мне по душе. Только модифицируйте его до компилябельного состояния.

S>Далее рисуем на растре плоскость Z = 0 в квадрате -1<x<2; -1.5<y<1.5
S>Должно получиться что-то типа болта, вкрученного в стену.

с каким шагом изменяется пара (x,y) ? Давайте так: законченный код на С#, генерирующий некоторый массив значений. По идентичности массивов можно судить о эквивалентности C# <=> C++ реализаций.

S>Непременное условие — возможность изменения описания поверхностей в рантайме.

Это пока опустим, для простоты. Фактически, мы зафиксировали один из вариантов описания поверхностей, теперь посмотрим на скорость рендеринга по нему. Если очень хочется — можно померять две реализации, с вынесом констант в некоторую структуру "настроек".

S>>>Доказывать что md5 на С будет немного быстрее C# мне не надо.
S>Уверен, что разница будет не такая, как между выполнением кода и интерпретацией

Не такая, но и не в несколько процентов, как уверяют одепты .NET Для интереса можно и этим "померяться".

Здравствуйте, Mamut, Вы писали:

IID>> так потрудись привести пример, подтверждающий твои слова. Если бы ты сказал что-то вроде "наивно думать что на С++ всё реализуется с такой же лёгкостью/гибкостью как в .NET" — не было бы таких вопросов к тебе. Раз заикнулся о скорости — давай говорить предметно. Измеряя скорость конструкций языка, а не скорость подсистем ввода вывода/сторонних парсеров/спутников на орбите/etc.

M>Это все синтетика.

Все тесты по сути синтетика.

M>Как можно сравнивать if с if'ом?

Не передёргивай Имелось ввиду измерение скорости самодостаточного алгоритма, который есс-но, описан этими самыми конструкциями. Алгоритма, а не сторонних библиотек/парсеров/сервисов ОС/и т.д.

M>Вон, в «декларативном программировании» привели пример считывания файлов таки. Ленивый Хаскель всех порвал.

Понятно, что ничего не делать можно за бесконечно малое время.

Здравствуйте, criosray, Вы писали:

C>Здравствуйте, IID, Вы писали:

IID>>Т.е. товарищ всеръез считает, что можно написать на .NET программу, которая окажется быстрее чем С++. Мой же поинт в том, что С++ всё-таки быстрее (уж во всяком случае точно не медленнее).

C>Можно написать. У каждой проблемы существует множество решений. Более экспрессивные средства и инструменты дотнет позволяют писать код на много быстрее, уделяя больше времени качеству кода, продуманности дизайна и выбора алгоритмов, ну и наконец быстро профилировать, выявлять узкие места и ликвидировать их.

Не уводите тему в сторону. Мы сейчас рассуждаем только о скорости получившегося кода.

Здравствуйте, IID, Вы писали:


IID>>>Т.е. товарищ всеръез считает, что можно написать на .NET программу, которая окажется быстрее чем С++. Мой же поинт в том, что С++ всё-таки быстрее (уж во всяком случае точно не медленнее).

C>>Можно написать. У каждой проблемы существует множество решений. Более экспрессивные средства и инструменты дотнет позволяют писать код на много быстрее, уделяя больше времени качеству кода, продуманности дизайна и выбора алгоритмов, ну и наконец быстро профилировать, выявлять узкие места и ликвидировать их.

IID>Не уводите тему в сторону. Мы сейчас рассуждаем только о скорости получившегося кода.

А я о чем говорил?

Здравствуйте, IID, Вы писали:

S>>Вобщем так:
S>>Примерно такого рода DSL, придуманный под string.Replace, чтобы без парсинга
S>>

S>>function Сфера { return x*x + y*y + z*z; }
S>>function XPlaneFunc { return x;}
S>>function YPlaneFunc { return y;}
S>>function ZZZFunc
S>>{
S>>    double xmy = x - y; return xmy - Math.Round(xmy, 1);
S>>}
S>>

IID>Не увидел где там string.Replace, но тем не менее код (как тестовая платформа) мне по душе. Только модифицируйте его до компилябельного состояния.

А с чего Вы решили, что он "некомпилябельный"?

Здравствуйте, MxKazan, Вы писали:

MK>Никакого волшебства. Просто если функция вызывается 1000 раз, компилироваться она будет только 1 раз, остальные 999 будет работать машинный код. Чтобы снова не было придирок: я не утверждаю, что эти 999 работают быстрее, чем аналогичный код на С++. А для особо волнующихся, есть NGen.

Diclaimer: я нисколько не считаю .NET/C# тормозным языком. Более того, я готов признать что на типичных задачах тормоза будут некритичными, потребление памяти — вещь в себе, не всегда это значимое ограничение. Я даже готов признать что .NET уделает неряшливый С++ вариант. Но вот с тем что некоторая .NET код может оказаться априори быстрее любого аналогичного кода на С++ (на одинаковом железе, ага) я поверить не могу. И пытаюсь получить от автора данного мнения подтверждение.

Здравствуйте, MxKazan, Вы писали:

MK> Да брось. То, что в разделе КСВ форума RSDN нет людей, которые разрабатывают на Mono, совершенно не означает, что этот проект какой-то не юзабельный и его нельзя приводить в качестве аргументов.

Думаю, что их как раз есть. Они-то и плюются на моно. А вот защищают его те, кто на нем даже hello word не сотворил, ИМХО. Вот этим защитникам я сначала и предлагаю попробовать написать на нем что-то вменяемое и, если не произойдет промывания желудка, защищать его, так сказать, уже во всеоружии. Моя уверенность строится на том, что после C# я пытался подходить к этому снаряду под линуксом уже раз не помню сколько — с каждым разом Qt мне нравится все больше и больше по сравнению с ним.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:


V>>>Насчет порядка на Ruby? Тебе на заметку — простейший шумоподавитель на .Net работает в 3 раза медленнее, чем на С++, микшер конференции на C# — в 3-5 раз медленнее, чем на С++. Не думаю, что я сильно ошибся относительно Ruby.

G>>1)Ну приведи код на C++ и C#, дающий такой результат. Хотя сомневаюсь что будет C++, будет тупо С, обернутый в класс и никаких шаблонов, STL, полиморфизма.

V>Там и на C# варианте никаких генериков в этом месте, полиморфизма и System.Collection.Generic. Что сказать-то хотел?
То что С++ (именно с плюсами) нах не нужен. Для быстрых числомолотилок берем код на C и нормально зовем его из любого языка. Для более высоких абстракций берем более подходящие языки.
Кроме того уже не за горами запуск числомолотилок на GPU, там тоже высокоуровневые языки будут более уместны, так как позволят генерить код для GPU в рантайме.

Здравствуйте, criosray, Вы писали:

C>>>Можно написать. У каждой проблемы существует множество решений. Более экспрессивные средства и инструменты дотнет позволяют писать код на много быстрее, уделяя больше времени качеству кода, продуманности дизайна и выбора алгоритмов, ну и наконец быстро профилировать, выявлять узкие места и ликвидировать их.

IID>>Не уводите тему в сторону. Мы сейчас рассуждаем только о скорости получившегося кода.

C>А я о чем говорил?

Из конкретики — о увеличичении скорости написания кода (могу согласиться). Остальное — вода, зависящая от кучи факторов. Совершенно непонятно, почему код С++ лишается возможности быть качественным, иметь продуманный дизайн, хорошие алгоритмы. Тоже и по профилированию. Возможно при этом для С++ варианта придётся потратить больше (усилий, времени, etc.). С другой стороны это может быть резонно в свете полученных бенефитов (потребление памяти, перфоманс, предсказуемость скорости работы.). Короче опять прописные истины, банальные, обсосанные по сто раз кряду.

Напомню, вопрос всё-таки стоит так, что С++ вариант не всегда окажется быстрее. Я уже кучу постов бьюсь, пытаясь получить "волшебный" .NET код, для которого не окажется более быстрого С++ варианта.

Здравствуйте, IID, Вы писали:

IID>Здравствуйте, criosray, Вы писали:

C>>Здравствуйте, IID, Вы писали:

IID>>>Т.е. товарищ всеръез считает, что можно написать на .NET программу, которая окажется быстрее чем С++. Мой же поинт в том, что С++ всё-таки быстрее (уж во всяком случае точно не медленнее).

C>>Можно написать. У каждой проблемы существует множество решений. Более экспрессивные средства и инструменты дотнет позволяют писать код на много быстрее, уделяя больше времени качеству кода, продуманности дизайна и выбора алгоритмов, ну и наконец быстро профилировать, выявлять узкие места и ликвидировать их.

IID>Не уводите тему в сторону. Мы сейчас рассуждаем только о скорости получившегося кода.

Если не рассматривать способ получения этого кода, то такие рассуждения не нужны.
Это сродни тому что на ассемблере можно написать программу которая будет быстрее любой программы на любом языке.
Тольео практика этот тезис не подтверждает.

Здравствуйте, IID, Вы писали:


C>>>>Можно написать. У каждой проблемы существует множество решений. Более экспрессивные средства и инструменты дотнет позволяют писать код на много быстрее, уделяя больше времени качеству кода, продуманности дизайна и выбора алгоритмов, ну и наконец быстро профилировать, выявлять узкие места и ликвидировать их.

IID>>>Не уводите тему в сторону. Мы сейчас рассуждаем только о скорости получившегося кода.

C>>А я о чем говорил?

IID>Из конкретики — о увеличичении скорости написания кода (могу согласиться). Остальное — вода, зависящая от кучи факторов. Совершенно непонятно, почему код С++ лишается возможности быть качественным, иметь продуманный дизайн, хорошие алгоритмы. Тоже и по профилированию. Возможно при этом для С++ варианта придётся потратить больше (усилий, времени, etc.).


Именно о том и речь. Время, как известно, вовсе не безграничный ресурс.

Здравствуйте, criosray, Вы писали:

ГВ>>Это зависит от того, что в данной конфигурации полагается модулем, а что — интеграцией. Поскольку структура любой сложной программы иерархическая, то модуль на одном уровне — это сборная конструкция на другом.

C>Нет, не зависит. RTFM, как говорится.

Мдее, это какой-то пуленепробиваемый ппц...
Вопрос на засыпку: ты пользуешься классами, скажем, .Net фреймворка в своих тестах? Вернее так, есть ли у тебя хоть один юнит-тест, где ты ими пользуешься?
Я-то ответ знаю, но вижу непонимание тобой сути происходящих вещей.

ГВ>>И неужто будет проще, чем аналогичная заглушка? Это если учесть, то заглушка реализуется в естественном синтаксисе, а мок — перехватом вызовов. Второе будет почти гарантированно сложнее.

C>С этой глупостью я даже спорить не стану.

Это от неумения организовывать тестирование в отсутствии ср-в поддержки или в случае, когда их возможностей не хватает.

C>Можете продолжать бояться. Как все-таки доберетесь до RTFM`а, то поймете, что я был прав.

C>Если Ваш код на столько сложный и запутанный, что Вы не можете написать серию простых тестов для него, значит Ваш код — плохой. Вот Вам и пища для размышлений.

Ну напиши серию простых тестов для многоконтурной АСУ на базе ПИД.
Не все же пишут сайты с магазинами.