Чего их опровергать? Ну обнаружили, что три параметра в примере передаются вчетверо медленнее, и что? Так, по-вашему, замеряют быстродействие? Да, C++ неплохо передаёт небольшое число параметров в функцию, может даже в регистры пару засунуть, проверок не делает. И что?
Наплевать мне на ссылки, как Вы не можете с одного раза-то понять? Для меня важнее, что мой коллега перевёл свой довольно большой проект с Delphi на C# и получил очевидный даже на глаз выигрыш скорости перерисовок, хотя не скорость его занимала. Главное, что перенос дался легко и выявил ряд недоразумений.Приведите код, посмотрим. Я привел ссылку, там код и числа. Вы не привели ничего.
C# обгоняет C++ на сложных вещественных вычислениях. Замерять сложение? А зачем? Обгоняет и при работе с кучей.Впрочем, если рассматривать "сфероконя в вакууме" - голый цикл с суммированием чисел - производительность дествительно сравнимая, у C# чуть-чуть выше, это я тоже проверял. Только как обычно бывает, в реальном приложении картина совсем другая. Чуть ниже тестовый код и результаты.
Именно, что более эффективно для производительности программирования. Заодно, кстати, это даст время и средства на доводку производительности алгоритмов.Я предлагаю писать на том, что более эффективно.
Да управлял. Причём на C++.Дмитрий, а Вы сами-то хоть одним проектом управляли, сложнее драйвера для портов?
То есть, не испытали C#. А методология сравнения Ваша хромает на все ноги.Не все, только номер 2 - движок для онлайн-казино, в составе команды из 3х человек. Название компании-заказчика привести не могу, по вполне понятной причине.
Писали на C++, поскольку заказчик предъявил определенные требования к производительности. На C# выполнить эти требования было бы невозможно.
И мне пофиг, сколько лет C# - если бы задачу можно было выполнить на нем, я бы так и сделал. Но это не всегда возможно.
Код этот можно сократить раз в 10, если не 100. Но это не программа, а невесть что. Наверняка для C++ использовали оптимизации, а на C# и не думали (что правильно, это последнее дело). Возьмите примеры из Visual Studio на C++ и C# и сравните производительность, я сравнивал.Уже нашел. Облегчу Вам задачу и приведу ссылку еще раз: http://www.kbcafe.com/articles/CSharp.Performance.pdf
Впрочем, там не везде в 4 раза, целочисленные вычисления - только в 2.
Приведу еще и свой тест:
И результат:
C++ - 2781 тиков
C# - 11906 тиков
Более чем в 4 раза.
Скрин с результатом на всякий случай приаттачил.
Хотя я не спец по шарпу, возможно что-то упустил.
Нет тут классов, есть какие-то ошмётки. Настоящие объекты намного больше, а значит и регистровая оптимизация не очевидно полезна. Собственно, это одна из методологических посылок приведшая к абстрактному стековому байткоду -- широкое использование сложных объектов приводит к тому, что регистровая оптимизация не необходима. На RISC-процессорах, кстати, сверхоперативный стек чаще всего есть, но не на x86, там только сопроцессор имеет новую архитектуру.Да, и небольшое замечание по поводу кода. Можно было бы обойтись структурами (для Storage например), но поскольку мы обсуждаем большие и сложные программы, нас интересует работа с классами в первую очередь.
Хорошо, что Вы это понимаете. Вот и перестаньте хамить.Хамство Вам не к лицу.
Не знаю таких. Мне это было надо? Пользовался Direct 3D 9 и не беспокоился, я трёхмерные стрелялки, к счастью, не пишу.Найдите хоть один _технологичный_ и _производительный_ 3D движок _полностью_ на C#. Сравнимый с другими хорошими движками, такими как Unreal Engine или движок Crysis.
Притом, что я их использую, это мой опыт.При чем тут шкалы и схемы? Вас про игры спрашивают, причем про _современные_ _технологичные_ игры.
Наберите в google «Производительность C#» и наслаждайтесь, если вопрос волнует. Только у Вас, замечу, вопросов нет, остальные приходят к сложным выводам. Сразитесь там на форумах с «идиотами», которые своё время оценивают выше компьютерного.