1. Ну так эти результаты надо привести. JIT-x86 и JIT-x64 — это два разных JIT-компилятора. Вы приводите результаты для одного, а вывод делаете общий, это абсолютно некорректно. Например, LegacyJIT-x64 умеет разматывать циклы чётной длины: при снижении количество итераций с 10000 до 9999 время работы может увеличиться, т. к. размотка цикла отключится. LegacyJIT-x86 такой размотки нет, там такого эффекта не будет.
2. Как я понимаю, RyuJIT у вас уже установлен (он идёт вместе с VisualStudio 2015 и .NET Framework 4.6), так что все x64-приложения под .NET 4.0+ запускаются из под RyuJIT. Рецепт отключения можно найти тут. Но на вашем месте я бы разобрался в теме намного подробнее: вы делаете выводы об эффективности JIT-компилятора, но при этом не знаете какого именно.
3. Сложно. Как написать сортировку «наиболее правильным методом» на неуправляемый код — это действительно не такая простая задача, тут думать надо. Как я уже отмечал выше, если стоит вопрос об эффективном решении задачи, то смысла писать простую неуправляемую сортировку нет — это академическая задачка, котоаря имеет мало отношения к реальной жизни. Если вам не подошла стандартная сортировка из BCL, то скорее всего у вашей задачи есть специфика, которую нужно учитывать при реализации этой самой сортировки.
4, 6, 7. Микробенчмаркинг — это очень сложная тематика. Я ей занимаюсь уже несколько лет, а у меня всё равно часто бенчмарки с ошибками получаются. Для грамотного замера времени C#-кода могу предложить попробовать BenchmarkDotNet. Для С++ конкретных советов дать не могу, но крайне советую поискать какие-нибудь библиотеки, которые позволят вам построить хороший бенчмарк и получить адекватные результаты.
5, 10. Ну тогда нужно предельно чётко обозначить границы вашего эксперимента во введении и заключении. Ещё раз: вы измеряете не эффективность C# а эффективность конкретных C#-компиляторов, JIT-компиляторов, конкретных реализаций .NET и т. п. У меня есть много знакомых, которые каждый день пишут на C#, но при этом работают только с Mono. Чтобы не путать людей, нужно написать: «Результаты справедливы для Microsoft .NET Framework, версия такая-то, в качестве JIT используем RyuJIT, измеряем скорость доступа к элементу массива в управляемом коде и т. д.»
8, 9. Я не вижу особой пользы от выводов, которые приведены «в среднем по больнице». Польза будет от наблюдений вида «если в C# писать вот так, то работать будет столько, а если писать вот так, то вот столько». Непонятно, из чего складываются ваши 10..80%, какие штуки привносят в C# накладные расходы. В статье, на которую вы ссылаетесь, всё нормально написано, в выводах делается анализ: что на что влияет. В вашей статье анализа нет, а оценки накладных расходов не включают в себя правдоподобные доказательства.
По результатам не хватает:
* Сравнение x86 и x64
* Сравнение LegacyJIT и RyuJIT
* Сравнение безопасного и небезопасного кода
* Сравнение результатов для разных размерностей массива (+ анализ того, каковы издержки на промохи кэша под каждую размерность на каждой железке)
* Сравнение разных версий рантайма (где Mono, где .NET Native и т. п.)
По методике измерений не хватает:
* Грамотный прогрев бенчмарка (если вы измеряете холодный запуск, что весьма странно, то не мешало бы добавить сравнение с NGEN)
* Многократный запуск бенчмарка и анализ разброса значений (желательно делать запуски в разных процессах, т. к. разные запуски CLR могут дать разные steady state)
* Есть ещё вагон и маленькая тележка разных тонких моментов, о которых нужно подумать, чтобы быть увереным в том, что бенчмарк даёт правдоподобные результаты.
По выводам:
* Содержательных выводов нет. Вы взяли какой-то очень специфичный пример программы, взяли очень специфичную конфигурацию для запуска, что-то померили, получили какие-то числа. Какой вывод должен сделать внимательный читатель? Что у управляемого кода есть некоторый overhead? Ну, это вроде бы и так было понятно.
* Для того, чтобы делать какие-то глобальные выводы в споре о производительности C++ vs C#, необходимо:
а) Смотреть не на один пример (который своим особым образом показывает издержки на обращение к элементу массива), а взять штук 600 разных примеров, каждый из которых проверяет отдельный аспект того или иного решения.
б) Смотреть на разные конфигурации. У языков самих по себе никакой производительности нет, измерять можно только скорость работы исполняемых файлов, которые получены в ходе компиляции. Стало быть, сравнивать надо компиляторы (для C# хотелось бы глянуть на выхлоп старого доброго csc и Roslyn-а под разные версии .NET Framework; Mono; .NET Native, который покажет вам совсем другие числа). Ну и запуск нужно проводить в разных окружениях, нынче их много.
в) Мне не нравится изначальная формулировка эксперимента «написать максимально идентичный и простой код на одном и другом языке». На мой взляд, при работе на современном железе зачастую проблемам скорости можно уделять не так много времени: многим не так важно, обработается ли, к примеру, пользовательский запрос за 50ms или 100ms. Если говорить о производительности, то нужно смотреть на такие ситуации, когда возникают проблемы с этой самой производительностью. И тут при сравнении языков разумней сравнивать не то, насколько различается производительность «максимально идентичного и простого кода», а то, насколько сложно эффективно решить ту или иную задачу на каждом из языков.
Dywar уже ответил за меня =)
Если честно, то такие задачи возникают не очень часто, но если возникают, то знание представленного материала очень помогает. Например, я на своей работе постоянно занимаюсь какими-нибудь микрооптимизациями, такова специфика проекта.
Да, 772G — отличная модель, ни разу не пожалел о покупке.
Что касается просмотра ASM, то возможностей VisualStudio мне вполне хватает в 80% случаев, а пользоваться в разы удобнее. В WinDbg лезу только тогда, когда нужно что-то специфическое.
Я занимаюсь распознаванием изображений, так что могу немного прокомментировать. В реальной жизни для применения каких-то простых фильтров отлично подходит любой вменяемый профессиональный графический редактор. ИМХО, для маленьких экспериментов — самый лучший путь. А если писать что-то серьёзное, то это чаще всего алгоритмы на базе opencv, реализованные на чём-нибудь вроде C++/Python/C#, чтобы можно было результаты работы нормально распространять. В общем, не вижу как мне Wolfram может помочь в области CV.
Согласен с Arastas. Поясню мысль на конкретном примере. Я занимаюсь дифференциальными уравнениями и динамическими системами (+стандартные статистики и визуализации). Все свои задачи я решаю на R. И я прекрасно помню почему я перешёл именно на R: я нашёл в сети множество примеров того, как люди легко и изящно решают на нём задачи из моей повседневной жизни. И мне сразу захотелось тоже так уметь: написал несколько простых строк — и всё заработало.
Поймите меня правильно, Wolfram Language — безусловно потрясающий проект. Каждый раз с удовольствием читаю про него статьи. Несколько раз был на ваших выступлениях, надеюсь посетить будущее мероприятия. Но я ни разу так и не увидел примера, который бы меня воодушевил перейти на Wolfram. Ни разу во время программирования у меня не возникло мысли вида «А вот если бы я писал на Wolfram, то вот эту штуку было бы сделать проще». Я ни в коем случае не говорю, что Wolfram чем-то уступает R. Я просто говорю, что я не видел примеров того, как Wolfram превосходит R на моём стеке задач (мне не так часто нужны первые 1000 цифр числа Пи). Поэтому у меня нет мотивации, чтобы бросать всё и бежать изучать новый язык (того же мнения придерживаются многие мои коллеги). Возможно, если бы было больше узкоспециализированных постов про Wolfram из различных областей, то ситуация бы изменилась.
Согласен с вами. С одной стороны, я понимаю почему XAML такой: некоторые его подходы обеспечивают высокий уровень гибкости. Плюс, абсолютно понятно как XAML отображается в стандартные классы. WPF позволяет делать удивительные вещи. Но вот сам XAML далеко не всегда радует, это правда. Лично меня больше всего всегда гриды печалили. Очень хочется, чтобы вместо
Неглупые выпускники всё равно много не понимают. Сборка мусора для джуниоров тёмный лес, а открывать байт-код большинство морально не готовы. В JVM и .NET много похожих концептов. Моё мнение: если имеется хорошее понимание управляемой исполняемой среды, то переучиться с Java на .NET не так сложно.
Плюс есть ещё один интересный момент. Будущее за теми .NET-технологиями, которые только-только появились, но даже в релиз ещё не вышли. Появились такие прекрасные штуки как Roslyn, CoreCLR, .NET Native, RyuJIT, ASP.NET 5. На сегодняшний день в них разбирается крайне малое количество народу. Я пишу на C# больше 10 лет, но если я сейчас не стану сидеть долго и упорно изучая все новые .NET-технологии, то через пару лет не смогу назвать себя квалифицированным C#-разработчиком. Microsoft в короткий промежуток времени выкинуло на рынок великое множество новых технологий. С одной стороны — это просто прекрасно, ведь с их помощью можно будет делать не менее великие проекты. А с другой стороны — это большой объём работы по самообразованию для тех, кто эти проекты хочет делать.
Это я к чему. На мой взгляд, сейчас как раз самый подходящий момент, чтобы с Java на .NET переходить. Завтра будут требовать n лет опыта с .NET 2015+, а у вас есть шанс начать работать с новыми технологиями ещё до их релиза. Не думаю, конечно, что в ближайшее время Java умрёт, но если Microsoft доделает всё обещанное (а у них есть все шансы на это с текущей стратегией), то .NET должен отгрызть себе приличную часть рынка.
Надо будет на досуге подобную штуку для .NET сделать. Но только там алгоритм сложнее: хэши считаются отдельно по чётным и нечётным символам + есть XOR. На коленке сходу удалось подобрать лишь два примера:
Спасибо за поддержку! Могу ещё добавить, что у меня есть пара десятков знакомых, которые перешли из C++ мира в мир C# и не разу об этом не пожалели. Хоть у меня и нет собственного особого плюс-плюс-опыта, но их авторитетному мнению я доверяю.
Ладно, у нас с вами разные вероисповедания, к консенсусу прийти не получится.
Нету в грамотно используемых плюсах «кучи времени на работу с низкоуровневыми проблемами», если явно на этот низкий уровень ради выжимания максимальной производительности не лезть.
Ну, согласен немного уступить, но не до конца. Тогда такой тезис: вероятность того, что средний плюсовый разработчик будет использовать плюсы грамотно меньше, чем вероятность того, что средний шарповский разработчик будет грамотно использовать шарп. Вы меня извините, но просто для меня это больная тема: слишком уж много доводилось видеть плюсового ужаса в своей жизни. Шарповский ужас тоже приходилось видеть, но его удавалось зарефакторить так, чтобы он начал смотреться нормально. В случае с плюсами зачастую проще выбросить на помойку сотни индусочасов работы и написать всё с нуля.
сразу грамотно заложили архитектуру — и конечный результат реально получился на заглядение
Молодцы! Тут не спорю, написать нормально можно, если навыки имеются.
При этом фронт-энд к этому проекту на 80% написанному на плюсах народ в другом офисе замутил несмотря на наше сопротивление на шарпе.
Мешать вредно для здоровья, тут тоже не спорю. А если с программированием большие проблемы, то C#-магия не спасёт от написания плохого кода.
Но в любом случае чем крупнее проект — тем бледнее преимущества C#.
Видимо тут мы не договоримся. Я всё равно стою на том, что C# для больших проектов идеально подходит. Можем всю ночь бросаться в друг друга аргументами, но всё равно каждый при своём останется.
Там где в шарпе нет готовых решений которые можно сразу зареюзать его полезность резко падает.
Надеюсь, вы не будете спорить, что есть шарповские решения без аналогов на плюсах? Полезность использования конкретных библиотек под конкретные задачи нужно оценивать из ТЗ.
Давайте я угадаю: именно на этот низкий плюсовый уровень приходится 90% процессорного времени, да :)?
Не угадали. Грубая оценка — 50% приходится на наши C#-алгоритмы. И я что-то сильно сомневаюсь, что напиши мы всю на плюсах, расклад резко поменялся бы.
и написать его будет проще
Нет, не договоримся мы. Давайте теперь я угадаю: вам не приходилось проектировать и разрабатывать C#-приложения (хорошие приложения, чтобы была грамотная архитектура, с которой удобно работать), размер которых исчислялся в сотнях тысяч строк кода. И маленькое признание: мне не доводилось иметь дело с проектами подобных размеров на плюсах. Очевидно, что вам проще писать на C++, а мне — на C#. При таком раскладе оба наших мнения предвзяты. Невозможно прийти к соглашению бросаясь друг в друга отдельными кусками личного опыта. Увы, подробный анализ ситуации займёт крайне много времени.
Исторический аспект важен, согласен. Но мы обсуждаем текущую сложившуюся ситуацию. Я утверждаю, что на сегодняшний день для многих проектов (но не для всех) лучше использовать C#, а не С++. Я не говорил, что С++ нельзя переписать с нуля так, чтобы общая философия сохранилась, а новый язык получился лучше шарпа. Но такого языка нет. А C# сам по себе и есть попытка переписать C с нуля, чтобы программировать было проще. Всякие штуки типа управляемости — аспекты нового подхода.
Для одних задач оптимальны плюсы, для других — шарп, для третьих — питон, для четвертых — прости господи, PHP.
Отлично, мы приближаемся к консенсусу. С этим абсолютно согласен. Даже про проекты на пых-пыхе.
Для
а) крупных проектов
б) нетривиальных задач
в) задач где важна производительность
плюсы, особенно C++11, не проигрывают шарпу ни в чем, но имеют ряд преимуществ.
А вот тут не соглашусь.
а) Зависит от специфики крупного проекта. Мне доводилось принимать участие в ряде весьма крупных проектов на C#. Работать было легко и приятно, я думал главным образом про дизайн и алгоритмы. Возводить подобное на плюсах я бы в жизни не согласился.
б) Что вы имеете в виду?
в) Тут опять важная специфика, от неё многое зависит. Современный CLR позволяет написать критичные по производительности куски кода так, что по скорости они вполне могут соревноваться с плюсовыми аналогами. Например, я сейчас работаю в проекте по обработке изображений. На низком уровне мы используем базовые методы OpenCV, а основной код (включая большую и хитрую логику по применению различных преобразований и их обработке) целиком написан на C#. Все наши алгоритмы просто летают, в то время как .NET позволяет сделать остальную разработку сплошным удовольствием. В другом проекте я также отвечал за сложные алгоритмы и тяжёлую математику. Пришлось немного постараться, в некоторых местах отказаться от прелестей ООП, но в итоге алгоритмы работают крайне быстро. А знакомые у меня занимаются 3D-рендерингом: 100% C# код написан очень хорошо, а работает настолько быстро, что плюсовые конкуренты нервно курят в сторонке.
Небольшой итог: производительный код на C# вполне писать можно, лишь бы руки из того места росли. Согласен, что есть проекты на которых без С++ никуда. Но они вовсе не обязательно нужны для крупного перфоменс-критикал проекта.
Предлагаю закончить нашу небольшую дискуссию и остановиться на следующей мысли: для каждой задачи хорош свой язык. Есть проекты, которые лучше делать на шарпе, а есть — которые лучше делать на плюсах. При выборе нужно исходить из конкретного чёткого ТЗ. Согласны?
2. Как я понимаю, RyuJIT у вас уже установлен (он идёт вместе с VisualStudio 2015 и .NET Framework 4.6), так что все x64-приложения под .NET 4.0+ запускаются из под RyuJIT. Рецепт отключения можно найти тут. Но на вашем месте я бы разобрался в теме намного подробнее: вы делаете выводы об эффективности JIT-компилятора, но при этом не знаете какого именно.
3. Сложно. Как написать сортировку «наиболее правильным методом» на неуправляемый код — это действительно не такая простая задача, тут думать надо. Как я уже отмечал выше, если стоит вопрос об эффективном решении задачи, то смысла писать простую неуправляемую сортировку нет — это академическая задачка, котоаря имеет мало отношения к реальной жизни. Если вам не подошла стандартная сортировка из BCL, то скорее всего у вашей задачи есть специфика, которую нужно учитывать при реализации этой самой сортировки.
4, 6, 7. Микробенчмаркинг — это очень сложная тематика. Я ей занимаюсь уже несколько лет, а у меня всё равно часто бенчмарки с ошибками получаются. Для грамотного замера времени C#-кода могу предложить попробовать BenchmarkDotNet. Для С++ конкретных советов дать не могу, но крайне советую поискать какие-нибудь библиотеки, которые позволят вам построить хороший бенчмарк и получить адекватные результаты.
5, 10. Ну тогда нужно предельно чётко обозначить границы вашего эксперимента во введении и заключении. Ещё раз: вы измеряете не эффективность C# а эффективность конкретных C#-компиляторов, JIT-компиляторов, конкретных реализаций .NET и т. п. У меня есть много знакомых, которые каждый день пишут на C#, но при этом работают только с Mono. Чтобы не путать людей, нужно написать: «Результаты справедливы для Microsoft .NET Framework, версия такая-то, в качестве JIT используем RyuJIT, измеряем скорость доступа к элементу массива в управляемом коде и т. д.»
8, 9. Я не вижу особой пользы от выводов, которые приведены «в среднем по больнице». Польза будет от наблюдений вида «если в C# писать вот так, то работать будет столько, а если писать вот так, то вот столько». Непонятно, из чего складываются ваши 10..80%, какие штуки привносят в C# накладные расходы. В статье, на которую вы ссылаетесь, всё нормально написано, в выводах делается анализ: что на что влияет. В вашей статье анализа нет, а оценки накладных расходов не включают в себя правдоподобные доказательства.
* Сравнение x86 и x64
* Сравнение LegacyJIT и RyuJIT
* Сравнение безопасного и небезопасного кода
* Сравнение результатов для разных размерностей массива (+ анализ того, каковы издержки на промохи кэша под каждую размерность на каждой железке)
* Сравнение разных версий рантайма (где Mono, где .NET Native и т. п.)
По методике измерений не хватает:
* Грамотный прогрев бенчмарка (если вы измеряете холодный запуск, что весьма странно, то не мешало бы добавить сравнение с NGEN)
* Многократный запуск бенчмарка и анализ разброса значений (желательно делать запуски в разных процессах, т. к. разные запуски CLR могут дать разные steady state)
* Есть ещё вагон и маленькая тележка разных тонких моментов, о которых нужно подумать, чтобы быть увереным в том, что бенчмарк даёт правдоподобные результаты.
По выводам:
* Содержательных выводов нет. Вы взяли какой-то очень специфичный пример программы, взяли очень специфичную конфигурацию для запуска, что-то померили, получили какие-то числа. Какой вывод должен сделать внимательный читатель? Что у управляемого кода есть некоторый overhead? Ну, это вроде бы и так было понятно.
* Для того, чтобы делать какие-то глобальные выводы в споре о производительности C++ vs C#, необходимо:
а) Смотреть не на один пример (который своим особым образом показывает издержки на обращение к элементу массива), а взять штук 600 разных примеров, каждый из которых проверяет отдельный аспект того или иного решения.
б) Смотреть на разные конфигурации. У языков самих по себе никакой производительности нет, измерять можно только скорость работы исполняемых файлов, которые получены в ходе компиляции. Стало быть, сравнивать надо компиляторы (для C# хотелось бы глянуть на выхлоп старого доброго csc и Roslyn-а под разные версии .NET Framework; Mono; .NET Native, который покажет вам совсем другие числа). Ну и запуск нужно проводить в разных окружениях, нынче их много.
в) Мне не нравится изначальная формулировка эксперимента «написать максимально идентичный и простой код на одном и другом языке». На мой взляд, при работе на современном железе зачастую проблемам скорости можно уделять не так много времени: многим не так важно, обработается ли, к примеру, пользовательский запрос за 50ms или 100ms. Если говорить о производительности, то нужно смотреть на такие ситуации, когда возникают проблемы с этой самой производительностью. И тут при сравнении языков разумней сравнивать не то, насколько различается производительность «максимально идентичного и простого кода», а то, насколько сложно эффективно решить ту или иную задачу на каждом из языков.
Если честно, то такие задачи возникают не очень часто, но если возникают, то знание представленного материала очень помогает. Например, я на своей работе постоянно занимаюсь какими-нибудь микрооптимизациями, такова специфика проекта.
Что касается просмотра ASM, то возможностей VisualStudio мне вполне хватает в 80% случаев, а пользоваться в разы удобнее. В WinDbg лезу только тогда, когда нужно что-то специфическое.
Поймите меня правильно, Wolfram Language — безусловно потрясающий проект. Каждый раз с удовольствием читаю про него статьи. Несколько раз был на ваших выступлениях, надеюсь посетить будущее мероприятия. Но я ни разу так и не увидел примера, который бы меня воодушевил перейти на Wolfram. Ни разу во время программирования у меня не возникло мысли вида «А вот если бы я писал на Wolfram, то вот эту штуку было бы сделать проще». Я ни в коем случае не говорю, что Wolfram чем-то уступает R. Я просто говорю, что я не видел примеров того, как Wolfram превосходит R на моём стеке задач (мне не так часто нужны первые 1000 цифр числа Пи). Поэтому у меня нет мотивации, чтобы бросать всё и бежать изучать новый язык (того же мнения придерживаются многие мои коллеги). Возможно, если бы было больше узкоспециализированных постов про Wolfram из различных областей, то ситуация бы изменилась.
можно было бы писать что-нибудь в духе
Плюс есть ещё один интересный момент. Будущее за теми .NET-технологиями, которые только-только появились, но даже в релиз ещё не вышли. Появились такие прекрасные штуки как Roslyn, CoreCLR, .NET Native, RyuJIT, ASP.NET 5. На сегодняшний день в них разбирается крайне малое количество народу. Я пишу на C# больше 10 лет, но если я сейчас не стану сидеть долго и упорно изучая все новые .NET-технологии, то через пару лет не смогу назвать себя квалифицированным C#-разработчиком. Microsoft в короткий промежуток времени выкинуло на рынок великое множество новых технологий. С одной стороны — это просто прекрасно, ведь с их помощью можно будет делать не менее великие проекты. А с другой стороны — это большой объём работы по самообразованию для тех, кто эти проекты хочет делать.
Это я к чему. На мой взгляд, сейчас как раз самый подходящий момент, чтобы с Java на .NET переходить. Завтра будут требовать n лет опыта с .NET 2015+, а у вас есть шанс начать работать с новыми технологиями ещё до их релиза. Не думаю, конечно, что в ближайшее время Java умрёт, но если Microsoft доделает всё обещанное (а у них есть все шансы на это с текущей стратегией), то .NET должен отгрызть себе приличную часть рынка.
int.MinValue:Ну, согласен немного уступить, но не до конца. Тогда такой тезис: вероятность того, что средний плюсовый разработчик будет использовать плюсы грамотно меньше, чем вероятность того, что средний шарповский разработчик будет грамотно использовать шарп. Вы меня извините, но просто для меня это больная тема: слишком уж много доводилось видеть плюсового ужаса в своей жизни. Шарповский ужас тоже приходилось видеть, но его удавалось зарефакторить так, чтобы он начал смотреться нормально. В случае с плюсами зачастую проще выбросить на помойку сотни индусочасов работы и написать всё с нуля.
Молодцы! Тут не спорю, написать нормально можно, если навыки имеются.
Мешать вредно для здоровья, тут тоже не спорю. А если с программированием большие проблемы, то C#-магия не спасёт от написания плохого кода.
Видимо тут мы не договоримся. Я всё равно стою на том, что C# для больших проектов идеально подходит. Можем всю ночь бросаться в друг друга аргументами, но всё равно каждый при своём останется.
Надеюсь, вы не будете спорить, что есть шарповские решения без аналогов на плюсах? Полезность использования конкретных библиотек под конкретные задачи нужно оценивать из ТЗ.
Не угадали. Грубая оценка — 50% приходится на наши C#-алгоритмы. И я что-то сильно сомневаюсь, что напиши мы всю на плюсах, расклад резко поменялся бы.
Нет, не договоримся мы. Давайте теперь я угадаю: вам не приходилось проектировать и разрабатывать C#-приложения (хорошие приложения, чтобы была грамотная архитектура, с которой удобно работать), размер которых исчислялся в сотнях тысяч строк кода. И маленькое признание: мне не доводилось иметь дело с проектами подобных размеров на плюсах. Очевидно, что вам проще писать на C++, а мне — на C#. При таком раскладе оба наших мнения предвзяты. Невозможно прийти к соглашению бросаясь друг в друга отдельными кусками личного опыта. Увы, подробный анализ ситуации займёт крайне много времени.
Отлично, мы приближаемся к консенсусу. С этим абсолютно согласен. Даже про проекты на пых-пыхе.
А вот тут не соглашусь.
а) Зависит от специфики крупного проекта. Мне доводилось принимать участие в ряде весьма крупных проектов на C#. Работать было легко и приятно, я думал главным образом про дизайн и алгоритмы. Возводить подобное на плюсах я бы в жизни не согласился.
б) Что вы имеете в виду?
в) Тут опять важная специфика, от неё многое зависит. Современный CLR позволяет написать критичные по производительности куски кода так, что по скорости они вполне могут соревноваться с плюсовыми аналогами. Например, я сейчас работаю в проекте по обработке изображений. На низком уровне мы используем базовые методы OpenCV, а основной код (включая большую и хитрую логику по применению различных преобразований и их обработке) целиком написан на C#. Все наши алгоритмы просто летают, в то время как .NET позволяет сделать остальную разработку сплошным удовольствием. В другом проекте я также отвечал за сложные алгоритмы и тяжёлую математику. Пришлось немного постараться, в некоторых местах отказаться от прелестей ООП, но в итоге алгоритмы работают крайне быстро. А знакомые у меня занимаются 3D-рендерингом: 100% C# код написан очень хорошо, а работает настолько быстро, что плюсовые конкуренты нервно курят в сторонке.
Небольшой итог: производительный код на C# вполне писать можно, лишь бы руки из того места росли. Согласен, что есть проекты на которых без С++ никуда. Но они вовсе не обязательно нужны для крупного перфоменс-критикал проекта.
Предлагаю закончить нашу небольшую дискуссию и остановиться на следующей мысли: для каждой задачи хорош свой язык. Есть проекты, которые лучше делать на шарпе, а есть — которые лучше делать на плюсах. При выборе нужно исходить из конкретного чёткого ТЗ. Согласны?