Здравствуйте, alex_public, Вы писали:

_>Да, и что самое главное... В таком варианте код не только быстрее, но и удобнее. Т.е. в отличие от вариантов во многих других языках, где нам надо уродовать код для достижения производительности, здесь у нас самый красивый код является самым быстрым.
Ровно до тех пор пока не нужна асинхронность

А вообще правильно. Всю математику лучше на C++ (или даже на C, в примерах C++ и не пахнет).

_>А ещё на C++ это всё можно распараллелить на все ядра процессора или вообще посчитать на gpu с помощью добавления одной инструкции (openmp или openacc) над циклом. Но это уже другая тема. Просто вспомнилось в контексте обсуждения максимальной эффективности вычислений. )
В .NET просто меняешь for на Parallel.For

_>Вообще то .net умеет автовекторизацию, правда в самых тривиальных случаях.
Вообще не умет. Ни авто, ни ручную. Давно еще читал статью про JIT, там чувак писал что намеренно отказались от векторных операций, чтобы не получать 100500 разных исполняемых образов под разные процессоры. Только в RyuJIT сделали классы для векторов и компиляцию в векторные инструкции (как в mono).

_>Кстати старый компилятор C# (на моём старом компьютере) справлялся даже с примером выше, но только в unsafe варианте (где он в точности как C++ вариант). А вот новый что-то не может ни в каком варианте. Странно даже. Но в любом случае наличие автовекторизации в компиляторе не поможет на таких примерах без использования unsafe. А поводу смысла программирования на unsafe C# тут уже высказали много чего. )))
Тут наоборот надо повышать уровень абстрации. Был такой проект — accelerator (http://research.microsoft.com/pubs/70250/tr-2005-184.pdf), который позволял описывать вычисления над массивами и матрицами, а потом запускать это все на видеокарте. Даже примеры в интернетах можно найти — http://tomasp.net/blog/accelerator-dataparallel.aspx/.
Все API строилось как раз на операциях с векторами и матрицами, а они потом уже перекладывались в GPU или SSE.
Но, увы, в MS забили на этот проект.