Что по-вашему «много»?
Нет там ни 4, ни 2, если речь вести о последней паре лет. Причём часто дело именно в том, что методологию сравнения приблизили к делу.Замеряют по-разному. Замеры различных алгоритмов, начиная от работы со строками и заканчивая обработкой XML и выборкой из баз данных, можно найти в гугле, ссылки я привел. Почти все замеры показывают худшую производительность, от 2х до 4х раз. А замеров передачи параметров я не видел, поэтому написал свой тест.
Не медленнее на деле, опыт имею.То, что программы на C# работают медленнее. Сколько раз повторить, что Вам дошло?
Не «будет работать», а работает давно, и не медленнее, по крайней мере.Хорошо, тогда я Вам без ссылок скажу: программа на C# будет работать в среднем в 2-4 раза медленнее программы на C++. Спасибо, свободны.
Есть доводы серьёзнее? И что Вы там раньше о сборке мусора спрашивали? Она-то причём?И по этому единичному случаю Вы судите о быстродействии языка? Смешно.
Некоторое время обгонял VC. Потом и MS тоже использовали кодогенератор Intel. Разница на уровне дополнительных квалификаторов. Кстати, вызов процедуры Delphi, вроде, до сих пор быстрее.Тем более Дельфи - далеко не эталон, ага.
Не упадёт.Это не имеет никакого значения, поскольку в общем скорость упадет в 2-4 раза. Я Вам про сфероконя уже раза 4 писал, Вы так и не поняли.
Хорошо понимаю, не беспокойтесь.Вы русский язык понимаете?
Есть опыт провалов? Знаю цену скорости кодогенерации -- она ни разу не была важной. Хотя все сравнивают, все беспокоятся. Я, как видите, тоже сравнивал когда-то, тоже переживал и ассемблерные генерации правил. Прошло.Если стоят определенные требования по быстродействию, никакая производительность программирования Вам не поможет, проект будет провален.
А получилось именно так.С чего Вы это взяли? Испытали, разумеется. Решение о выборе языка принимали не от фонаря.
Пояснил уже. Напрмер, в C#, даже unmanned, есть проверки времени исполнения, которых нет в C++, значит, если Вы будете испытывать пример, в котором проверки будут обрабатываться основную часть времени, Вы получите произвольно большое соотношение «тиков». Вот только к производительности это не имеет прямого отношения.Вы что, правда не понимаете зачем там именно такой код? Поясняю на пальцах: в реальной программе нужна инкапсуляция процесса выполнения, процесса вычислений и данных.
Лучшие профессионалы отрасли исследовали относительную цену проверок и выигрыша производительности.
Нет -- Вы.Нет. Невесть что - это то что Вы здесь пишете.
Какую? Сейчас не так много средств оптимизации C#. Замечу, что C# вполне можно просто компилировать, как C++, без байткода. Семантика вполне это позволяет, она много проще C++. У Вас просто нет таких средств. Что не значит, что при окончательной сборке ответственного проекта нельзя их использовать.Оптимизацию использовал и в C#. Не надо меня обвинять в подтасовках. Неужели получше аргументов не нашлось?
Из Direct 3D SDK.Какие именно примеры брали?
Не тормозит, это я Вам не ссылку, а опыт сообщаю.Не пишете, но заявляете, что на C# можно написать. Так вот, я Вам говорю - нельзя, тормозить будет неимоверно. На этот раз без ссылок, раз на ссылки Вам плевать.
А ответил я про это, умному достаточно.Но вопрос Вам задали не про это.
И читали ссылки-то? Или ограничились парой статей 1997 и 2002-2003 годов?А Вы думаете, откуда я взял вышеприведенные ссылки? Именно из гугла, именно по таком запросу, только на английском языке.
Как я без Ваших ценных замечаний буду?EDIT: после прочтения вот этого все вопросы отпали. В игнор.





Ответить с цитированием