Здравствуйте, Ночной Смотрящий, Вы писали:

НС>100 это вообще ни о чем.

Что это значит? Что orchard cms может выдавать 1000 и больше RPS на одном ядре? Или то, что ты можешь написать приложение, которое даст 1000?

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

Z>Что это значит? Что orchard cms может выдавать 1000 и больше RPS на одном ядре?

Ничего не знаю про orchard cms. Если это такое же кривое поделие как dotnetnuke, то может и не может.

Z> Или то, что ты можешь написать приложение, которое даст 1000?

То, что типичное веб-приложение типа соцсетей или форумов, если там сильно не накосячить, без особых проблем способно будет обрабатывать несколько сотен параллельных запросов. Если же писать аккуратно, пусть и без всяких high load приемов, то несколько тысяч rps на ядро не проблема.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ничего не знаю про orchard cms. Если это такое же кривое поделие как dotnetnuke, то может и не может.

Я сейчас не знаю, смотрел очень давно. Если осталось такое же, то да. Как и множество других продуктов.

НС>То, что типичное веб-приложение типа соцсетей или форумов, если там сильно не накосячить, без особых проблем способно будет обрабатывать несколько сотен параллельных запросов. Если же писать аккуратно, пусть и без всяких high load приемов, то несколько тысяч rps на ядро не проблема.

Если я напишу аккуратно, могу и на тормознутых рельсах сделать порядка тысячи RPS, несколько сотен параллельных запросов. В реальных приложениях картина будет резко отличаться.

Ну и вообще это такое странное писькомерство, допустим у нас 10к RPS. Это сотни тысяч, а то и миллионы, одновременно работающих пользователей. Сервер под это дело будет стоить несколько сотен тысяч рублей. Его размещение — сущие копейки. Не хватает производительности — купили еще один сервер и вот у нас уже 20к RPS. За сравнительно небольшие деньги.

А вот сколько у нас стоит сервер для базы и сколько стоит удвоить его производительность? Основные заморочки начинаются там и их решение стоит уже сильно дороже.

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

НС>>Ничего не знаю про orchard cms. Если это такое же кривое поделие как dotnetnuke, то может и не может.
Z>Я сейчас не знаю, смотрел очень давно. Если осталось такое же, то да. Как и множество других продуктов.

И? То что кривым кодом можно нивелировать любую технологию — вряд ли кто спорить будет.

Z>Ну и вообще это такое странное писькомерство

С чего ты взял что это писькомерство вообще? Речь про другое — на нагрузке в 100 RPS бессмысленно сравнивать технологии, они все справятся.

Z>А вот сколько у нас стоит сервер для базы и сколько стоит удвоить его производительность? Основные заморочки начинаются там и их решение стоит уже сильно дороже.

Сильно зависит от задачи.

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

_>>Более того, с этой точки зрения нет абсолютно никакой разницы между IOCP кодом и кодом с созданным пользователем потоком, в котором используется блокирующая операция ввода-вывода.
S>Благодарю, крайне познавательно. Но тут не согласен, когда речь идет о нагруженном приложении пропускная способность c IOPC будет больше, ибо бы будем ему делегировать io операции,
S>не блокировав тем самым пользовательский поток, который сможет начать обрабатывать другой запрос.

Для нагруженного приложения асинхронный код действительно будет эффективнее. Но не из-за эффективности асинхронного ввода-вывода самого по себя, а из-за неэффективности (при их большом числе) системных потоков ОС. Т.к. использование блокирующего ввода-вывода принуждает к использованию схемы "по системному потоку на каждый запрос пользователя".

S>В однопоточном случае разница будет небольшой, тут согласен.

Она не просто будет небольшой, она скорее всего будет ещё и в пользу блокирующего ввода-вывода. )))

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

_>Для нагруженного приложения асинхронный код действительно будет эффективнее. Но не из-за эффективности асинхронного ввода-вывода самого по себя, а из-за неэффективности (при их большом числе) системных потоков ОС. Т.к. использование блокирующего ввода-вывода принуждает к использованию схемы "по системному потоку на каждый запрос пользователя".

А вот енто интересно! Неужели однопоточные неблокирующие сервера с eventloop'ом столь эффективны из-за одного потока, т.к. ресурсы на управление потоками не тратятся? Или же все-таки asynchronous io штука сама по себе мощная, что ей много потоков и не надо? Я думаю, что asynchronous io штука мощная да еще и с потоками мучаться не надо, что выигрышно вдвойне.

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

I>>Софт сам по себе не работает, его выполняет процессор. Все остальное, в т.ч. события от железа, транслируется именно в эту модель — процессора.

S>Да, енто так, и? Но процессор тоже асинхронен, у него есть прерывания, например. Далее, наряду с процессором используется еще и периферия,
S>которая оченно медленная, поэтому все вокруг периферии старается быть асинхронным.

Ога. И каким же чудом ты собираешься это воспользоваться этим из юзер мода ?

I>>Под капотом все эти хитрые эвенты всё равно разбрасываются по потокам. То есть, быстрее никак не выйдет, это в чистом виде издержки.

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

Обычные потоки. thread. Ты описываешь какую то несуществующую операционку. Событие от железа, пока попадёт в юзер мод, пройдет хрен знает сколько задержек и очередей. Аналогично и в обратную сторону.

I>>ЭвентЛуп помогает правильно загрузить внутренний тредпул. Вручную такой работы далеко не всегда сможешь добиться.
I>>Если вычислений мало, JS рулит. Но если начинается внятная загрузка, эвентлуп блокируются, а это значит, что события от железа тупо ждут. А вот в ручном многопоточном управлении они все равно обрабатываются.

S>Полностью согласен, все енто не для числодробилок, а для отдачи какой-нибудь html статики\динамики, т.е. где по сути одно io. П

Уже html статика с динамикой могут потребовать довольно много ресурсов, например: для конкатенации строк, парсинга тех же строк и тд.

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


I>Ога. И каким же чудом ты собираешься это воспользоваться этим из юзер мода ?

Никак, но на уровне дизайна можно все енто дело как-то мимикрировать, понимая почему именно так работает железо.

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

Про потоки понял, мы про разные стадии говорим -- я про начало обработки (очередь hd), Вы -- про конец, разрброс результата по потокам.
Вот именно пока событие от медленного железа дойдет в юзер моду, мы можем сосредоточиться на чем-то другом.

S>>Полностью согласен, все енто не для числодробилок, а для отдачи какой-нибудь html статики\динамики, т.е. где по сути одно io. П
I>Уже html статика с динамикой могут потребовать довольно много ресурсов, например: для конкатенации строк, парсинга тех же строк и тд.

Либо чисто статики, не знаю насколько енто соотв. реальности боевых систем, либо потребляемы ресурсы ЦПУ O(1) от io.

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

_>>Для нагруженного приложения асинхронный код действительно будет эффективнее. Но не из-за эффективности асинхронного ввода-вывода самого по себя, а из-за неэффективности (при их большом числе) системных потоков ОС. Т.к. использование блокирующего ввода-вывода принуждает к использованию схемы "по системному потоку на каждый запрос пользователя".
S>А вот енто интересно! Неужели однопоточные неблокирующие сервера с eventloop'ом столь эффективны из-за одного потока, т.к. ресурсы на управление потоками не тратятся? Или же все-таки asynchronous io штука сама по себе мощная, что ей много потоков и не надо? Я думаю, что asynchronous io штука мощная да еще и с потоками мучаться не надо, что выигрышно вдвойне.

Если бы оно было выигрышно само по себе, то тогда и одиночная асинхронная операция ввода-вывода была бы эффективнее синхронной, не так ли? А тут всё с точностью до наоборот. Вот в этой темке уже кидали ссылки на какие-то совершенно дикие цифры (аж в 8 раз медленнее) для асинхронной работы из .Net. В нормальной реализации (на чистом WinAPI) конечно не всё столь печально, но ни о каком преимуществе над синхронным вводом-выводом говорить не приходится.

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

_>прерывание в процессоре, сигнализирующее о завершение перекачки через DMA очередной порции данных от сетевой карты -> запуск обработчика прерывания, осуществляющего запуск кода из соответствующего драйвера сетевой карты->запуск обработчиков из драйверов сетевого стека, которые копируют данные из DMA памяти в подготовленный приложением буффер и ставят соответствующий флаг в системной структуре.
_>...проходит неопределённое время...
_>планировщик потоков windows видит что появилась возможность активировать соответствующий поток->IOCP поток видит установленный флаг готовности данных->происходить вызов прикладного кода с бизнес-логикой.

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

_>Как видишь, тут между вызовом железа и реальным вызовом кода имеется произвольный разрыв, так что ни о какой реальной асинхронности от железа речи нет.

Разрыв может исчезать в пиковых нагрузках.

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

_>>прерывание в процессоре, сигнализирующее о завершение перекачки через DMA очередной порции данных от сетевой карты -> запуск обработчика прерывания, осуществляющего запуск кода из соответствующего драйвера сетевой карты->запуск обработчиков из драйверов сетевого стека, которые копируют данные из DMA памяти в подготовленный приложением буффер и ставят соответствующий флаг в системной структуре.
_>>...проходит неопределённое время...
_>>планировщик потоков windows видит что появилась возможность активировать соответствующий поток->IOCP поток видит установленный флаг готовности данных->происходить вызов прикладного кода с бизнес-логикой.
A>К моменту завершения бизнес логики может завершится какая-то другая io операция и потоку не нужно будет засыпать. Т.е. выполнение следующей io операции не будет включать переключения контекста.

Конечно. В этом и смысл использования асинхронного ввода-вывод. Естественно это не на 100% так выходит, т.к. даже имеющий задачи поток снимается с исполнения по истечение своего кванта времени. Не говоря уже о том, что прерывание от сетевой карты обрабатывают те же самые ядра процессора, а не какая-то внутренняя магия. Но в целом да, при тысячах одновременных задач получаем огромный выигрыш по производительности в сравнение с с просто многопоточным подходом.

_>>Как видишь, тут между вызовом железа и реальным вызовом кода имеется произвольный разрыв, так что ни о какой реальной асинхронности от железа речи нет.
A>Разрыв может исчезать в пиковых нагрузках.

Нет, разрыв не исчезнет никогда. Он может становится больше или меньше по времени, но и только. Потому как вызов прикладного кода в любом случае осуществляется не из обработчика прерывания — это просто разные стеки вызовов.

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

_>>Для нагруженного приложения асинхронный код действительно будет эффективнее. Но не из-за эффективности асинхронного ввода-вывода самого по себя, а из-за неэффективности (при их большом числе) системных потоков ОС. Т.к. использование блокирующего ввода-вывода принуждает к использованию схемы "по системному потоку на каждый запрос пользователя".

S>А вот енто интересно! Неужели однопоточные неблокирующие сервера с eventloop'ом столь эффективны из-за одного потока, т.к. ресурсы на управление потоками не тратятся? Или же все-таки asynchronous io штука сама по себе мощная, что ей много потоков и не надо? Я думаю, что asynchronous io штука мощная да еще и с потоками мучаться не надо, что выигрышно вдвойне.

Ей нужно примерно столько же потоков, как и обычному приложению. Разница только в том, что эти потоки работают "под капотом". То есть, не нужно мучиться с потоками. Но и нет возможности заниматься вычислительными задачами.

Асинхронный процессинг сам по себе медленее синхронного. Бенефит получается только тогда, когда запросов много, но бОльшая часть времени тратится на sleep. То есть, неэффективная работа потоков.

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

Z>Причина — можно рассовать 1000 IO по потокам и тогда у нас вроде как 1000 запросов могут обрабатываться одновременно.

Ага, прямо таки одновременно. Откуда у тебя возьмется 1000 ядер?

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

I>Ага, прямо таки одновременно. Откуда у тебя возьмется 1000 ядер?

Одновременно, в данном случае, значит 1000 потоков в состоянии обработки. В отличии от состояния ожидание обработки в очереди.

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

I>>Ага, прямо таки одновременно. Откуда у тебя возьмется 1000 ядер?

Z>Одновременно, в данном случае, значит 1000 потоков в состоянии обработки. В отличии от состояния ожидание обработки в очереди.

Это значит, что почти вся тысяча ждет, пока им выделится физическое ядро. То есть, и там и там ожидание, только очереди разные.

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

I>Это значит, что почти вся тысяча ждет, пока им выделится физическое ядро. То есть, и там и там ожидание, только очереди разные.

Верно.

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

KP>В современном мире я не думаю что есть хоть какой-то смысл в использовании старых LISP-ов,

Как минимум пока в Emacs используется Elisp — смысл есть

KP>есть же Clojure, которая благодаря JVM фактически нивелирует разницу в количестве доступных библиотек с Python

Есть Hy. Это Lisp с двусторонней совместимостью с Python. Ему доступны все Python'овские библиотеки by-design.
http://docs.hylang.org/en/stable/tutorial.html

(import [sh [cat grep wc]])
(->
  (cat "/usr/share/dict/words")
  (grep "-E" "^hy")
  (wc "-l"))

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

KP>>>Использовать как некого гибрида между отладчиком, редактором и юнит-тестами.
НС>>Зачем? В чем преимущество перед нормальным встроенным в IDE тестраннером?
KP>В скорости обратной связи. Если ты не работал плотно хотя бы с Jupyter, ты меня не поймёшь. Просто попробуй.

Работал с Jupyter, сейчас плотно работаю с Org-mode (суть та же — интерактивные ячейки с кодом — только лучше).
По части обратной связи при "игре с кодом", юнит тесты (в том числе на C++, ага) ничем не уступают — написал строчку, нажал кнопку (или настроил авто-запуск) и через мгновение получаешь результат
REPL тут заруливает если данные в память долго или трудно загружать, или например сложная конфигурации обвязки, или например нужно провести хирургическую операцию прямо на боевой системе. В случае с REPL'ами среду не нужно перезапускать при каждой правке, и соответственно не нужно загружать данные снова и снова.

KP>Так что (к дискуссии выше) я более чем верю в то, что Грэм имел охренненое преимущество по скорости разработки перед любыми конкурентами.

Только это преимущество заключается отнюдь не в REPL, а в ФВП, замыканиях и макросах. Например в его книге On Lisp, которая вышла перед началом Viaweb, основным мотивом является создание встроенных языков (EDSL), а отнюдь ни REPL.

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

KP>>В современном мире я не думаю что есть хоть какой-то смысл в использовании старых LISP-ов,
EP>Как минимум пока в Emacs используется Elisp — смысл есть

Да, ELisp действительно имеет значение

EP>Есть Hy. Это Lisp с двусторонней совместимостью с Python. Ему доступны все Python'овские библиотеки by-design.

Не знаю, Python все же и сам имеет просто прекрасный синтаксис и возможности с одной стороны и улучшения тут врятли нужны, плюс он и так дико тормозной с другой стороны и делать его еще медленнее за счет дополнительной прослойки та еще идея. А вот Clojure с запуском поверх JVM – вот это действительно супер идея!

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

EP>По части обратной связи при "игре с кодом", юнит тесты (в том числе на C++, ага) ничем не уступают — написал строчку, нажал кнопку (или настроил авто-запуск) и через мгновение получаешь результат

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

KP>>Так что (к дискуссии выше) я более чем верю в то, что Грэм имел охренненое преимущество по скорости разработки перед любыми конкурентами.
EP>Только это преимущество заключается отнюдь не в REPL, а в ФВП, замыканиях и макросах. Например в его книге On Lisp, которая вышла перед началом Viaweb, основным мотивом является создание встроенных языков (EDSL), а отнюдь ни REPL.

Тогда – нет, не только. Сейчас и другие языки имеют развитое мета-программирование (C++, Rust) или макросы (Rust, Nemerle), пусть и с не настолько впечатляющими возможностями как в LISP-ах. То есть это все и сейчас преимущество по сравнению с другими языками, но только REPL до сих пор вне конкуренции в отличие от остальных возможностей.