Интересует следующий вопрос. На сколько оптимально, рационально с точки зрения:
- надежности реализации
- дальнейшего усовершенствования системы 

использовать C# для низкого уровня, по сравнению с С++.

Пример задач:
- Обработка данных с некоторых периферийных устройств (приборов), т.е. не стандартных девайсов.
- Скорость обработки большого кол-ва математических расчетов. 
- ПО, работающее по прослушки телефонной линии, как АОН, с выводом инфы на терминал.
- Организация параллельности и распределенности решаемых задач на суперкомпьютерах.

Как вы видите, круг задач описан, так что Holy Wars отменяются.

 Зачем использовать инструмент для тех задач для которых он не предназначен... Ты же не забиваешь гвозди отверткой... Можно конечно к C# - проекту подключить unsafe код, но зачем тогда вообще трогать .NET. 
 Кстати по поводу

был недавно удивлен заявлением MicroSoft о том, что C# очень даже неплохо с этим справляется... Потестил сам 
(Замерял время выполнения достаточно разнообразных операций над массивом). Шарп С++ не обогнал , но был близок...)))
что то вроде 5% отстования по времени... Это и понятно ... измерения ведь выполняются в откомпилированном JITerom коде...

Значит, как я понимаю, С# не предназначен для низкого уровня без извратов?
ЗЫ: С C# совсем не работал, только сейчас начина, поэтому возможности его не знаю.


Интересуют более сложные задачи...

Здесь полный порядок.

Вот почему о производительности ничего не сказано - непонятно. Хотя, при должной оптимизации (unsafe-код, stackalloc для буферов данных, типизация) будет работать "ну почти как" код скомпилированный из С++, использующий те же API для работы с железом. Самый-самый низкий уровень (тот, что на DDK) можно вынести в native DLL.

Встречный вопрос - почему C#?

Однозначно рулит C++/ASM, желательно с оптимизацией под конкретный процессор. Почему никто не пишет кодеки типа XviD на дотнете или жабе? Потому что хочешь сделать, чтобы работало быстро - сделай сам (сиречь, на сисемблере + SSE + MMX etc), а не полагайся на рантайм.


По поводу распараллеливания и использования нескольких ядер/процессоров/машин ничего не могу сказать, всё зависит от архитектуры, по которой строится взаимодействие. Сам по себе дотнет может обеспечивать некую оптимизацию на уровне JIT, но как на самом деле обстоят дела с генерируемым native-кодом, Гейтс его знает.

P.S. к слову, как раз сегодня читал занятную статью на dtf.ru о многопоточности под Win:
http://www.dtf.ru/articles/read.php?id=39888

Применительно к строго вышеизложенным задачам?



Угу, спасибо.



Что такое DDK?


Аналогично.

Т.е., как я понимаю, работу с девайсами крупные мат рассчеты луже организовывать на C++/ASM, а вот интерфейс пользовательского приложения на .NET, в частности C#.

ЗЫ: Как я понимаю, то что написано на C# под юниксовами системам не поднимется? Или можно как-то MSIL сделать?

Mono — подымется, но с ограниченными возможностями (в частности, реализация WinForms пока в глубокой альфе), да и с производительностью у Mono проблемы.

Driver Development Kit

Боюсь, ни о каком автоматическом распараллеливании на уровне JIT или на каком либо ещё речь не идёт.

На чём основано это утверждение ?

И что ты понимаешь под автоматическом распараллеливании? Лично у меня это в голове не укладывается. Как мне какжется распараллеливание делается программно. Другое дело, что программа должна держать нити процесса...

На здравом смысле. Работы в области автоматического распараллеливания ведутся уже десятки лет, но сколько нибудь приличных результатов никто не добился, даже на функциональных языках, наилучшим образом подходящих для этой задачи из-за отсутствия разделяемых и изменяемых данных. А всё, что сейчас есть для императивных — это полуавтоматические средства вроде OpenMP.
Если бы JIT в .NET умел что-то подобное, MS уже трубила бы об этом всему миру.