Здравствуйте, ins-omnia, Вы писали:
I>>В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.
IO>Тут хорошо бы уточнить, какие задачи подразумеваются. Если посмотреть на процессы, работающие на типичном десктопе, десяток тредов там норма, и понятно, что это ни о чем не говорит.
В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер
Я думаю скорее стоит ожидать появления специализированых процессоров например для ио
Если часть функций ос вынести в железо, это даст не слабую масштабируемость
Здравствуйте, Ikemefula, Вы писали:
I>В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.
Для десятков физических тредов нужны тысячи логических потоков, чтобы адекватно загрузить всё это. Сейчас основные бока в том, что переключение потоков ядром оч тяжелое, поэтому в бусте одна из активно развивающихся либ — корутины. Т.е. настоящие корутины, а не автоматы, сгенерённые с помощью async/await.
Т.е. характерен тот момент, что корутины для нейтива что они есть, что их нет — абсолютно пофиг для остальной программы, в отличие от того же дотнета, которому нужен детерминированный стек для нормальной работы GC.
Единственно что для нейтива требуется — это для каждого вида механизма, на котором можно что-то ожидать в блокирующем виде, написать специальную ф-ию ожидания, которая будет переключать корутины в кооперативной манере, если ожидание приведет к блокировке текущего потока исполнения. А этих механизмов всего 5 видов — примитив синхронизации (семафор/мьютекс/HEVENT), другой поток/фибер, дескриптор файла, сокет (для линухов сокет и файл — одно и то же) и некая очередь сообщений (типа IOCP, сообщений для GUI-окошка или сообщений для юзер-мод драйвера).
Здравствуйте, Mamut, Вы писали:
M>100500 уже нереально. С этим (первым?) столкнулся Erlang, которому, казалось бы, сам бог велел быть впереди планеты всей на этом фронте. Ан нет. Банальная синхронизация и менеджмент процессов на 100500 ядер накладывает нехилые проблемы, что приводит к жутким просаживаниям по производительности.
Это проблемы не Эрланга, а SMP-архитектуры. Про эту архитектуру с самого начала было известно, что она нацелена на небольшое кол-во процессоров/ядер, т.к. основной затык в ней — в аппаратуре, поддерживающей когерентность видимых процессорам данных + дорогое переключение контекстов при вытесняющей многозадачности.
Предлагаю взглянуть на старый Эльбрус или Крэй, с их несимметричной архитектурой. Простая вытесняющая многозадачность на тех процессорах была бы крайне неэффективной, т.к. логический вычислительный поток занимал оч много регистров из файла регистров, при том, что сам файл регистров состоял из различных видов этих регистров — от обычных 64-хразрядных, до 64х64бит векторов. Эффективно всё это использовать можно было только в пакетном режиме вычислений.
Уже сейчас понятно, что дальнейшее развитие многопоточности будет идти через усложнение архитектуры SMP. Например, суперкомпьютеры, которые ранее делались на процессорах Sun или HP, давно показали, как надо строить такие системы: это "двухярусная" система, где на первом "ярусе" располагаются SMP-узлы (порядка 16-32 ядер на узел), а на верхнем "ярусе" — транспортная шина некоей топологии, объединяющая эти узлы + специальный шедуллер, раскидывающий задачи по узлам. Сама система при этом получается гетерогенная, т.е. один/несколько узлов зарезервированы для работы системы, а все остальные рассматриваются как вспомогательные (современный аналог происходящего — GPU, типа как в Cell/PowerPC).
Получается, что "основной блок" может работать в режиме привычной вытесняющей многозадачности, а режим работы остальных блоков больше походит на пакетную обработку. Примерно так же получается в случае вычислений на GPU, при использовании GPU как "сопроцессора".
Современные же т.н. "суперкомпьютеры" — это то, что будет впоследствии высмеяно потомками, причем громко и по-конски. Современный "суперкомпьютер" — это узлы на основе какого-нить топового x64-процессора от Интел + GPU от nVidia + гигабитный Ethernet м/у ними. Эти т.н. "суперкомпьютеры" построены по принципу "я его слепила из того, что было". В отсутствии специализированного транспорта для памяти, берут Ethernet и огонь. ))
Кароч, современный отрыв в производительности настольных процов от производительности "классических серверных процов" сделал своё дело — сервера строят на процах и периферии от десктопов. Т.н. "серверные" процы от интел — это модификации ядер десктопных процов, где вся модификация сводится к большему кол-ву кеш-памяти и кол-ву каналов для внешней памяти.
С другой стороны, падение спроса на десктопы и постепенное перемещение вычислений в web могут подстегнуть создание более специализированной для серваков архитектуры. Не удивлюсь, если это сначала сделают у нас. )) Не зря наш Эльбрус-3 когда-то растащили сначала на Crusoe от Transmeta, потом на сановские процы, потом на Itanium от Intel.
Здравствуйте, Ikemefula, Вы писали:
IO>>Тут хорошо бы уточнить, какие задачи подразумеваются. Если посмотреть на процессы, работающие на типичном десктопе, десяток тредов там норма, и понятно, что это ни о чем не говорит. I>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер
В пакетном режиме вычислений, однако.
I>Я думаю скорее стоит ожидать появления специализированых процессоров например для ио I>Если часть функций ос вынести в железо, это даст не слабую масштабируемость
В случае с обычным произвольным вытеснением никакой масштабируемости не будет по определению.
Здравствуйте, vdimas, Вы писали:
I>>В том то и дело, что нужны более серьезные инструменты, нежели нынешние, для десятка тредов.
V>Для десятков физических тредов нужны тысячи логических потоков, чтобы адекватно загрузить всё это.
Наоборот, потоков вообще не нужно для этого. Смотри на видеокарту — винде не надо создавать по 3 тысячи потоков если в видеокарте 3 тысячи ядер
V>Т.е. характерен тот момент, что корутины для нейтива что они есть, что их нет — абсолютно пофиг для остальной программы, в отличие от того же дотнета, которому нужен детерминированный стек для нормальной работы GC.
Смешное утверждение. Файберы могут работать с дотнетом. Принципиальной разницы нет. Если GC может сканировать стек, то может сканировать и стек короутин. Ничего военного.
V>Единственно что для нейтива требуется — это для каждого вида механизма, на котором можно что-то ожидать в блокирующем виде, написать специальную ф-ию ожидания, которая будет переключать корутины в кооперативной манере, если ожидание приведет к блокировке текущего потока исполнения.
Вся идея короутин в отсутствии ожиданий. Короутина ничего и никого ждать не должна. Все тяжелые блокирующие вызовы нужно отфутболивать в тред-пул, а шедулер будет брать следующую короутину. Отсюда ясно, что проблема вовсе не в примитивах синхронизации, как ты тут утверждаешь. Т.е. все дело в том, сколько тактов нужно потратить на вызов следующей короутины, а не в том, какие механицмы синхронизации у кого есть.
Здравствуйте, vdimas, Вы писали:
IO>>>Тут хорошо бы уточнить, какие задачи подразумеваются. Если посмотреть на процессы, работающие на типичном десктопе, десяток тредов там норма, и понятно, что это ни о чем не говорит. I>>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер
V>В пакетном режиме вычислений, однако.
И что тебя смущает ?
I>>Я думаю скорее стоит ожидать появления специализированых процессоров например для ио I>>Если часть функций ос вынести в железо, это даст не слабую масштабируемость
V>В случае с обычным произвольным вытеснением никакой масштабируемости не будет по определению.
Здравствуйте, alex19, Вы писали:
A>Так что серьезного роста количества ядер в процессорах для решения широкого круга задач в ближайшее время не предвидится (без серьезного прорыва в какой-либо технологии, связанной с работой CPU). Нужно либо найти способ увеличить кеши на той же площади кристалла, либо научиться работать без них.
А что благородные доны думают про Xeon Phi? 60 ядер и всё такое...
_____________________
С уважением,
Stanislav V. Zudin
SVZ>А что благородные доны думают про Xeon Phi? 60 ядер и всё такое...
Практически нет задач, которые будут нагружать хотя бы половину из этих ядер. По разным причинам — от отсутсвия задач до неподготовленности ОСей, программ, языков программирования и программистов
У нас вот на работе в продакшне 80-ядерник стоит. Максимум 10% CPU, максимум 4 ядра заняты (сейчас, вроде, ухитрились 8 заставить работать ).
Здравствуйте, Mamut, Вы писали:
M>Практически нет задач, которые будут нагружать хотя бы половину из этих ядер. По разным причинам — от отсутсвия задач до неподготовленности ОСей, программ, языков программирования и программистов M>У нас вот на работе в продакшне 80-ядерник стоит. Максимум 10% CPU, максимум 4 ядра заняты (сейчас, вроде, ухитрились 8 заставить работать ).
Мы еще только собираемся прикупить такой агрегат.
У нас есть чем его загрузить — электродинамическим 3Д-солвером
Но, как выше верно говорили, отдельную задачу не распараллелить, алгоритмы не позволяют, но зато можно разом запустить целую пачку однотипных задач.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Ikemefula, Вы писали:
I>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер
В смысле ядер, соединенных сетью? Это уже не многопоточность, а нечно на порядок сложнее.
I>Я думаю скорее стоит ожидать появления специализированых процессоров например для ио I>Если часть функций ос вынести в железо, это даст не слабую масштабируемость
Сетевые карты, обрабатывающие внутри себя TCP — это оно, или что-то другое?
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Ikemefula, Вы писали:
I>>>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер V>>В пакетном режиме вычислений, однако. I>И что тебя смущает ?
Что это плохо ложится на современные SMP-системы "общего назначения".
Здравствуйте, Ikemefula, Вы писали:
V>>Для десятков физических тредов нужны тысячи логических потоков, чтобы адекватно загрузить всё это. I>Наоборот, потоков вообще не нужно для этого. Смотри на видеокарту — винде не надо создавать по 3 тысячи потоков если в видеокарте 3 тысячи ядер
Это зависит от вида алгоритма. В видеокарте, считай, все тыщщи ядер выполняют один и тот же алгоритм, просто над разными участками данных.
Кароч, это спор о видах пареллелизма.
Я имел виду "независимый" параллелизм, т.е. паралеллизм независимых потоков, где каждый поток выполняет уникальный алгоритм.
V>>Т.е. характерен тот момент, что корутины для нейтива что они есть, что их нет — абсолютно пофиг для остальной программы, в отличие от того же дотнета, которому нужен детерминированный стек для нормальной работы GC.
I>Смешное утверждение. Файберы могут работать с дотнетом. Принципиальной разницы нет.
Да, но корутины буста дешевле, чем файберы windows, поэтому и разрабатываются.
Дотнету НЕОБХОДИМО разметить стек на фреймы, чтобы GC мог в нём работать. Если же корутина была создана не ср-вами дотнета, то дотнет в таком стеке сможет работать только с самым последним кадром стека, который создаётся, например, вы вызове из нейтива unmanaged poiner to function, которую можно получить из дотнетного делегата.
I>Если GC может сканировать стек, то может сканировать и стек короутин. Ничего военного.
GC сканирует не весь стек, а только список связанный фреймов в нём. Оборвешь связь — и нет никакого сканирования.
I>Вся идея короутин в отсутствии ожиданий. Короутина ничего и никого ждать не должна. Все тяжелые блокирующие вызовы нужно отфутболивать в тред-пул, а шедулер будет брать следующую короутину. Отсюда ясно, что проблема вовсе не в примитивах синхронизации, как ты тут утверждаешь. Т.е. все дело в том, сколько тактов нужно потратить на вызов следующей короутины, а не в том, какие механицмы синхронизации у кого есть.
Облом спорить. Но, таки, ожидание IO — это де-факто больное место ВСЕХ библиотек statefull-корутин. Могу рекомендовать посмотреть на PPL, как там с этим борются.
Здравствуйте, Sheridan, Вы писали:
I>>Именно. В силу того, что ты пишешь в своё удовольствие, ты скорее всего проходишь мимо очень важных, но скучных, рутинных вещей, которые напрямую не связаны с результатом, например тестирование, проектирование, майнтенанс, суппорт. Что характерно, именно эти вещи дают наибОльшее количество экспириенса, в т.ч. даже в кодинге. S>Ты говоришь о процессе разработки вообще, я же говорю только о его части — собственно, программировании. S>Как, например, процесс саппорта дает опыт в программировании? Да, процесс влияет на результат (выясняем баги, пишем патчи), но сам процесс не дает такого опыта.
Этот процесс даёт возможность посмореть на своё приложение под разными углами.
Грубо говоря, новичок-разработчик смотрит на код и видит в нём один execution path. Его устраивает поведение программы на этом execution path, поэтому он считает свою работу выполненной.
Разработчик, отпахавший 10 лет в саппорте, смотрит в тот же самый hello world и видит пару сотен вариантов того, как могут пойти дела на самом деле.
Естественно, он пишет программы с учётом этого опыта.
Точно так же, как начинающий DBA пыхтит над тем, чтобы нарисовать корректный SQL-запрос, а опытный — сразу видит, где могут быть просадки производительности.
И эта опытность никак не зависит от количества "написанных" стейтментов — исключительно от количества решённых проблем, возникающих при реальной эксплуатации "в поле".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>И эта опытность никак не зависит от количества "написанных" стейтментов — исключительно от количества решённых проблем, возникающих при реальной эксплуатации "в поле".
Всё верно. Изменится подход к написанию софта, возможно архитектура.
На знание языка, на умение программировать это никаким образом не влияет
Здравствуйте, petr_t, Вы писали:
S>>Пока еще ничего. _>Если оно даже не работает, то о чем вообще говорить?
Не прыгай в сторону, сам же просил показать, а теперь отмахиваешься. Нет уж, смотри.
Во первых, оно работает, но преследуемая мной цель еще не достигнута.
Во вторых, поясню немного — что это: это еще одна распределенная система мониторинга сервантов. На компах устанавливаются ноды (демон), которые сенсорами собирают инфу и передают её коллекторам (демон), которые сохраняют это в хранилище (демон). Из хранилища это потом отдельными приложениями будет браться инфа и рисоваться как хистори графики, так и реалтайм. Будет как минимум веб-приложение для сводного хистори (с графиками, рисованными на R) и обычное клиентское приложение для реалтайм наблюдения и хистори.
Проект сильно вялотекущий, пишу когда есть желание. Чтение\запись конфигов уже есть (собственный парсер/генератор json), данные от сенсоров уже приходят к коллекторам (как раз на этом этапе пока остановился). Это всё будет гибко конфигурироваться (сколько каких данных с какой периодичностью сохранять, надо ли усреднять, с каким периодом итд), данные будут кешироваться для уменьшения запросов к БД (например, для реалтайма, крайний слепок данных будет всегда в памяти), написаны макросы для легкого написания новых сенсоров (в макросы запиханы все кишки взаимодействия с нодой, программисту останется написать сам код выкапывания данных и json-описание сенсора, например). Потоки там используются так: каждый сенсор в своем потоке, каждая нода в каждом коллекторе в своем потоке. Хранилище тоже будет общаться с коллекторами и клиентами тоже в отдельных потоках для каждого.
Не реализовано еще хранение, визуализация, сенсоры, поддержка snmp, обеспечение непрерывности данных (не хочу терять данные, пока коллектор или хранилище по тем или иным причинам недоступны).
В третьих, пишу потому как всё доступное существующее меня не устраивает, руки иногда тянутся писать код, а голова требует задачу. Поэтому вопрос "нафига оно надо" задавать не стоит, равно как и вопрос "когда допишешь" — допишу тогда, когда допишу, этот проект ради шашечек пишется. Как получится ехать — тогда и поедем, возможно очень нескоро
Надеюсь, на все возникшие вопросы ответить получилось, давай дальше по существу. У себя в этом проекте в потоках я могу куда нибудь упороться? Если да, то какой дашь совет?
Здравствуйте, Sheridan, Вы писали:
S>Всё верно. Изменится подход к написанию софта, возможно архитектура. S>На знание языка, на умение программировать это никаким образом не влияет
Я все пропустил. Работать, понимаете ли, надо.
Когда меняется подход к решению задачи, привычные средства языка, которым ты, казалось бы, владеешь в совершенстве, открываются с совершенно неожиданной стороны.
Здравствуйте, Sheridan, Вы писали:
S>Всё верно. Изменится подход к написанию софта, возможно архитектура. S>На знание языка, на умение программировать это никаким образом не влияет
Знание языка, о котором ты говоришь — это умение читать программы.
Умение программировать — это и есть "подход к написанию софта, возможно архитектура".
Например, я могу читать программы на примерно 7-8 языках. "Со словарём" — на полусотне.
А вот программировать я умею от силы на пяти языках, а скорее даже на трёх-четырёх.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
