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

P>Снова теоретические рассуждения. Менеджер, разумеется, нужен. Но это отдельный модуль. Его просто написали. А все остальное сильно переделывать ничего не пришлось. Добавили пару-тройку функций для взаимодействия в менеджером. Все остальное каким было, таким и осталось. Менеджер этот — штука не самая тривиальная.
А я и не говорю, что надо переколбашивать всё подряд и никогда не говорил. Я говорю лишь о том, что проект надо пересмотреть и в каких то местах, возможно, поправить.

P>Межпроцессное взаимодействие — не то же самое, что межпоточное в рамках одного процесса.
Это я понимаю.


Напомню, с чего всё началось. Началось всё с того, что я предположил дальнейший путь повышения производительности софта, в связи с скорым (?) достижением железом потолка, будет прокладываться в сторону распараллеливания. Сначала говорил про многопоточность (и упёрся в нежелание понимать того простого факта, что так или иначе, рано или поздно, но это сделать придется там где есть возможность). Ок, внесли предложение заменить на "многопроцессность" — пусть будет так, я не против, результат будет и в этом случае.
И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно. Блин, да я не говорю о том что будет легко. Я вообще не даю никаких оценок и никого ничему не учу.
Или тут тренд такой — не соглашаться со мной? Надо будет как нибудь попробовать написать пост типа "Память нынче не ресурс, давайте откусывать много и не жалеть, клиент всего лишь купит еще пару плашек по 8Г и будет счастлив", интересно — все сменят свое мнение и начнут возражать или нет?...

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

S>Вот! Я как раз говорю про знание, а вы про владение.

Ну да, про владение. Программисты-теоретики — это злющее зло. Правда, таких теоретиков, не участвовавших ни в одном проекте, я встречал только в качестве преподов в вузах (не среди своих). По счастью, их было очень мало. Для студентов они — адский адЪ. Никогда не ставят зачет, если исходник программы студента выглядит не так, как препод его себе представляет.

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

S>И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно.

Это не сложно. В массовых маштабах и с сегодняшними технологиями многопоточного программирования, это просто невозможно.

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

S>И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно. Блин, да я не говорю о том что будет легко. Я вообще не даю никаких оценок и никого ничему не учу.

Сложность очевидна, как ты сам сказал. А вот отсутствие альтернативных путей это, мягко говоря, дилетантские рассуждения.

S>Или тут тренд такой — не соглашаться со мной? Надо будет как нибудь попробовать написать пост типа "Память нынче не ресурс, давайте откусывать много и не жалеть, клиент всего лишь купит еще пару плашек по 8Г и будет счастлив", интересно — все сменят свое мнение и начнут возражать или нет?...

У тебя слишком категорично выходит. Во первых, возможны принципиально новые архитектуры вычислителей. Во вторых, возможна реструктуризация софта. Скажем, вместо "вычислить за секунду на сотне ядер" получится "считать с упреждением за ночь и по требованию выдать за секунду".
В третьих, возможны новые технологии в микропроцессорах, операционных системах и тд и тд.

У тебя вместо всего этого только один ответ — "много(поточность|процессорность|нужное вписать)".

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

I>>>>В том то и дело. В специфичных задачах уже давно работают по тесяче и более ядер
V>>>В пакетном режиме вычислений, однако.
I>>И что тебя смущает ?

V>Что это плохо ложится на современные SMP-системы "общего назначения".

Наоборот, очень даже хорошо. Видеокарты тому пример.

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

V>Дотнету НЕОБХОДИМО разметить стек на фреймы, чтобы GC мог в нём работать. Если же корутина была создана не ср-вами дотнета, то дотнет в таком стеке сможет работать только с самым последним кадром стека, который создаётся, например, вы вызове из нейтива unmanaged poiner to function, которую можно получить из дотнетного делегата.

Нет никаких фундаментальных препятствий научить GC таким короутинам. С теми же файберами он может худо-бедно работать.

I>>Если GC может сканировать стек, то может сканировать и стек короутин. Ничего военного.

V>GC сканирует не весь стек, а только список связанный фреймов в нём. Оборвешь связь — и нет никакого сканирования.

Ну так не обрывай.

I>>Вся идея короутин в отсутствии ожиданий. Короутина ничего и никого ждать не должна. Все тяжелые блокирующие вызовы нужно отфутболивать в тред-пул, а шедулер будет брать следующую короутину. Отсюда ясно, что проблема вовсе не в примитивах синхронизации, как ты тут утверждаешь. Т.е. все дело в том, сколько тактов нужно потратить на вызов следующей короутины, а не в том, какие механицмы синхронизации у кого есть.

V>Облом спорить. Но, таки, ожидание IO — это де-факто больное место ВСЕХ библиотек statefull-корутин. Могу рекомендовать посмотреть на PPL, как там с этим борются.

Любое ожидание, не только IO, это больное место вообще всей целиком взятой кооперативной многозадачности, а сюда входят не только statefull, но и stateless-корутины и многие другие вещи.

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

S>Во первых, оно работает, но преследуемая мной цель еще не достигнута.
надо взять на вооружение

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

I>>Я думаю скорее стоит ожидать появления специализированых процессоров например для ио
I>>Если часть функций ос вынести в железо, это даст не слабую масштабируемость
IO>Сетевые карты, обрабатывающие внутри себя TCP — это оно, или что-то другое?

Управление от потока данных. Как IOCP, но 'сильнее'

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

S>>И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно. Блин, да я не говорю о том что будет легко. Я вообще не даю никаких оценок и никого ничему не учу.
I>Сложность очевидна, как ты сам сказал. А вот отсутствие альтернативных путей это, мягко говоря, дилетантские рассуждения.
I>У тебя слишком категорично выходит. Во первых, возможны принципиально новые архитектуры вычислителей. Во вторых, возможна реструктуризация софта. Скажем, вместо "вычислить за секунду на сотне ядер" получится "считать с упреждением за ночь и по требованию выдать за секунду".
I>В третьих, возможны новые технологии в микропроцессорах, операционных системах и тд и тд.
I>У тебя вместо всего этого только один ответ — "много(поточность|процессорность|нужное вписать)".
Я не говорил что альтернатив нет, альтернативы вполне себе обсуждались в соседних подветках и я туда не лез, я ограничил свой подсабж только распараллеливанием
Я просто стараюсь всётаки в рамках сабжекта разговаривать, не прыгать туда-сюда, иначе бардак. Не всегда, конечно получается. но я стремлюсь чтобы всегда.

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

I>Управление от потока данных. Как IOCP, но 'сильнее'

А это как-то можно сделать в рамках процессора общего назначения? ЦПУ с dataflow-архитектурой — идея не новая, но её практическая реализуемость вроде бы никто не продемонстрировал. Хотя попытки были.

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

S>Напомню, с чего всё началось. Началось всё с того, что я предположил дальнейший путь повышения производительности софта, в связи с скорым (?) достижением железом потолка, будет прокладываться в сторону распараллеливания. Сначала говорил про многопоточность (и упёрся в нежелание понимать того простого факта, что так или иначе, рано или поздно, но это сделать придется там где есть возможность). Ок, внесли предложение заменить на "многопроцессность" — пусть будет так, я не против, результат будет и в этом случае.

Для тебя это очевидно, потому что ты прочитал на эту тему кучу теоретических рассуждений, и на этом основании сформулировал и отстаиваешь свою точку зрения. Это твое "так или иначе, рано или поздно, но это сделать придется" — далеко не очевидный факт. Скажу банальность. Тут бизнес решает. Да, я снова про презренный металл. Выжать больше возможностей, минимизируя при этом затраты. Альтернативные варианты, как ты заметил, обсуждаются.

Заметь, я не утверждаю, что ты категорически неправ. Я говорю, что твоя точка зрения — не единственная.


S>И все равно, вместо того чтобы согласиться с очевидным фактом того, что так или иначе придется идти в этом направлении, все начинают со мной спорить о том, что это сложно.

Повторю: это далеко не очевидный факт.

S>Или тут тренд такой — не соглашаться со мной?

А не сам ли ты способствуешь его развитию?

S>Надо будет как нибудь попробовать написать пост типа "Память нынче не ресурс, давайте откусывать много и не жалеть, клиент всего лишь купит еще пару плашек по 8Г и будет счастлив", интересно — все сменят свое мнение и начнут возражать или нет?...

"Шо, опять?" © Вот смотри. У меня в компе когда-то стояло 64 М памяти. В один прекрасный день мне понадобилось на том компе запустить кое-что тяжелое. Я заранее знал, что 64 — не хватит. Пошел в ближайшую лавку и купил вагон памяти. В этом смысле память — действительно не ресурс. Проблема возникает, если память, которая продается, не вставляется в имеющиеся разъемы.

Когда разрабатывают серверный софт, примерно знают, сколько он отхватит. Знают, как будет использоваться серверное железо. Соответственно, памяти ставят туда, сколько нужно. Может, вдвое больше. Память все еще не ресурс. А вот когда софтина сразу после релиза начинает вылетать из-за нехватки памяти — это уже хреново. Вот тут память становится ресурсом, и еще каким. Потому что простой сервера — это всегда убытки для его владельца.

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

S>Напомню, с чего всё началось. Началось всё с того, что я предположил дальнейший путь повышения производительности софта, в связи с скорым (?) достижением железом потолка, будет прокладываться в сторону распараллеливания.
Тут есть ещё такой момент. Описанный, ЕМНИП, у Кнута.
Возьмём какую-нибудь простую задачку. Например, сортировку массива.
Есть десятки алгоритмов, построенных для однопоточных реализаций. Есть несколько алгоритмов, которые построены для многопоточных.
Возьмём экстремальный пример: предположим, у нас есть неограниченное количество "ядер" — вычислителей, каждый из которых может выполнять простую операцию типа compare-and-swap за одну стадию.
Длина массива — N. За какое минимальное количество стадий мы можем отсортировать массив?
Внезапно выясняется, что у современной математики нет способа решения таких задач. Для небольших количеств ядер (<10) нам известны оптимальные конфигурации процессорной сети — полученные, собственно, прямым перебором. Уже при K=50 мы не можем нарисовать эффективную сеть.

Этот простой пример показывает причины, по которым твоё предположение пока что весьма сомнительно. Известные нам алгоритмы параллелизации задач начинают сосать при выходе количества ядер за пределы нескольких десятков.
Вот хороший анализ: http://lira.imamod.ru/FondProgramm/Sort/ParallelSort.pdf
Посмотри на алгоритм Бэтчера. Видно, что при 512 ядрах мы сумели разогнать сортировку с 83 секунд до 1.29. Круто? Круто.
Но добавление ещё 128 ядер даёт нам всего лишь 0.08 секунды ускорения. Если у нас бюджет на эту сортировку — 100мс, то мы, судя по форме графика, всё ещё ой как далеки. А слоты под процессоры уже закончились.
Именно поэтому современные тенденции — в консолидации. Мы запихиваем по 48 ядер в одну коробку не для того, чтобы отдавать странички в 48 раз быстрее, а чтобы обрабатывать в 48 раз больше параллельных реквестов, тратя всего лишь в 5 раз больше на электричество и охлаждение.

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

S>Этот простой пример показывает причины, по которым твоё предположение пока что весьма сомнительно. Известные нам алгоритмы параллелизации задач начинают сосать при выходе количества ядер за пределы нескольких десятков.
S>Вот хороший анализ: http://lira.imamod.ru/FondProgramm/Sort/ParallelSort.pdf
S>Посмотри на алгоритм Бэтчера. Видно, что при 512 ядрах мы сумели разогнать сортировку с 83 секунд до 1.29. Круто? Круто.
S>Но добавление ещё 128 ядер даёт нам всего лишь 0.08 секунды ускорения. Если у нас бюджет на эту сортировку — 100мс, то мы, судя по форме графика, всё ещё ой как далеки.

Да, закон Амдала во всей красе.

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

S>Я не говорил что альтернатив нет, альтернативы вполне себе обсуждались в соседних подветках и я туда не лез, я ограничил свой подсабж только распараллеливанием

Распараллеливание это не панацея по той простой причине, что слишком много задач имеют сложные зависимости по данным. Если ты найдешь способ, скажем, как хорошо обходить граф в глубину параллельным алгоритмом, сразу двинешь всё человечество далеко вперёд

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

I>>Управление от потока данных. Как IOCP, но 'сильнее'

IO>А это как-то можно сделать в рамках процессора общего назначения? ЦПУ с dataflow-архитектурой — идея не новая, но её практическая реализуемость вроде бы никто не продемонстрировал. Хотя попытки были.

В рамках процессора общего назначения не выйдет, конечно.

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

I>Распараллеливание это не панацея по той простой причине, что слишком много задач имеют сложные зависимости по данным. Если ты найдешь способ, скажем, как хорошо обходить граф в глубину параллельным алгоритмом, сразу двинешь всё человечество далеко вперёд

А чем плох поиск в ширину?

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


_>Тоже верно. Но я как-то не надеюсь, что разработчики хромающего хрома и тормозиллы возьмутся за ум. Раньше их криворучие компенсировалось приростом производительности, но теперь уже нет.

Ну, ващет простые сайты открываются сейчас моментально в браузерах. Другое дело, что как только увеличивается производительность и появляются новые фичи(в дабаскрипте, цсс и т.д.), сразу усложняются сайты. Веб сейчас сильно отличается от того, что был 10 лет назад, и в старых, более шустрых, браузерах, 99.9% современных сайтов просто не откроются.

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


I>Чудеса параллельного программирования пока что сильно преувеличены. Большинство задач или плохо параллелятся, или дают такое усложнение, что качество само собой обваливается ниже плинтуса.

Или вообще могут оказаться медленнее однопоточного варианта, часто по весьма неочевидным причинам, которые не были учтены при принятии решения о распараллеливании.

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

S>Именно поэтому современные тенденции — в консолидации. Мы запихиваем по 48 ядер в одну коробку не для того, чтобы отдавать странички в 48 раз быстрее, а чтобы обрабатывать в 48 раз больше параллельных реквестов

На самом деле — раз так в 20, в лучшем случае.

Вообще то Мур говорил о том, что наблюдения показали рост плотности транзисторов, не более того.
А так за последние 14 лет частота процессоров Intel выросла аж на 200Мгц.
Халява то закончилась, по этому поводу была статья, 10 лет назад.