Насчет п.2 спорить бесполезно, ибо холивар. Если есть какие-то конкретные вопросы, можно обсудить.
Но в целом, мой совет про аллокаторы (не ТС, а всем): необходимо попробовать различные аллокаторы (tbbmalloc, TCMalloc, jemalloc, parallel_allocator, hoard, etc.) и использовать тот, который больше всего устраивает устраивает для этого конкретного приложения или ворклода.
1. scalable_allocator идет под лицензией GPLv2 with runtime exception + Commercial. Лицензии использования алгоритма, представленного в топике не указаны.
2. scalable_allocator использует всю мощь tbbmalloc, который работает в бэкэнде, и соответственно работает на всех платформах, куда запортирован tbbmalloc.
этот модуль будет использовать CRT аллокатор с выделенным пулом памяти. Это всё равно, что построить обе library.dll и test.exe со статическим рантаймом и пробовать выделять/освобождать память в разных модулях. Классический «cross module boundaries hell».
Первый вариант («патч msvcrt»). Поскольку у каждой студии свой рантайм (msvcrt70.dll,msvcrt71.dll...,msvcrt120.dll,ucrtbase.dll), я указал «рантаймы» во множественном числе. Они все меняются одновременно. Соответственно, если какая-то новая библиотека, которая загружена позже через LoadLibrary(), использует тот же рантайм, что был уже перегружен при запуске программы, то эта новая библиотека будет использовать перегруженный аллокатор. Если же используется какой-то новый рантайм, в котором аллокатор не перегружен, то при определенных обстоятельствах неправильного использования можно столкнуться со знаменитым «cross module boundaries hell».
мы переопределяем маллос и в всех студийных рантаймах, приложения (msvcrt*.dll), которые подняты при старте подмены аллокатора. Т.е library.dll и test.exe будут использовать один и тот же аллокатор.
Более того, если используется «плохой стиль» + library.dll и test.exe собраны разными студиями («не повторяйте этого дома»:)), тогда всё равно будет использоваться один подмененный аллокатор.
у теслы нет графического выхода, это не графика, а числодробилка. С натяжкой её можно назвать GPGPU, поскольку там такая же CUDA, как на «нормальном джефорсе», только число блоков обработки и рабочая частота поболее.:)
Ответил выше, есть сомнения насчет производительности на текущий момент в таких кейсах.
Сомнения есть всегда и это хорошая мотивация для экспериментов тем, кому это надо.
Кому-то хватит производительности OpenCV на эдисоне для своих задач, а кому-то будет недостаточно и 4х-голового xeon с парой xeon phi или tesla карточек. Кстати, на таком сервере тоже высокопроизводительной графики нет.
Эта статья для тех, кто считает, что ему может хватить текущей производительности эдисона.:)
Не совсем понял, причем тут графика и IoT. Графика вроде больше к мобильному сегменту относится.
Смысл запуска на борде: например, разработка ПО для распознавания лиц, подсчета уникальных посетителей в магазинах, и прочих вещей из мира IoT. Причем с использованием оптимизаций IPP для эдисона и авто-распараллеливания через TBB, поскольку эдисон двухъядерный.
Относительно корпусов и железа в целом — это, скорее, вопрос к производителям железа. Здесь же, как писала SvetlanaGEm в заминусовоном комментарии, платформа, для прототипирования и понимания требований, которые необходимы конечным интеграторам. И здесь два решения для пользователей такого железа: придумать на ранней стадии, как это использовать, продуктизировать и «снимать сливки», или ждать, пока появятся готовые железные решения и использовать их.
то в банкоматы и другие встраиваемые устройства уже можно будет вставлять такие платки, а не запихивать целый системный блок… Правда до этого момента что Intel что RPi еще долго расти и наращивать производительность своих дохлых плат…
Виндовс уже и на кварке заводится, habrahabr.ru/company/intel/blog/218107. Эдиссон пошустрее будет. Так что банкоматы/кассовые машины должны, в принципе, работать.
Здесь 2 основных преимущества над OpenCL:
1. «Single source» — не надо специальные исходные файлы создавать с кодом для устройств.
2. нативная поддержка C++.
«не очень прозрачно» в этой статье можно сказать про примеры кода с тайлингом. Но в этом плане, если оптимизировать OpenCL код под какое-то конкретное устройство, то и тайлинг будет и лишние буфера, чтобы шина не вставала, когда разные устройства обращаются в память.
Но в целом, мой совет про аллокаторы (не ТС, а всем): необходимо попробовать различные аллокаторы (tbbmalloc, TCMalloc, jemalloc, parallel_allocator, hoard, etc.) и использовать тот, который больше всего устраивает устраивает для этого конкретного приложения или ворклода.
2. scalable_allocator использует всю мощь tbbmalloc, который работает в бэкэнде, и соответственно работает на всех платформах, куда запортирован tbbmalloc.
www.intel.com/content/dam/www/public/us/en/documents/research/2007-vol11-iss-4-intel-technology-journal.pdf
Я так понял, что это тоже самое, что было реализовано в этой статье.
Более того, если используется «плохой стиль» + library.dll и test.exe собраны разными студиями («не повторяйте этого дома»:)), тогда всё равно будет использоваться один подмененный аллокатор.
www.threadingbuildingblocks.org/docs/help/index.htm#tbb_userguide/Windows_C_Dynamic_Memory_Interface_Replacement.htm
software.intel.com/sites/campaigns/nest
Сомнения есть всегда и это хорошая мотивация для экспериментов тем, кому это надо.
Кому-то хватит производительности OpenCV на эдисоне для своих задач, а кому-то будет недостаточно и 4х-голового xeon с парой xeon phi или tesla карточек. Кстати, на таком сервере тоже высокопроизводительной графики нет.
Эта статья для тех, кто считает, что ему может хватить текущей производительности эдисона.:)
Смысл запуска на борде: например, разработка ПО для распознавания лиц, подсчета уникальных посетителей в магазинах, и прочих вещей из мира IoT. Причем с использованием оптимизаций IPP для эдисона и авто-распараллеливания через TBB, поскольку эдисон двухъядерный.
--Владимир
Виндовс уже и на кварке заводится, habrahabr.ru/company/intel/blog/218107. Эдиссон пошустрее будет. Так что банкоматы/кассовые машины должны, в принципе, работать.
1. «Single source» — не надо специальные исходные файлы создавать с кодом для устройств.
2. нативная поддержка C++.
«не очень прозрачно» в этой статье можно сказать про примеры кода с тайлингом. Но в этом плане, если оптимизировать OpenCL код под какое-то конкретное устройство, то и тайлинг будет и лишние буфера, чтобы шина не вставала, когда разные устройства обращаются в память.