Очень напомнило, как когда-то на 2-ом курсе в качестве курсовика по ассемблеру написали с однокурсником бота, который тоже работает засчёт перехвата функций.
Как внедриться в чужой процесс брали здесь: rsdn.ru/article/baseserv/IntercetionAPI.xml#EIEAC
А вот описанный в той же статье метод перехвата не подошёл, поэтому DirectX многопоточен. Так что преподаватель подсказал сделать как в Detours (гуглить: file:huntusenixnt99.pdf).
Вот видосики, где бот играет, может и про него статью напишем: www.youtube.com/user/thbotproject/videos
Сайт бота: thbot.kt15.ru/
Теперь насчёт технических деталей: мы тоже перехватывали, руками вытаскивая offset из vtable. А потом, когда всё уже сделали, поняли, что можно было C-шное API перехватывать.
ну хотите фактов, давайте обсудим статью и рассмотрим факты:
1) Dryad адаптирован и используется в Bing, Microsoft AdCenter, Kinect, Windows HPC Server 2008 R2 (последнее, известно достоверно).
WTF ??? какой кинект, если мы говорим про кластера и распределенную обработку
2) потому что Dryad — не Hadoop: модель map/reduce — только частный случай для Dryad, в то время как для Hadoop – это единственно возможная модель выполнения.
в заголовке указали, что mr единственным решением был только до появления ярна, а в выводах забыли, нехорошо как-то, под хадуп ярном и обход графа уже запилили и рекурсивные алгоритмы, когда вывод с одной ноды сразу стримом гонится на другую для свертки, не ожидая остальных.
3) сложность адаптации для работы в realtime-режиме
берем spark, для рекурсивных заданий это реально молния, есть проект по замене mesos на yarn из хадупа, в итоге получаем хорошую скорость близкую к реалтайм, заюзав sharkвместо hive еще и sql подмножество хапаем.
А еще для пущего эфекта добавим в кашу такой проект как impala (имеет пачку плюшек для работы с большими данными: mpp, p2p, оптимизированный формат хранения parquet (тоже подглядели у гугла, есть компрессия данных и rle для чисел)).
4) Задание в Dryad runtime представляет собой направленный ациклический граф, где вершины представляют собой программы, а ребра графа – каналы данных
что-то мне это напомнинает, а впомнил, storm от твитера для евент процессинга, но
5) и, вероятно, принципиальная невозможность работы с потоковыми данными.
ЧТО??? О_о имея такую архитектуру не запилить работу с потоковыми данными, особенно на фоне хорошей парадигмы и либы Rx, да они наверное издеваются
6) в Hadoop свертка не может начаться пока все map-задания не будут окончены
верно, дальше на вашем слайде и в описании показано Speculative Execution, когда таск (map или reduce) запускается параллельно с уже имеющимся медленным таском в надежде выиграть время, фича доступна уже в первой версии хадупа.
7) Open-source лицензии, потому что это изначально другой тип продукта (но бесплатный доступ по академической лицензии все же есть);
ой да не смешите, какой другой тип продукта? хотя если вы имели в виду: «продукт для того, чтобы залочить кого на себе и стричь бабло», то тогда я полностью согласен, не тот это продукт.
8) Других заявлений про дальнейшую поддержку Dryad или, напротив, однозначный отказ от поддержки, на протяжении прошлого (2012) и этого года замечено не было.
ага, то есть слов и действий: «для больших вычислений мы будем использовать хадуп, ради того чтобы его под виндой запускать в azure мы даже неплохо бабла отвалим hortonwork» уже недостаточно, чтобы решить что продукт издох. Раз есть devel-preview которая неподдерживается и сорцов нету, то считаем проект живым. Нет, ну неужели вы это серьезно? Имеющиеся (но не доказанные) внедрения на фоне остановки развития продукта вызывают лишь жалость к тем, кто залочился на данном продукте, а соскочить не может.
Сколько раз уже можно повторять: Hadoop — это не MapReduce + HDFS, Hadoop — это ЭКОСИСТЕМА.
так что: ДА, по характеристикам Dryad устарел лет на 10
Koller09 – Probabilistic Graphical Models: Principles and Techniques
Bishop06 – Pattern Recognition and Machine Learning
Bengio14 – не совсем верно, т.к. книга ещё не вышла, но (пока ещё) можно почитать черновик.
Как внедриться в чужой процесс брали здесь: rsdn.ru/article/baseserv/IntercetionAPI.xml#EIEAC
А вот описанный в той же статье метод перехвата не подошёл, поэтому DirectX многопоточен. Так что преподаватель подсказал сделать как в Detours (гуглить: file:huntusenixnt99.pdf).
Вот видосики, где бот играет, может и про него статью напишем: www.youtube.com/user/thbotproject/videos
Сайт бота: thbot.kt15.ru/
Теперь насчёт технических деталей: мы тоже перехватывали, руками вытаскивая offset из vtable. А потом, когда всё уже сделали, поняли, что можно было C-шное API перехватывать.
1) Dryad адаптирован и используется в Bing, Microsoft AdCenter, Kinect, Windows HPC Server 2008 R2 (последнее, известно достоверно).
WTF ??? какой кинект, если мы говорим про кластера и распределенную обработку
2) потому что Dryad — не Hadoop: модель map/reduce — только частный случай для Dryad, в то время как для Hadoop – это единственно возможная модель выполнения.
в заголовке указали, что mr единственным решением был только до появления ярна, а в выводах забыли, нехорошо как-то, под хадуп ярном и обход графа уже запилили и рекурсивные алгоритмы, когда вывод с одной ноды сразу стримом гонится на другую для свертки, не ожидая остальных.
3) сложность адаптации для работы в realtime-режиме
берем spark, для рекурсивных заданий это реально молния, есть проект по замене mesos на yarn из хадупа, в итоге получаем хорошую скорость близкую к реалтайм, заюзав sharkвместо hive еще и sql подмножество хапаем.
А еще для пущего эфекта добавим в кашу такой проект как impala (имеет пачку плюшек для работы с большими данными: mpp, p2p, оптимизированный формат хранения parquet (тоже подглядели у гугла, есть компрессия данных и rle для чисел)).
4) Задание в Dryad runtime представляет собой направленный ациклический граф, где вершины представляют собой программы, а ребра графа – каналы данных
что-то мне это напомнинает, а впомнил, storm от твитера для евент процессинга, но
5) и, вероятно, принципиальная невозможность работы с потоковыми данными.
ЧТО??? О_о имея такую архитектуру не запилить работу с потоковыми данными, особенно на фоне хорошей парадигмы и либы Rx, да они наверное издеваются
6) в Hadoop свертка не может начаться пока все map-задания не будут окончены
верно, дальше на вашем слайде и в описании показано Speculative Execution, когда таск (map или reduce) запускается параллельно с уже имеющимся медленным таском в надежде выиграть время, фича доступна уже в первой версии хадупа.
7) Open-source лицензии, потому что это изначально другой тип продукта (но бесплатный доступ по академической лицензии все же есть);
ой да не смешите, какой другой тип продукта? хотя если вы имели в виду: «продукт для того, чтобы залочить кого на себе и стричь бабло», то тогда я полностью согласен, не тот это продукт.
8) Других заявлений про дальнейшую поддержку Dryad или, напротив, однозначный отказ от поддержки, на протяжении прошлого (2012) и этого года замечено не было.
ага, то есть слов и действий: «для больших вычислений мы будем использовать хадуп, ради того чтобы его под виндой запускать в azure мы даже неплохо бабла отвалим hortonwork» уже недостаточно, чтобы решить что продукт издох. Раз есть devel-preview которая неподдерживается и сорцов нету, то считаем проект живым. Нет, ну неужели вы это серьезно? Имеющиеся (но не доказанные) внедрения на фоне остановки развития продукта вызывают лишь жалость к тем, кто залочился на данном продукте, а соскочить не может.
Сколько раз уже можно повторять: Hadoop — это не MapReduce + HDFS, Hadoop — это ЭКОСИСТЕМА.
так что: ДА, по характеристикам Dryad устарел лет на 10