>> А я про обфускацию. Точнее про машинно-сгенерированный код. Я не знаю из
>> чего он был сгенерирован, гадать не решаюсь.
> Гхм... Вы правда знаете машины которые способны сгенировать довольно сложный логический
> код приведенный выше??? Код был просто прогнан через минимизатор(он же обфускатор).
> копи-пастните его хотя бы в jsnice.org и вы поймете что ошибаетесь
> насчет умности машин, способных генернуть подобный код.Я не знаю как ты пришёл к выводу о том, как был сгенерирован код, поэтому я продолжу придерживаться своего мнения: код был получен в результате компиляции. Минимизация -- это тоже разновидность компиляции, но я не уверен в том, что ею всё и ограничилось.
>> Стиль программирования -- это дело привычки. Это я тебе из опыта говорю
>> -- мне приходилось одолевать ассемблер после C, и это было непросто.
>> Потом мне было lisp сложно одолеть. Потом я об хаскелл ломал
>> голову. И несколько лет назад о rust.
> Мне теперь тоже достать баклажан и помериться у кого больше ?
> Ну так я начинал с более худшего, с опкодов (т.к друго еще
> просто не было), сидишь так и ищешь по строкам и столбцам
> нужный опкод из таблиц... Все еще живой, не помер... :)
То есть я объясняю тебе то, что ты и без меня знаешь? Что ж ты тогда ноешь о стиле программирования, если и так знаешь?
>> Если ты не умеешь
>> мыслить о программировании в какой-то специфической концепции -- это не значит,
>> что концепция плохая.
> "На вкус и цвет товарища нет" :)
Это дилетантские глупости. В реальности ты используешь тот стиль, который лучше ложится на задачу, а вопрос твоих личных предпочтений никого не волнует.
> Уфф, Ок, у вас есть 3 мальчика на побегушках и вам надо
> чтобы они разнесли 3 письма. Это "тру" ассинхронность, если они все
> вместе паралельно побежали. Теперь вам надо, чтобы пацаны разнесли одновременно 8
> писем - Гуд бай "тру" ассинхроность. Нода, как врочем любой другой
> язык, предоставит вам фэйковую ассинхроность, спрятав под капотом планировщика ядра очень
> быструю беготню тех 3-х пацанов.
Ты здесь и сейчас путаешь асинхронность с ядрами процессора (и после этого ты удивляешься, как это твоему собеседнику удаётся догадаться об отсутствии квалификации у тебя...). Сходи почитай о терминах. Мы тут с тобой говорим "асинхронность", сокращая термины и как бы подразумевая что все понимают о чём речь, но раз ты не понимаешь, я поясню. Речь идёт об асинхронных коммуникациях. Асинхронность -- это не свойство программы, это свойство тех внешних интерфейсов, с которыми она работает. Когда у тебя даже два сокета, то каждый из них ведёт себя вне всякой связи с другим, и это называется асинхронностью, точнее сокеты называют асинхронными: они не синхронизированы между собой. Когда у тебя есть мышь и клавиатура, которые могут любым образом перетасовывать свои ивенты, типа KeyDown, MouseMove, Button1Down, KeyUp, Button2Down... то это тоже асинхронность, клавиатура и мышь не синхронизированы между собой. Вот KeyDown и KeyUp ивенты синхронизированы, второй всегда следует за первым, а KeyDown и MouseMove не синхронизированы, они асинхронны. Слово "асинхронность" применяют и к описанию программы, чтобы отразить свойство программы справляться с асинхронным вводом/выводом и не синхронизировать принудительно работу разных каналов ввода/вывода из-за своих внутренних ограничений архитектуры. Например, если ты напишешь цикл типа
while let conn = accept(socket) {
let request = conn.read_request();
let response = request.eval();
conn.write_response(response);
conn.close();
}
То тогда это синхронный код: ты будешь обрабатывать соединения в порядке поступления, и если одно из соединений зависнет почему-то, то остальные послушно будут ждать. Таким образом этот код будет синхронизировать соединения.
> И как вы понимаете, даже если
> пацанята спринтеры, то с увеличением количества писем та самая 100к ассинхронность
> замедлится независимо от ноды, рaста или ассемблера, т.к. если только три
> пацана.
Там вопрос в том, когда сервер прекратит справляться с нагрузкой, то есть когда количество соединений начнёт расти, потому что у сервера не хватает ресурсов на обработку их. По мере роста количества входящих соединений в секунду происходит некоторое замедление (которое может быть несущественным: основное время на обработку может определятеся сетевыми задержками), но в какой-то момент сервер включает отказ в обслуживании. Твоя "тру-асинхронность" сможет работать с десятками, может с сотнями соединений. Если у тебя ядра будут исчисляться сотнями, то может тысячи или десятки тысяч соединений сможет обслуживать -- с уродскими задержками, но сможет. Эти ядра будут простаивать 90% времени (или 99%), в ожидании ввода/вывода, но больше твоя тру-асинхронность выжать не сможет. Если ты включишь преемптивную многозадачность в ядре, и подберёшь scheduler в ядре попроще, который за O(1) сможет переключать задачи, то на сотне ядер может ты до сотни тысяч соединений дотянешься.
Твоя тру-асинхронность нафиг никому не сдалась, даже если ты доплачивать будешь за её использование, потому что она не в состоянии утилизировать наличные возможности возможности, она приводит к тому, что существенную часть времени ядра крутят пустой цикл в ожидании ввода/вывода, или на то, чтобы пересчитывать приоритеты, переключать контексты и выполнять переходы между ring0/ring3. Вместо того, чтобы работать с данными, программа тратит процессорные такты на какую-то хрень.
>> Как раз, чтобы это не было демагогией, чтобы разговор был бы конструктивным
>> и развивающим, я предлагаю тебе посетить образовательные ресурсы.
> Понятно, вы я так понимаю всезнающий отец наставник, чтоб так вот запросто
> определить уровень собеседника...
Да у тебя на лбу написано. Если ты этого не понимаешь, то это ещё одна приписка на лбу, которая говорит что предыдущее я понял неверно и завысил твой уровень.
>> Я не следил за темой достаточно внимательно в процессе её развития, но
>> по моим наблюдениям, именно эти абьюзы эвентуального программирования были одним из
>> основных мотивов для изобретения промисов/асинков. Ну, или если точнее выражаться, то
>> не изобретения, а скорее доведения до уровня массового потребления -- идея-то
>> не новая, в общем.
> Угу, долго что то только к этому шли
А ты думаешь такую вещь так просто изобрести? Типа сел, подумал вечерок, придумал, и через недельку выкатил синтаксис async/await и рантайм к нему, позволяющий тянуть миллион соединений?
На это надо много проб и ошибок. Мне неоднократно приходилось читать статьи вида "я тут на досуге взял lighttpd, и попробовал его перепилить вот так, и вот смотрите какие результаты..." Алан Кокс, помнится, чуть ли не в ядро запиливал какую-то фишку, чтобы потом на lighttpd показать, как она отразится на характеристиках работы. Но тут ведь речь ещё о свойствах языка, то есть мало придумать как это сделать на уровне машинных кодов, надо ещё придумать как это записывать в языке, запилить в какой-нибудь язык подходящий синтаксис, в этом синтаксисе запилить http-сервер и померять результаты. И если получилось неочень, то выкинуть всё придумать что-нибудь ещё и повторить эпопею.
Но мало ведь того, хотелось бы иметь подход, который будет работать и с написанием гуёв -- где источников асинхронности не так много, но зато гораздо разнообразнее надо реагировать на это из-за чего код становится сложнее на пару порядков, чем любой http-сервер. Такие вещи крайне сложно запилить, если бы их было просто запилить, то их запилили бы ещё в середине XX века, до изобретения всех этих ваших C.
Если я сейчас легко могу объяснить что такое async/await, как это работает, чем там занят рантайм, как на это хорошо ложатся задачи асинхронного ввода/вывода, то это не потому что async/await придумать просто, а потому что его уже придумали за меня, и я дал себе труд посмотреть на него, и заглянуть под капот. И то, я отмечу, что если взять всё то время, которое я потратил на изучение работы с асинхронным вводом/выводом, то там получится не неделя и даже не две, там выйдет больше.
