LenkaKorotok,

1. Писать на языке которой компилируется только в управляемый код - C#, VB.NET и т.п.

2. Писать на языке которой компилируется только в машинный код - C++, С и т.п.

3. Тут есть варианты: а) пишем на C++ with managed extensions; б) часть кода пишем на C#/VB.NET, другую на C/C++ и взаимодействуем друг с другом через P/Invoke, COM, COM+ и другие методы межпрограмного взаимодействия.

4. Почти никак. В случае с Express редакциями придется несколько версий ставить и возможно будет неудобно работать.

LenkaKorotokУ меня в проекте переключатель CLR в положении "не используется", поэтому код полностью неуправляемый. Это хорошо, так как работает в разы быстрее.
Производительность программы зависит не только от того какой у нас код - машинный или управляемый. В первую очередь важна квалификация программиста. Кроме того ты забываешь что производительность программы не единственная важная метрика. Скорость разработки и удобство сопровождения тоже важны.

LenkaKorotokНашла этот чудный тест: http://www.rsdn.ru/forum/flame.comp/2720100?tree=tree
Интересный тест, который ничего особо не демонстрирует на самом деле. Во-первых, код на C# не эффективный. Простая замена строки в классе MatrixDouble на моей машине дало выигрыш в 8 секунд (15 против 23):


Использование unsafe кода и указателей тоже должно добавить скорости. (хорошая иллюстрация насчет квалификации программиста). Вполне возможно что в С++ коже тоже есть "косяки", которые могут ускорить работу.

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

В третьих, если нам нужно решать вычислительную задачу, то почему бы не выбрать язык предназначенный именно для таких задач? Fortan, APL или специализированный математический пакет.

LenkaKorotokКстати, а верны мои логические размышления о сравнении производительности управляемого/неуправляемого кодов по производительности С#/С++ ? А то может управляемый С++ не уступает по производительности (или даже превосходит) неуправляемый код (и падение производительности- шарповский косяк)?
Использование управляемого кода разумеется имеет свою цену, но одновременно несет и пользу. Вопрос производительности следует рассматривать в контексте конкретной задачи стоящей перед тобой иначе это будет разговор о сферическом коне в вакууме.

LenkaKorotokВедь там "на лету" идет интерпретация MSIL в команды процессора
MSIL не интепретируется, а компилируется по мере необходимости в машинный код JIT-компилятором. Происходит это один раз в течение выполнения программы.

LenkaKorotokВедь там "на лету" идет интерпретация MSIL в команды процессора и можно более эффективно использовать ресурсы (тот же анализ свободных регистров процессора, который при неуправляемом коде выполнить невозможно)?
Ты заблуждаешься. Компиляторы С++ выполняют оптимизацию кода. В Visual Studio, например, есть режим Whole Program Optimization (или Link Time Code Generation) в задачу которого и входит глобальная оптимизация кода в том числе и на уровне регистров.

Разница между неуправляемым и управляемым кодом в том что неуправляемый код изначально заточен (оптимизирован) под определенный процессор, а MSIL переводится в машинный код на клиентской машине и следовательно у нас есть возможность оптимизировать код под конкретный процессор. В том числе под тот который не еще существовал в момент создания программы. Кроме того MS постоянно вносит изменения в CLR/JIT направленные на улучшение производительности и наши программы могут начать быстрее без всяких усилий с нашей стороны.

Dimitry SibiryakovbazileИспользование unsafe кода и указателей тоже должно добавить скорости.
Прэлестно... Чтобы ускорить управляемый код, надо превратить его в неуправляемый. Ню-ню...
Это не превращение управляемого в неуправляемый, а использование всех возможностей языка. Это особенно важно раз речь идет о производительности.

LenkaKorotokДавайте про сравнение С++ управляемый / неуправляемый. Там я поболее понимаю, и абсолютно одинаковый код выполняется разное количество времени.
Логично предполагать что неуправляемый C++ будет быстрее управляемого из-за отсутствия дополнительного слоя в виде CLR/JIT. С другой стороны, если программист решает использовать управляемый C++, то он делает это не просто так, а ради какого-то улучшения. Например, ради сборщика мусора. То есть он жертвует одним ради другого.

LenkaKorotokА чем С++ плох? Я реализовала нужные мне классы умных массивов и очень рада этому мегаудобству.
Я не говорил что C++ плох, а что выбор языка программирования диктуется, в том числе условиями конкретной задачи которую нам необходимо решить. Если задача это перемножение матриц - то есть математическая задача, то почему бы не выбрать язык программирования созданный специально для решения математических (вычислительных) задач?

LenkaKorotokbazileMSIL не интепретируется, а компилируется по мере необходимости в машинный код JIT-компилятором. Происходит это один раз в течение выполнения программы.
В нашем случае перемножения матриц этот довод имеет какое-то значение?
Это важно для понимания платформы.

LenkaKorotokЧто мешает собрать код на клиенте?
Ничего не мешает, но для этого тебе придется а) отдавать клиенту полные исходные тексты своей программы и все необходимые библиотеки и б) включать в состав дистрибутива компилятор C++.

LenkaKorotokТа же 1с всем устанавливает клиентское ПО?
Ты похоже путаешь клиентское ПО, с ПО компилируемом на стороне клиента. Есть, например, веб-сервер Apache. Серверное приложение по своей сути. Но мы можем скачать его исходные тексты и откомпилировать его локально.

LenkaKorotokНасчет изменений от MS- разработчики компиляторов тоже вносят изменения, и наши неуправляемые программы тоже могут начать работать быстрее.
Разумеется с каждой новой версий VS поставляется все более и более изощренный компилятор C++, но этот компилятор находится на машине разработчика. Следовательно тебе необходимо обновить VS, перекомпилировать программу, распространить её клиентам, которые должно заново установить её. В случае же .NET клиент обновляет .NET (нередко автоматически через Windows Update) и все установленные программы сразу могут начать быстрее.

Dimitry SibiryakovУправляемый код должен быть полностью safe.
С таким же успехом можно утверждать что "код на С++ должен использовать только STL". unsafe код и указатели это часть языка C# о которой надо знать и пользоваться тогда когда это необходимо. В случае с перемножением матриц эта возможность может оказаться полезной. Авторы языка включили ключевое слово unsafe в состав языка не ради красоты, а чтобы в тех ситуациях когда нам нужен прямой доступ к памяти (редкая ситуация) мы могли это сделать.

Кроме того утверждение "Управляемый код должен быть полностью safe" не выполняется даже для встроенных типов. Часть методов класса System.String помечены как unsafe и мир не рухнул.

Dimitry SibiryakovЕсли разрешить unsafe конструкции, он перестаёт быть управляемым со всеми вытекающими.
Мы говорим о C# код на котором всегда компилируется в IL код. Машинных инструкций для нашего кода в программе созданной компилятором C# нет. Данный код (safe или unsafe) в любом случае выполняется внутри CLR, его так же компилирует JIT компилятор, данные хранятся в управляемой куче, механизм безопасности .NET работает тоже одинаково. Так что я не понимаю как использование unsafe конструкции делает код неуправляемым.

Dimitry SibiryakovНет, это хаки, понижающие управляемость языка для того, чтобы он годился на что-то большее чем "Hello, World".
То есть это уже не неуправляемый код, как раньше? :)

Dimitry Sibiryakov,

bazileDimitry SibiryakovЕсли разрешить unsafe конструкции, он перестаёт быть управляемым со всеми вытекающими.
Так что я не понимаю как использование unsafe конструкции делает код неуправляемым.
Дополню свой ответ. Возможно ты имел в виду, что в unsafe контексте возможны операции, которые запрещены в ином случае. Например, выход за пределы массива при использовании указателя на него. Это конечно потенциально опасная операция, но она не делает код неуправляемым.