Загрузка...
В связи с моими постами на смарт-лабе, ко мне приходит много вопросов с просьбой дать рекомендации, что можно почитать по алготрейдингу и написанию биржевых роботов. Сразу должен сказать, что адекватной литературы крайне мало как у нас, так и за границей. Понятно, почему - мало кто готов открывать зарабатывающие алгоритмы, тем более, что в них вложено очень много времени и труда, это я знаю по себе. Попробую, все же, назвать несколько книг, которые очень помогли мне в построении роботов.
Сначала основы:
С.В. Булашев. Статистика для трейдеров. Книга была актуальной 10 лет назад, остается такой же актуальной и сейчас. Что такое случайные величины, их законы распределения, регресионный анализ, метод наименьших квадратов, механические торговые системы и управление капиталом - это основы, без которых невозможно построить сколько-нибудь прибыльный алгоритм. К прочтению обязательна для всех трейдеров.
Книги по HFT трейдингу. Прошу прощения, тут все на английском языке, на русском по данной теме нет ничего:
Irene Aldridge. High Frequancy Trading: A Practical Guide to Algorithmic Strategies and Trading Systems. Даны общие характеристики рынков, основы микроструктуры рынка, классификация высокочастотных алгоритмов, риск-менеджмент, бэктестинг и анализ работы программ. В основном все на теоретическом уровне, чтобы понять, что действительно полезно, надо продираться через кучу обобщенной информации. Но направления дает верные.
Ernie Chan.Quantitative Trading: How to Build Your Own Algorithmic Trading Business. В этой книге рассматривается автоматический трейдинг в общем, без упора на высокочастотные стратегии. Но проводится разделение алгоритмов - на импульсные (momentum) и реверсивные (mean-reverting), что актуально для HFT. Также много говорится о бэктестинге, и где черпать идеи для алгоритмов.
Книги по опционам. Опционными стратегиями тоже занимаюсь, поэтому вот книги, которые мне в этом помогают:
М.Чекулаев. Загадки и тайны опционной торговли. Что такое опционы, параметры опционов, математика опционов, в общем основы. Рассмотрено множество опционных конструкций, управление стратегиями, основные понятия торговли волатильностью. После прочтения будете знать об опционах практически все, что необходимо, останется только вникать в детали.
К.Б.Конноли. Покупка и продажа волатильности. Кто хочет строить автоматические алгоритмы с применением опционов понадобится хорошее понимание стратегии торговли волатильностью. В этой книге вы найдете все теоретические основы по этому виду торговли, в ней достаточно сведений и для построения HFT алгоритмов, хотя напрямую они не рассматриваются.
Все остальные знания о высокочастотной торговле придется искать в разрозненных публикациях, как правило англоязычных. Задача этого блога и состоит в том, чтобы систематизировать все эти данные и попробовать на основе них разработать практические алгоритмы.
Для создания роботов необходимо уметь программировать, потому что предлагаемые на рынке высокоуровневые оболочки, как правило, совсем не подходят для создания HFT стратегий. Знание какого-либо языка программирования позволит гораздо более гибко подойти к разработке и учесть тонкие моменты,например, связанные со скоростью выставления ордеров. Я рекомендую начать изучение с C#, который универсален и не очень сложен. Книги, которые мне в этом помогли:
Стиллмен Э., Грин Д.Изучаем C# . Хорошая книга для начинающих. Позволит сразу начать писать реальные приложения на C#.
Д.Рихтер.CLR via C#. Программирование на платформе Microsoft .NET Framework 4.0 на языке C#. Обязательна к прочтению. Объясняются основы функционирования среды исполнения CLR, что необходимо для более глубокого понимания языка.
Мартин Р., Мартин М. Принципы, паттерны и методики гибкой разработки на языке C#. В книге рассмариваются основные паттерны программирования, которые позволяют писать хорошо структурированные программы, что сэкономит немало времени в связи с многократным использованием кода, и увеличат надежность работы, что очень немаловажно для биржевых разработок.
Надеюсь все эти книги помогут вам начать создание собственных прибыльных роботов , в том числе в очень непростом сегменте высокочастотной торговли.
Все таки, думаю, зря Вы на C# людей подсаживаете) Я вот как не стараюсь, а не могу с него на плюсы теперь слезть. Все каким-то неудобным кажется. Тру ХФТ пишется вообще на верилоге) А время C# на бирже уже прошло.
Плюсы конечно неудобные, все таки неуправляемый код. Не согласен, что время C# прошло, для сложных алгоритмов, где не надо ловить миллисекунды, самое то.
Попал на сайт случайно - спасибо Google.
Спасибо автору и Excalibur за то что не постеснялись выложить размышления и результаты трудов на тему товарища Стоикова и других.
Время C# не начиналось и не заканчивается - логичное продолжение имеющихся средств разработки, которые друг друга великолепно дополняют, включая портабельность, межплатформенную разработку, а также развитие алгоритмического мышления? (Model - View - ViewModel - точно можно было продолжить только в C#, если учесть, что GOF - C++ и доступные языки в 1998-1999 г.г.).
В качестве пустяка - ну, неужели не логично с мобильного устройства через удаленный доступ вмешаться в настройки того же алгоритма, базы данных и т.п.? Такой код на C# пишется очень легко и быстро.
Если нужно, то - C++ AMP - через PInvoke; или можно остановиться на CudaFy или ManagedCuda. Уверен, что даже без GPU в большинстве случаев ни SIMD ни AVX инструкции, доступные программису C++, не понадобятся. Производительность кода, выдаваемого компилятором C# практически не уступает из под С++, даже одномерный массив обходится быстрее, библиотека STL как не смешно уступает BCL .Net, хотя большинство библиотек .Net написаны на с++ того же Мелкософта. Так же необходимо отметить, что среда CLR решает за программиста очень много задач: от кэширования интерфейсных вызовов до управления пулом потоков. Сколько сил надо потратить, чтобы все это поднять с нуля, используя доблестный c++? Известен ряд тех.статей, в которых ни Рихтер ни другие товарищи с использованием C++, не смогли обогнать по производительности динамические коллекции .Net BCL. Все сказанное говорилось только о продукции Microsoft.
Но ни машинного обучения, ни элементарного моделирования портфеля без языка программирования высокого уровня не выйдет. Однозначно C# комфортен и для генетического программирования и его дальнейшего продолжения (или модификации) - генетического программирования выражений. Это из практики.
А вот такой вопрос интересный: разрабатывать новый синтаксис языка для команд торгового приложения, или вы разрабатываете маленкий метод C#, куда вначале по умолчанию вставляются все ссылки на необходимые библиотеки, а ваш код описывается в 5-10 строчек, и вы в любой момент имеете возможность его откомпилировать и исполнить с той же скоростью, как и основное приложение (аналог скриптового расширения), но без перестройки основного - на лету в RichTextBox, сохранив или загрузив его из файла?
Или пойдем дальше - в ходе работы алгоритма генетического программирования предложена некая синтаксическая конструкция - вытекающая из дерева, либо просто длинное выражение - которые преспокойно могут быть выражены в терминах того же C# (можно вообще сразу так делать) либо воспользоваться Expressions. Одно касание - проверка синтаксиса компилятором, если нет ошибок, то можно этот откомпилированный метод сразу же вызвать - скорость та же. (это единственное, что у меня пока не реализовано, но однозначно этим должно закончится: пока выгодно оставить в форме подготовленного стэка(списка) выражений, так как из небо удобно делать пулы параллельные задач - но однозначно есть над чем подумать - придется делать обратный разбор, но с точки зрения читабельности - просто супер )
Если отойти от теоретических численных методов и попробовать сделать как минимум визуализацию логического вывода не в алфавитной форме, что уж говорить о создании качественной среды разработки - куда без WPF и MVVM?
В книге Irene Aldridge о HFT четко указано, что ядро NYSE - c++, GUI - java. Но это так сложилось.
Нет ни малейшего сомнения, что C# сейчас бы рассматривался во главе угла. Есть великолепные изыскания в 2-х книгах по производетльности .Net - все вопросы только к программисту. Есть четкие особенности, которых лишен программист C# - прямой вызов ряда функций Windows API. Но как говорилось, очень легко они вытаскиваются через PInvoke C++ dll - это для фанатов оптимизации файлового ввода/вывода: FileStream в С++ тоже медленный, и работа с портами ввода/вывода плюс оптимизация буфера ввода/вывода. Все.
--
Одним контрактом может быть и можно побороться за микросекунды (а может наносекунды), но придется оставаться в пределах линейной регрессии для некоторых задач. Но решить типовые задачки на опционные позиции типа short put, long call, long базовый актив, помоделировать как минимум портфель стратегий уже не выйдет.
--
Если высказался неточно, поправьте.
Но очевидно, что C# и .Net самые совершенные среды разработки. Читаем книгу тех.директора Google: пишет о C#, но плачет так не может на нем работать, тов. Рихтер уже даже не в счет.
К сожалению, не обладаю полнотой информации об использовании специализированных программируемых устройств. Но представляется, что в итоге такие устройства должны исполнять код в режиме реального времени, не отвлекаясь на переключение между потоками выполнения, как, например, это делает Windows. А модель их работы должна быть создана и только потом зашита в их ПЗУ или что там сейчас. Так что сначала среда моделирования/разработки, а потом все остальное.
--
Еще раз спасибо, что не постеснялись поделиться трудами мучительных изысканий.
Спасибо за такой развернутый комментарий,который тянет статью. Может опубликуете ее на этом сайте - для этого нужно просто зарегистрироваться. В основном согласен с вами, но так как я не профессиональный программист, на 100% не знаю, верны ли ваши утверждения. Но точно знаю, что у тех, кто занимается HFT все написано на C++, даже бэктесты. Возможно, это просто привычка 🙂 А вы занимаетесь разработкой торговых алгоритмов?
Я не являюсь профессиональным разработчиком. Но приходилось вести проекты и слушать много лапши.
То что указано - это железобетонные факты статей Дж.Рихтера на MSDN: C# и .Net для С++ программистов и книги "Оптимизация производительности на платформе .Net" .
По поводу Гугла - Джон Скит "C# для профессионалов" - его должность там и указана. Там же он указывает оценку C# так как вынужден работать на Java. Irene Aldridge - вами она преведена только в первом издании. О реализации Nyse указано во втором издании и как ни странно она там впервые указывает на написание HFT алгоритмов на C#.
Сам Дж.Рихтер, Петцольд - известные евангелисты Майкрософт четко указывают, что сами используют уже более 10-ти лет в основном C#, причем все хорошо знают и книги Рихтера о Windows и C++.
У меня лично очень многое реализовано на C# - и уверяю, что, например эконометрические серии у меня считаются быстрее, чем в великом WealthLab от 10-20% быстрее в случае обыкновенной скользящей средней и иногда позорно для WealthLab в разы быстрее в случае статистик. Про полный цикл оптимизации даже говорить не интересно. Могу доказать, мы месяца 3 тестировали с их тех.поддержкой, чей код будет быстрее. Да и просто подгрузив библиотеку и сделав тест.
Можно еще дополнительно отдельно обсуждать классические вопросы кэширования расчетов (повторное использование вычисленных значений), например можно даже некоторые серии выгружать на диск и читать в случае необходимости (если допустим большая кореляционная матрица), если такое действие будет быстрее.
Сколько еще зашито чтении/записи файлов - либо собственная реализация сериализации, либо использование HDF5 формата. Разница может быть в сотни раз.
Существует еще масса классических приемов и рациональных действий после профилировщика.
Все это вполне доступно терпеливому пользователю да и разумному инвестору (вспомним тов. Грэхема).
В итоге, например, зачем нейронные сети вообще использовать, если регрессию и (или) классификацию можно сделать в сотни раз быстрее другими способами. В кубке мира по машинному обучению нейронные сети давно никто не использует. Это же можно просто прочитать.
Это я к тому, что на данной стадии еще не важно C# или С++.
В названном мной книге по оптимизации в .Net авторы показывают, что даже реализацию буферов ввода/вывода можно сделать глупо, а можно в 200-300 раз быстрее библиотечных вызовов BCL. Примеры приводятся на C#, но основой успеха является именно хорошее знание Win API. Я специально коснулся этого вопроса, так как для производительной обработки данных в режиме реального времени скорее больше времени уйдет не на математические методы, а на неоптимальную организацию операций ввода/вывода. Тот же WCF может неудачно использовать сериализацию - результат 100-200 кратная потеря.
Переходя к конкретной реализации уже станет почти не важно C# или C++.
Причем оба C - подобных. Если уж приспичит поработать с указателями, то можно Unsafe попробовать. Но все же лучше данные расположить в памяти последовательно и желательно чтобы они были value type и в этот момент станет уже все равно safe/unsafe.
Среда CLR выполняет сумасшедшую работу - ведь .Net Гейтс лично развивает с 1999 г. как личный проект. Согласитесь 15 лет - это срок.
Но очевидно, что без нормальной постановки задачи, соблюдения принципов - из серии внедрение зависимостей только через консткруктор поломается любая разработка.
А остальное - это дело вкуса.
В конце концов мы ведь говорили о Windows - а она ради отклика слишком часто переключает процессы.
--
Я высказался от души, так как увидел личную заинтересованность и был удивлен кропотливым отношением Ekskalibura по зачистке ряда вычислений.
Что касается - обменяться опытом - я подумаю.
Мой личный интерес - это машинное обучение и очень много сил потрачено на графический интерфейс представления и обработки знаний. Думается, что получилось не сильно хуже, чем в Azure Machine Learning, но нет ограничения только вероятностных и статистических моделей.
А вывод знаний, построение гипотез, и только потом обучение моделей, как мне кажется - это самое интересное.
Простая арифметика: допустим приложение C# или C++ уже откомпилировано и запущено.
Условия таковы : Bollinger Bands - оно же почти из анализа главных компонент: то есть скользящая арифметическая средняя и две границы сверху и снизу по 2 среднеквадратичных отклонения.
Каждый раз на новом значении алгоритм берет и считают серию на 50,000 значениях с периодом 21 по наивным лобовым формулам WikiPedia. Конечно, это бредово - но для данного случая не важно.
Уверяю, что если замерить время выполнения данных расчетов, то оно менее 1 мс.
Даже если 10 раз выполнить такой тестовый прогон, то по замеру будет все ниже 1 мс.
Ничего сложного обрамить код C# вызовами Stopwatch методов.
Идем дальше - ввод/вывод и сериализация/десериализация - ну тут уже вопросы к архитектуре подключения и как построены методы ввода/вывода на стороне торгового приложения. Если 10 инструментов, то можно многого и не заметить. Если весь рынок - есть над чем подумать. Но без особого труда все можно вписать в 1 мс. Главное не пользоваться методами сериализации по умолчанию .Net - там используется тормознутое Reflection.
Далее работа напрямую через Unsafe с буферами ввода/вывода в C# может даже дать возможность написать сервер, раздающий данные 200-м клиентам . Поэтому в случае одного клиента как ни крути даже не думая о глубоких оптимизациях ошибиться и выйти на ощутимые потери еще надо постараться.
Но вот на что влиять почти невозможно - это вопрос времени переключения между процессами Windows - а оно будет чуть повыше. Чем больше процессов, тем хуже. Это нужно четко замерять - но можно вернутся к тов. Рихтеру. Допустим он указывает 2-5 мс для какой-нибудь машины i5-i7 для win7.
Поэтому если говорить о т.н. HFT с временем реакции 2-5 мс - c C# нет и не будет никаких проблем.
--
Вопрос другой классика C++ - это Unix/Linux, которые не имеют названных задержек переключения между процессами. Плюс развитые библиотеки научных параллельных вычислений.
C# можно и там запустить, но это будет Mono реализация, а она по производительности на порядок слабее версии Microsoft.
И если в одном интересном тесте на CodeProject между 10-тью подобными вычислительными тесами С++ / C# с компилятором Microsoft C++ код был шустрее на 2-3 % - сравнение шло .Net 4.0, то Mono проваливался глубоко на 100 %.
Это исключительно пример. Все в руках программиста. Я сам неоднократно сравнивал подобный код C++ и .Net - X64 .Net в среднем оказывался на 2-3% веселее.
--
Но вот где можно ощутить разницу - это оптимизация и бэктест. Но это снова вопрос качества алгоритмов.
Вообще говоря, оптимальный подход - это сочетание необходимых компонентов.
C# в целом гораздо легче сопровождается + вершина проектирования GUI WPF, но полностью совместимое только с Windows.
Вероятно вы очень грамотный программист с огромным багажом знания и опыта. Давайте обмениваться опытом, лично я был бы очень признателен.
Я как и автор сайта не профессиональный программист. При кодировании на с++ сталкиваешься с тем, что элементарная ошибка , к примеру, забыл при инициализации указателя приравнять его к нулю, проявляется в совершенно неожиданных формах, и в режиме дебага подобные ошибки не отлавливаются. Потом целую ночь занимаешься любовью с программой пытаясь понять, что она хочет от тебя. После такой ночи любви, вырабатывается безусловный орфографический рефлекс написания кода. Или неожиданно начинает расти объем памяти отведённый для программы. Вот и ищешь где переменную не удалил, или объект.
Не судите строго, глупого и непрофессионального программиста (меня). Наверное, главное, что бы код был рабочим, и алгоритмы были эффективными. Согласно моих знаний по с# почерпнутых из беседы с крутими программистами, - это превосходный язык, не уступающий по скорости и превосходящий по удобству. Пожалуй реальные прибавки к скорости действительно можно ощутить зная нюансы по обработки векторов и матриц.... Давно изучаю подобную информацию, но так как острой необходимости в увеличении скорости работы алгоритмов нет - пока без особого энтузиазма. Лично я буду очень рад, если Вы будете одним из исследователей и авторов статей на этом сайте. Так как совместная деятельность всегда эффективнее.
Спасибо за столь высокую оценку.
На самом деле я - финансист, когда-то начав свою карьеру на долговом и денежном рынке. Но после долгого перерыва как-то ознакомившись с трудами первопроходца Броуновского движения тов. Башелье, предложившего теорию игры и спекуляций, и опередившего на 5 лет обогнал тов. Эйнштейна, а также вооружившись мнением тов. Герберта Саймона, что первая машина искусственного интеллекта была разработана Аристотелем и она была символьной, решил широко сформулировать постановку задачи:
- возможность оптимизации имеющихся моделей численными методами;
- возможность построения логического вывода (или символьного)
- адекватное представление, хранение и обобщение знаний.
Как оказалось - не я один этим интересуюсь.)
Практическая причина проста - если вывод простых формул типа Пифагора, восстановление стишков Шейкспира - вполне решаемые в режиме реального времени задачи, то почему не попробовать рассматривать более практические цели. Ну, а так как было желание не только получать комбинацию известных математических моделей, но еще и допустить вывод новых, а также помимо предлагаемых на вход признаков или переменных рассматривать и отхождения, то получается, что производительность даже элементарных алгоритмов должна быть высочайшей. Поэтому до истерики дошел не один программист)).
Согласитесь, что вывод формулы Пифагора за 10 с и 10 мс - существенная разница.
Ну а выводами я поделился в том смысле, что нет более дурацких обсуждений. Сначала должен быть алгоритм и постановка задачи.
В действительности разговоров больше, чем квалифицированных результатов.И это первый сайт, где я увидел просто нормальную трудовую попытку оптимизировать модель.
Тогда, с вашего позволения вопрос - я не увидел на сайте публикаций о ядерных методах. Я на них очень большую установку делаю. Приходилось ли вам с ними встречаться в ходе обучения и практики?
Да и как не оптимизировать, время просчёта алгоритма составляет примерно 2 минуты ....
Ну если быть честным то допущения следующие: основные математические операторы, 3 ряда данных. Как сейчас помню первые итерации около 2 мин, далее после оптимизаций и зачисток время упало до 30 сек. В основе лежал генетический алгоритм.
Финишная прямая без замены компьютера, тот же C#, но уже модифицированный эволюционный алгоритм и почти совершенный код - 10 мс .
не слабо так оптимизировать, от 2 минут до 10 мс.
Никаких упаковок/распаковок, строгая типизация переменных и массивов, минимизация копирования в стек при вызове методов, инлайн-вставка методов, недопущение копирования объектов выражений с помощью сериализации....Причем никакого распараллеливания и только желательно в пределах кэша.
Все же еще раз оттестировал вывод формулы Пифагора - на самом деле реальное время работы 1с - 10 с. время зависит от загрузки процессора и генератора случайных чисел. Настройки алгоритма - максимально 5000 эпох, стартовая популяция 50 выражений, на каждой следующей эпохе может быть сгенерировано одно новое выражение, копия лучшего выражения может быть мутирована.
Ради интереса - CsharpCorner - что-то в таком духе.
Проект по-моему назывался GEP или MEP
Посмотрите как бенчмарк сколько он у вас времени займет.
В моем понимании он крайне медленный, а код не оптимален.
Ну и для очистки совести, с учетом уточнения справедливого времени работы алгоритма выражений несколько слов производительности численных методов.
Немного объективной информации по производительности кода неуправляемого из-под компилятора MS VS C++ и .Net для численных методов. Для решения задач регрессии нам нужны матрицы, как для линейной, так и для различных модификаций, включая переход к ядру.
Естественно это важно для построения и проверки гипотез, сокращения количества признаков и т.д. и т.п.
В качестве примера великолепное тестовое решение команды разработчиков C++ AMP на соответствующем блоге Microsoft: Random Traveler.
Это WPF приложение, выполненное на C#, которое посредством Platform Invoke вызывает динамическую неуправляемую библиотеку. Или проще говоря C# обращается к методам C(C++ AMP), осуществляющим умножение двух матриц 607*607 и 2949*2949. Вполне часто встречающиеся примеры в оценке производительности.
Инженерами Microsoft предложено и измерено 3 решения:
1. Последовательный "наивный" алгоритм;
2. Параллельный алгоритм (на самом деле распараллелен обход внешнего индекса) с использованием Task Parallel Library;
3. Собственно полностью распраллеливаемый по количеству ядер графического процессора алгоритм, который так же может полностью использовать ЦПУ, но SIMD инструкции, которые недоступны средствами .Net.
Несколько первых забавных выводов: лобовой алгоритм использует стандартный синактис работы с массивами, параллельный почему-то уже использует небезопасный код, но все же без ссылок.
Результат трехкратного умножения матрицы 607*607:
Алгоритм 1: 0,04 GFLOPS, 22 c; 2-й: 2с, 0,55 GFLOPS; 3-й 1.2 c. 1.08 GFLOPS (использован режим CPU, так как в графическом процессоре нет сомнений).
Так как небозопасный код предполагает загрузку dll библиотеки, то смотреть надо на результат 3-го алгоритма, начиная со второго прогона.
В общем все это выглядит как шикарный рекламный трюк. Так как все же добиться максимальной производительности в работе с многомерными массивами в C# можно добиться только обращаясь к их элементам в небезопасном коде, фиксируя их расположение и через ссылку. Есть еще несколько дополнительных приемов (но отставим их в сторону).
В общем с такими алгоритами матрицу 2949 * 2949 можно пробовать считать только с использованием C++AMP. И то время около двух минут.
Скажу одну ремарку - можно пробовать разные вычислительные мощности, решение можно легко скачать на сайте. Правда надо не забыть поправить парсинг XAML файла, если будет ошибка - все зависит от собственных установок, грубо говоря какой разделитель точка или запятая. Но самое интересное дальше .
Почистив код, а точнее заменив полностью на Unsafe, ссылки, обход строк матрицы в разбивку по блокам, соответствующие кэшу L1 процессора (в целях отсутствия промахов кэша)появились забавные результаты:
1. Последовательный алгоритм стал летать со скоростью 0,88 GFLOPS - неплохое ускорение, неправда ли?
2. Параллельный TPL * 1.2 GFLOPS - то есть стал даже чуть шустрее кода якобы, использующего SIMD инструкции процессора. Естественно загрузка 100% всех 8-ми ядер.
--
Иными словами от C# явно уже добиться ничего большего не выйдет.
Интереса ради скачал AlgLib, набрал в строке поиска unsafe - нет совпадений.
Поэтому даже смотреть бесплатную библиотеку не имеет смысла. Так как обогнать работу с указателями в C# в многомерном массиве невозможно.
--
Берем в руки самурайский меч C++, пробуем снова наивный алгоритм, параллельный....векторизацию. Но вызываем все в том же коде C#.
2 GFLOPS, векторизация - 3! и никакого параллельного Parallel.For, ... еще пару идей и 5.13 GFLOPS! Конечно, была попытка распараллелить цикл обхода последовательных блоков памяти, но результат не идет ни в какое сравнение с исполнением последовательных вычислений в векторных регистрах процессора с оптимизацией обращения к кэшу.
И все ядра свободны, видна частичная нагрузка только на одном ядре!
В общем результат впечатляет: на той же машине: 5,13 GFLOPS, 300 ms для алгоритма 3-х кратного умножения матрицы 607*607, 2949*2949 тоже три раза за 30-35 секунд... То есть мы вполне себе может нагрузить все ядра, на каждом из которых будет выполнять последовательный код....То есть положим 3x-4x ускорение в зависимости от нагрузки и на 8-ми ядрах, то есть мы вправе рассчитывать на на минимальное ускорение 24x по сравнению с самым лучшим вариантом C#. Почему 3x, а не 4x на одном ядре - никогда не будет линейного эффекта.
Наивные алгоритмы обсуждать не имеет смысла, то есть разницу в сотни раз, так как очевидно, что ими никто никогда не будет - только для проверки правильности оптимизированных версий.
А вот функции векторизации (если алгоритм вычисления предполагает такую возможность), к сожалению доступны только программисту C/C++. Но вызов такого метода в C# осуществляется очень легко.
Если сравнивать итоговое время всех оптимизаций - запустили глубокий поиск признаков и моделей в 8-ми гипотезах, допустим, то эффект такого запуска в случае чистого C# очевидно будет гораздо выше 24x. Там будут дополнительные эффекты. При полной загрузке можно ожидать итоговых эффектов и в 100 и выше раз в случае, например, если будет задействоваться под 100% памяти.Но отставим их обсуждение.
Вот теперь, пожалуй, все.
Но, самое интересное только начиналось. Вышел кандидат Visual Studio c .Net 4.6:
Типы с поддержкой SIMD
Пространство имен System.Numerics теперь включает несколько типов с поддержкой SIMD, таких как Matrix3x2, Matrix4x4, Plane, Quaternion, Vector2,Vector3 и Vector4Vector4.
.NET Native
Приложения Windows для Windows 10, ориентированные на .NET Core и написанные на языке C# или Visual Basic, могут воспользоваться преимуществами новой технологии, компилирующей приложения в машинный код, а не в IL-код. Они создают приложения, которым присуща более быстрая загрузка и время выполнения. Дополнительные сведения см. в разделе Компиляция приложений с помощью .NET Native. Общие сведения о .NET Native и рассмотрение отличий такой компиляции от компиляции JIT и NGEN, и ее влияние на код см. в разделе .NET Native и компиляция.
Приложения компилируются в машинный код по умолчанию, если компиляция выполняется с помощью Visual Studio 2015. Дополнительные сведения см. в разделе Начало работы с .NET Native.
Причем, речь идет не только о новых типах данных, но и методах, включая набор операций линейной алегбры, оптимзированных под SIMD.
В VS2015 во всех вариантах обхода массивов при сложении векторов в С#: стандартная нотация, параллелизация, блочный вариант, по ссылке и т.д. - увеличение производительности 2,2 - 4х. Причем реализация т.н. циклов с внутренним маленьким телом и внешним обходом через Parallel.Foreach Partitioner получило минимум ускорение 8х. А в определенных случаях при настройке блоков под кэш до 30х.
C# алгоритмы умножения матриц из теста Random Traveler после компиляцией под VS2015 с тех. блога Microsost, которые были переписаны, но замеры производительности оставлены без изменения, ускорились в 3,5х.
Для кода c++ умножения матриц улучшений производительности не обнаружено.
При внимательном изучении блога соавтора книги "Оптимизация производительности .Net" тов. Голдштейна можно обнаружить, что т.н. векторизация SIMD протестированная в Net 4.5.2 не дала улучшения при тесте умножения матриц.
---
Вывод таков: Планирование использования средств компилятора можно осуществлять только при четкой постановке задачи и качественном тестировании.
В ряде задач удалось достигнуть производительности сопоставимой и немного выше, чем со средствами компилятора C++. Это идет речь о параллелизации цикла с применением авто разбивки Partitioner.
Конечно, не совсем корректно говорить об итоговых преимуществах C# перед C++ или наоборот, так как все библиотеки C# изготавливаются на C++, но все дело в том, что C# - это уже готовый к использованию объектно-ориентированный инструментарий со своими мощными библиотеками, готовыми к использованию.
И если быть честным, то если товарищи из Микрософт доведут возможность использования SIMD оптимизации в C# до логического конца, то к С++, а точнее даже к C будет иметь смысл обращаться только в стыковочных точках.
Причем CLR среда гарантирует наилучшее исполнение кода на физической аппаратной платформе, а это значит, что приложение будет использовать те же SIMD оптимизации на Intel и AMD платформах, причем код пишется разработчиков только один раз. В случае же C++ - надо на каждую платформу откомпилировать свой код (библиотеку ), перед выполнением определить среду, загрузить необходимую библиотеку...В общем в Net и C# в частности такие действия упрощаются.
--
С учетом изложенного грех не протестировать несколько регрессий (или классификаций -кому как нравится) по различным признакам и ансамбли решений по ним. Только вопрос один - всегда ли есть взаимосвязи? Мой личный настрой на онлайн-обучение и на попытку получения вероятностей событий выше 80%. А что под нее подводить: шансы на выгрыш выше 1/5, 1/10 в сравнении с возможной просадкой по сделке или иные подходы - это тот самый выбор признаков и целевых функций, отбор которых тоже неплохая задача для математика или в терминах тов.Грэхема "активного" инвестора.