Модель обслуживания выбрана спорная. Легковесные потоки по всем параметрам предпочтительней. И работают не хуже, и многопроцессорность можно сделать, и код получается читабельным, а не лапша из коллбэков.
ЯП спорный. Сам по себе JS мне очень нравится, но наслоения со времён 90-х, невнятная стандартная библиотека, это всё делает его очень спорным выбором.
Что реально мне понравилось — возможность использовать общий код в богатом клиенте в браузере и на сервере. Но сколько этого общего кода? Много ли? Мне кажется, что нет. Навскидку приходит в голову только валидация. Да рендеринг на сервере страницы перед тем, как её отдать, в AJAX приложении, аналогичный рендерингу на клиенте, но это, вроде, практически нигде пока не реализовано. Валидация, в принципе, делается кодогенерацией из декларативного описания на сервере для любого ЯП, если хочется убрать тут дубликацию.
Ещё мне понравилось коммьюнити. Очень интересные миниатюрные библиотеки, отличное качество документации. Но это, наверное, не заслуга языка. Поэтому пока интересует исключительно технические плюсы.
Здравствуйте, vsb, Вы писали:
vsb>Модель обслуживания выбрана спорная. Легковесные потоки по всем параметрам предпочтительней. И работают не хуже, и многопроцессорность можно сделать, и код получается читабельным, а не лапша из коллбэков. vsb>ЯП спорный. Сам по себе JS мне очень нравится, но наслоения со времён 90-х, невнятная стандартная библиотека, это всё делает его очень спорным выбором.
Спорить можно всегда и с чем угодно, эт дело такое.
Есть простой факт:
Нода начиналась как проект-эксперимент и выросла в полноценную серверную платформу с богатой инфраструктурой. Поэтому не уверен что спору по поводу модели/языка будут … эффективными.
vsb>но наслоения со времён 90-х, невнятная стандартная библиотека
Могли бы вы раскрыть эту мысль. О каких наслоениях идет речь? И о какой "стандартной библиотеке"? По факту в джавасрипте ее нет. А нода привнесла очень много своих "стандартных библиотек" + нестандартные.
vsb>Ещё мне понравилось коммьюнити. Очень интересные миниатюрные библиотеки, отличное качество документации. Но это, наверное, не заслуга языка.
Почему же, вполне может быть заслуга языка, сообщество ноды сформировалось с фронт-эндшиков (в обоих смыслах: "браузерные" разработчики и разработчики серверных фронт-этдов), а в той сфере много людей с шилом в одном месте
vsb>Поэтому пока интересует исключительно технические плюсы.
Из технических моментов:
Однопоточность и колбеки убирают/уменьшают вероятность дедлоков.
Модель ноды (1 поток — 1 процесс) упрощает администирование. В случае утечки ресурсов с легковесными потоками не всегда может получится удалить "зависшие" и освободить ресурсы. Поэтому реально выход один — убить весь процесс, который у вас занимал несколько, а скорее всего все, ядра. В случае с нодой вы убиваете процесс который завис на одном ядре, а процессы на других ядрах у вас продолжают работать. То есть масштабирование у вас кошерное горизонтальное, нет разницы запускаетесь вы на супер-компьютере или на десятке микроинстансов.
Довольно нетребовательный к ресурсам для простых задач. Приложение на той же джаве в реальном мире будет рассчитывать на хотя бы 1-2 Гб
"Один язык". Упрощается подбор команды, так как язык, подходы, иногда библиотеки одни и те же. А в случае если используется МонгоДБ, то и язык БД совпадает с языком сервера и клиентской части.
Здравствуйте, vsb, Вы писали:
vsb>Модель обслуживания выбрана спорная. Легковесные потоки по всем параметрам предпочтительней. И работают не хуже, и многопроцессорность можно сделать, и код
А у каких библиотек, платформ есть легковесные потоки, не считя erlang?
Здравствуйте, Sharov, Вы писали:
S>А у каких библиотек, платформ есть легковесные потоки, не считя erlang?
В Rust вроде встроены зелёные потоки. А так, наборы "сделай сам" в виде coroutines/fibers есть практически для всех языков — C++, D, Go, Python.
Кстати, для Python есть готовая библиотека, делает monkey-patch стандартных сокетов и т.п.:
"""Spawn multiple workers and wait for them to complete"""from __future__ import print_function
urls = ['http://www.google.com', 'http://www.yandex.ru', 'http://www.python.org']
import gevent
from gevent import monkey
# patches stdlib (including socket and ssl modules) to cooperate with other greenlets
monkey.patch_all()
import urllib2
def print_head(url):
print('Starting %s' % url)
data = urllib2.urlopen(url).read()
print('%s: %s bytes: %r' % (url, len(data), data[:50]))
jobs = [gevent.spawn(print_head, url) for url in urls]
gevent.wait(jobs)
Наверняка, многим серьезным веб-программистом преходилось испытать неприязнь, когда они узнавали, что чтобы выложить веб-сайт надо еще изучать пхп. Все соглашаются (и в интернете я тоже читал) что это очень, очень плохой язык. Это на самом деле глупость и когда я прочитал я долго не мог поверить ходил спрашивал и оказалось не зря. Тепер ьвеб-сайты можно писать на самом популярном в мире языке джаваскрипте. Это революционный переворот и он происходит прямо на наших глазах. Что это значит для нас, ребята? Что мы уже знаем, как писать сйты по сути. Я был шокирован, как там все организовано, но похоже они все вопросы продумали с самого начала и договорились что это будет очень востребованный проект.Более того, умные C++ перцы из гугл которые по утрам ездят в автобусах набитых баскетбольными мечами уже работают над тем, чтобы джаваскрипт работал быстрее С++, потому что он комплируется сразу в результат, минуя стадию вычисления! Вы наверняка заметили это по тому, что gmail.com открывается за 5 секунд, а не 20 как это было в до-интернетную эпоху, может хотя бы самые древние. Его кстати тоже делали в гугл. Что это если не порыв я не знаю. То есть, если вы напишете свой сайт на nodejs, он автоматически будет бытсрым и будет масштабироватсья (обрабатывать столько клиентов, сколько пришло, это настоящая проблема в пхп была и некто не знал как с ней быть). Например, данные между разными запросами не изолированны и вообще можно использовать одни и те же глобальные переменные для всех клиентов и экономить память. В том же пхп это в принципе не возмонжно и засчет этого у ноды такая гиганская производительность. Там даже продумано если вы будете работать с другом или кто-то допустим, то я зык специально за счет очень удобной типизации можно писать так что вы не будете знать что и как вам передает ваш друг. Это очень удобно потому что позволяет меняь програму в одном месте и вообще не парится о том же друге что там у него програма все равно запустится.Только представьте! Любой кусок кода можно насать один раз. Например, функцию, переворачивающущю строку, и вызывать ее из браузера или включать музыку с телефона. Особенно если заморочиться совместимостью северного кода и особеностей разных браузеров. Также они добавили возможность создавать внутри функции другие функции и это очень круто, но я пока не понял как потом вернуться в первую функцию. Но самое главное, что над нодой сейчас работает туча народу просто, они переписывают все что было до них написано на ноду и у них получается лучше потому что они сразу заточились на производительность и чтобы было лучше а так же просто использовать. Например нужно сходить в базу данных создал проект на гитхабе сразу набежали форкнули завтра только пуллреквесты принять и можно заливать в продакшн на свой ноутбук. Сообщество очень дружелюбное, если кому-то удается сделать что-то работающее на ноде его обязательно хвалят и подбадревают потому что это правда успех. Я пока не понял как допустим считать файл но говорят эт из-за безопасности,там все очень надежно, ведь если к тебе вдруг идет миллион клиентов и вы облажаетесь в 10% случаев ты облажаешься перед 100 000 человек. Поэтому например если где-то произошла ошибка лучше сразу аккуратненько завершиться чем пазориться перед остальными, тем более если перезапустить сервер то там и память лишняя освободится и бегать начнет пошустрее, да и перезапускается он очнь бытсро. Иногда бывает быстрее перезапустить сервер чем дождаться окончания сборки мусора. Ктому же nodejs так оптимизирован что никогда не займет больше одного ядра а это значит что базу данных например можно поставить на тот же ноут на другое ядро для экономии ресурсов и надежности (иметь что-то на той же машине всегда надежнее, много ли что, все у кого есть дома интернет вы это итак знаете) и все будет быстро бегать и даже можно во что-нибудь пошпилить или дальше форум по nodejs почитать но тогда надо побольше ядер купить. Но в серверы как раз много ядер и ставят и как видите nodejs прекрасно справляется с этой задачей. Правда что бы писать на ноде нужно купить макбук потому что все примеры в интернете написаны на мак буке но я думаю если выделаете высокопроизводительный веб-сервис, вам всеравно прийдется пройти раунд финансирования у родителей чтобы потом его запускать. Вообщем я в восторге хотя немного напрягает что гдето должны быть проблемы но я пока не понял не столкнулся ая уже очнь долго с ней разбираюсь и пока не понял.
Здравствуйте, LuciferSpb, Вы писали:
LS>перцы из гугл которые по утрам ездят в автобусах набитых баскетбольными мечами уже LS>(с) http://tonsky.livejournal.com/266519.html Никита Прокопов (tonsky)
Как можно серьезно воспринимать персонажа, который очевидно неграмотен?
Как относится к неграмотному персонажу, который не моргнув глазом, цитирует другого неграмотного?
Здравствуйте, silverwolf, Вы писали:
vsb>>ЯП спорный. Сам по себе JS мне очень нравится, но наслоения со времён 90-х, невнятная стандартная библиотека, это всё делает его очень спорным выбором. S>Спорить можно всегда и с чем угодно, эт дело такое. S>Есть простой факт: S>Нода начиналась как проект-эксперимент и выросла в полноценную серверную платформу с богатой инфраструктурой. Поэтому не уверен что спору по поводу модели/языка будут … эффективными.
Это чисто эстетическое. Писать можно на чём угодно, но красивые ортогональные решения приятней и подсознательно имеют большой вес при выборе.
vsb>>но наслоения со времён 90-х, невнятная стандартная библиотека S>Могли бы вы раскрыть эту мысль. О каких наслоениях идет речь? И о какой "стандартной библиотеке"? По факту в джавасрипте ее нет. А нода привнесла очень много своих "стандартных библиотек" + нестандартные.
Всякие ===, undefined, false, null, переменные, создаваемые по умолчанию, многословный синтаксис для анонимных функций, какие-то неявные нелогичные преобразования типов, это по языку.
Стандартная библиотека в JS есть, но она отстойная. Массивы, которые одновременно хеш-таблицы, причём неизвестно как реализованные, без контроля хеш-функции, нет связных списков, нет нормального ООП-апи, нет нормального ФП-апи, какой-то студент накидал функций случайным образом, половину слизав с Java 1.0, половину придумав, чтобы зачёт получить и забыть как страшный сон.
Нестандартные библиотеки для основы языка это плохо. С этим можно жить, но это плохо. Потому что на них основаны все остальные библиотеки. И при их использовании будет боль. Хороший пример — 100500 классов строк в С++, потому что нормального класса в своё время не было (и, я так понял, до сих пор нет).
Здравствуйте, LuciferSpb, Вы писали:
LS>Здравствуйте, Stanislaw K, Вы писали: LS>>>перцы из гугл которые по утрам ездят в автобусах набитых баскетбольными мечами уже LS>выделенное — единственное, что глаз резануло?
Исё началось тут: "Наверняка, многим серьезным веб-программистом преходилось испытать неприязнь", а к "мечам" уже накатило что то.
LS>>>(с) http://tonsky.livejournal.com/266519.html Никита Прокопов (tonsky) SK>>Как можно серьезно воспринимать персонажа, который очевидно неграмотен? LS>весь текст — очевидный стеб.
ты прервал.
Здравствуйте, Sharov, Вы писали:
EP>>Кстати, для Python есть готовая библиотека, делает monkey-patch стандартных сокетов и т.п.: S>Питон не очень удачный пример, поскольку он изначально сильно однопоточный.
Так JS по дизайну _полностью_ однопоточный.
В Python, для примера, в PyPy или JPython используются реальные параллельные потоки без всякого GIL.
Здравствуйте, Sharov, Вы писали:
EP>> Python. EP>>Кстати, для Python есть готовая библиотека, делает monkey-patch стандартных сокетов и т.п.: S>Питон не очень удачный пример, поскольку он изначально сильно однопоточный.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А node.js разве не однопоточный?
Я к тому, что Вы поставил питон в один ряд с языками или платформами, где есть встроенная поддержка (легковесных) потоков.
Питон там не очень к месту, хотя есть реализации питона (см. выше комментарий), где он уже обладает
вполне себе взрослой многопоточностью.
Здравствуйте, Sharov, Вы писали:
EP>>А node.js разве не однопоточный? S>Я к тому, что Вы поставил питон в один ряд с языками или платформами, где есть встроенная поддержка (легковесных) потоков.
gevent как раз предоставляет легковесные потоки.
Да и кстати, в node.js ведь нет встроенных легковесных потоков, так? Автоматы ведь вручную по callback'ам размазываются.
Здравствуйте, silverwolf, Вы писали:
S>Из технических моментов: S>
S> Однопоточность и колбеки убирают/уменьшают вероятность дедлоков. S>
Это заблуждение. Дедлоки происходят от двух вещей — многозадачность и разделяемые ресурсы. Хотя поток один, асинхронных цепочек может быть несколько.
Итого — кооперативная многозадчность на марше. Теперь все цепочки работают с одним разделяемым ресурсом — опаньки !
Как и с любой многозадачности и разделяемыми ресурсами, происходят гонки. Решаем эти гонки и получаем асинхронные примитивы синхронизации.
Применяем...
...две асинхронных нити, 1 и 2, захватывают 2 ресурса, А и Б, но в разной последовательности. Нить 1 захватывает А и пытается захватить Б, а нить 2 захватывает Б и пытается захватить А.
Опаньки — дедлок асинхронного кода.
Итого — асинхронщина это АДъ в отладке. Нужно устранять разделяемые ресурсы, даже если это обойдётся в 100гб адресного пространства
Здравствуйте, vsb, Вы писали:
vsb>Стандартная библиотека в JS есть, но она отстойная. Массивы, которые одновременно хеш-таблицы, причём неизвестно как реализованные, без контроля хеш-функции, нет связных списков, нет нормального ООП-апи, нет нормального ФП-апи, какой-то студент накидал функций случайным образом, половину слизав с Java 1.0, половину придумав, чтобы зачёт получить и забыть как страшный сон.
ООП и ФП гораздо лучше чем в C# и Java и даже С++. В новом стандарте станет вообще недостижимо лучше.
vsb>Нестандартные библиотеки для основы языка это плохо. С этим можно жить, но это плохо. Потому что на них основаны все остальные библиотеки. И при их использовании будет боль. Хороший пример — 100500 классов строк в С++, потому что нормального класса в своё время не было (и, я так понял, до сих пор нет).
С++ как язык слишком сложен. Пока люди разберуется, что к чему, то уже прирастают к своим велосипедам (классам строк и смартпоинтерам) и жить без них не могут, тащут во все проекты.
В джаваскрипте код в целом пишется довольно быстро, набрал и всё палит, т.е. за свой код мало кто держится. Есть несколько основных стеков, на которых все построено и унутре стека все довольно гладко. Выбор библиотек довольно большой, с одной тсороны хорошо, с другой стороны может понадобиться время на этот выбор.
Есть несколько правил в JS — нужно, в порядке убывания важности
1 избегать лишних связей и обрезать оные по возможности.
2 держать код в виде пригодном для рефакторинга
3 избегать лишних сущностей и обрезать по возможности.
4 соблюдать соглашения, давать качественные имена
5 следить за локальностью
Если все 5 кажутся трудными в исполнении, то самый минимум это 1. Без него вообде никуда. Если непонятно как этого добиться — лучше вообще уйти от динамических языков.
п2 он немного парадоксальный. JS сам по себе довольно гибкий язык. Но как сказал Ленин, если слишком сильно взять влево, окажешься справа. Слишком много гибкости даёт хрупкость.
п5 он тоже не совсем очевидный. Очень просто на JS наваять такое решение, что придется вникать во все модули и либы, что бы понять локальную строчку — т.е. фактически возврат во времена плохого С++ или даже ассемблера — в каждой строчке надо думать о том, что может произойти в другой части системы.
Здравствуйте, Ikemefula, Вы писали:
vsb>>Стандартная библиотека в JS есть, но она отстойная. Массивы, которые одновременно хеш-таблицы, причём неизвестно как реализованные, без контроля хеш-функции, нет связных списков, нет нормального ООП-апи, нет нормального ФП-апи, какой-то студент накидал функций случайным образом, половину слизав с Java 1.0, половину придумав, чтобы зачёт получить и забыть как страшный сон.
I>ООП и ФП гораздо лучше чем в C# и Java и даже С++. В новом стандарте станет вообще недостижимо лучше.
Чем лучше? Что будет в новом стандарте? Когда его будут поддерживать все браузеры?
К ФП у меня претензии — нет нормального синтаксиса для анонимных однострочных функций, писать function (x, y) { return x + y; } это очень много в сравнение с другими языками. Нет нормальной библиотеки коллекций в функциональном стиле.
Про ООП странно слышать. Я в JS вообще ООП нормальный не вижу, вижу некую симуляцию, как в каком-нибудь перле. Вроде внешне всё как в ООП, но внутри костылях и хеш-таблицы. В Java с этим по-моему лучше.
vsb>>Нестандартные библиотеки для основы языка это плохо. С этим можно жить, но это плохо. Потому что на них основаны все остальные библиотеки. И при их использовании будет боль. Хороший пример — 100500 классов строк в С++, потому что нормального класса в своё время не было (и, я так понял, до сих пор нет).
I>В джаваскрипте код в целом пишется довольно быстро, набрал и всё палит, т.е. за свой код мало кто держится. Есть несколько основных стеков, на которых все построено и унутре стека все довольно гладко. Выбор библиотек довольно большой, с одной тсороны хорошо, с другой стороны может понадобиться время на этот выбор.
Какие стеки есть?
I>Есть несколько правил в JS — нужно, в порядке убывания важности I>1 избегать лишних связей и обрезать оные по возможности. I>2 держать код в виде пригодном для рефакторинга I>3 избегать лишних сущностей и обрезать по возможности. I>4 соблюдать соглашения, давать качественные имена I>5 следить за локальностью
Правила хорошего тона для любого языка на мой взгляд.
Здравствуйте, Ikemefula, Вы писали:
I>Как и с любой многозадачности и разделяемыми ресурсами, происходят гонки. Решаем эти гонки и получаем асинхронные примитивы синхронизации.
Да, но в дополнение есть мощный и дешёвый примитив синхронизации, которого нет в вытесняющей многозадачности: отдать управление после совершения всей транзакции.
Здравствуйте, vsb, Вы писали:
I>>ООП и ФП гораздо лучше чем в C# и Java и даже С++. В новом стандарте станет вообще недостижимо лучше.
vsb>Чем лучше? Что будет в новом стандарте? Когда его будут поддерживать все браузеры?
Лямбды, короутины, классы, модули, прокси. Не в курсе.
vsb>К ФП у меня претензии — нет нормального синтаксиса для анонимных однострочных функций, писать function (x, y) { return x + y; } это очень много в сравнение с другими языками. Нет нормальной библиотеки коллекций в функциональном стиле.
А что ты хочешь от этой нормальной библиотеки функций ?
vsb>Про ООП странно слышать. Я в JS вообще ООП нормальный не вижу, вижу некую симуляцию, как в каком-нибудь перле. Вроде внешне всё как в ООП, но внутри костылях и хеш-таблицы. В Java с этим по-моему лучше.
Там прототипное ООП, в ём реализуемо всё что тебе надо.
I>>В джаваскрипте код в целом пишется довольно быстро, набрал и всё палит, т.е. за свой код мало кто держится. Есть несколько основных стеков, на которых все построено и унутре стека все довольно гладко. Выбор библиотек довольно большой, с одной тсороны хорошо, с другой стороны может понадобиться время на этот выбор.
vsb>Какие стеки есть?
node.js, sencha, jQuery
I>>Есть несколько правил в JS — нужно, в порядке убывания важности I>>1 избегать лишних связей и обрезать оные по возможности. I>>2 держать код в виде пригодном для рефакторинга I>>3 избегать лишних сущностей и обрезать по возможности. I>>4 соблюдать соглашения, давать качественные имена I>>5 следить за локальностью
vsb>Правила хорошего тона для любого языка на мой взгляд.
Приоритеты разные. Скажем, п2, п4 и п5 для C# или джавы вообще можно выкинуть
I>...две асинхронных нити, 1 и 2, захватывают 2 ресурса, А и Б, но в разной последовательности. Нить 1 захватывает А и пытается захватить Б, а нить 2 захватывает Б и пытается захватить А. I>Опаньки — дедлок асинхронного кода.
В теории согласен, но я не могу вспомнить (или даже придумать) реального примера когда такое происходило бы (утечки ресурса, гонки -- это помню, дедлок вспомнить не могу). Если вам не трудно приведите его.
И все же оставил себе немного маневра S>> Однопоточность и колбеки убирают/уменьшают вероятность дедлоков.
I>Итого — асинхронщина это АДъ в отладке. Нужно устранять разделяемые ресурсы, даже если это обойдётся в 100гб адресного пространства
Простите немного не понял вывод. При чем тут отладка? И откуда появились 100Гб?
Здравствуйте, silverwolf, Вы писали:
I>>Опаньки — дедлок асинхронного кода. S>В теории согласен, но я не могу вспомнить (или даже придумать) реального примера когда такое происходило бы (утечки ресурса, гонки -- это помню, дедлок вспомнить не могу). Если вам не трудно приведите его.
В правильно написаном приложении я вообще не могу вспомнить где бы проиходили утечки, гонки, дедлоки, креши. Если не трудно — приведи пример.
Дедлоки возникают в ошибочных схемах работы с разделяемым ресурсом. Вот простой пример — есть два файла, в которых надо чего то писать. Одна цепочка пишет в файл унутре асинхронного мутекса и там же пытается записать в другой файл, так же унутре асинхроного мутекса, но другого. Другая цепочка делает тоже самое, но наоборот.
S>И все же оставил себе немного маневра S>>> Однопоточность и колбеки убирают/уменьшают вероятность дедлоков. S>
I>>Итого — асинхронщина это АДъ в отладке. Нужно устранять разделяемые ресурсы, даже если это обойдётся в 100гб адресного пространства S>Простите немного не понял вывод. При чем тут отладка? И откуда появились 100Гб?
Если говорить про коня в вакууме, то отладка ни при чем. А если про конкретный результат, то надо чем то обеспечить " Однопоточность и колбеки убирают/уменьшают вероятность дедлоков". Пудозреваю, это легко если ты пишешь без багов
100гб это для интереса. Зарулить указаную проблему можно конским распылением памяти-адресного пространства.
Здравствуйте, Ikemefula, Вы писали:
vsb>>К ФП у меня претензии — нет нормального синтаксиса для анонимных однострочных функций, писать function (x, y) { return x + y; } это очень много в сравнение с другими языками. Нет нормальной библиотеки коллекций в функциональном стиле.
I>А что ты хочешь от этой нормальной библиотеки функций ?
1. Развитый и расширяемый набор классов для коллекций. Вообще мне Java-овский нравится, но в целом может быть можно и лучше. Iterable, Collection, Set, List, ArrayList, LinkedList, HashSet, TreeSet, Map, HashMap, TreeMap. Эти все классы я использую достаточно часто и не представляю, как без них можно жить. В принципе есть ещё некоторые структуры данных вроде AVL-Tree, Trie, Ropes, BTree, которые используются редко, но почему бы их не иметь в стандартной библиотеке коллекций. Ещё есть бесконечные списки-генераторы, тоже могут быть полезны.
2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.
vsb>>Про ООП странно слышать. Я в JS вообще ООП нормальный не вижу, вижу некую симуляцию, как в каком-нибудь перле. Вроде внешне всё как в ООП, но внутри костылях и хеш-таблицы. В Java с этим по-моему лучше.
I>Там прототипное ООП, в ём реализуемо всё что тебе надо.
На С тоже реализуемо всё, что надо. Но писать классы в Java-стиле как то проще и понятней, в том числе для новичков. А прототипно-ориентированное программирование некоторыми ставится как отдельная дисциплина. В целом мне оно нравится, но всё же я не считаю его эталоном ООП.
I>>>Есть несколько правил в JS — нужно, в порядке убывания важности I>>>1 избегать лишних связей и обрезать оные по возможности. I>>>2 держать код в виде пригодном для рефакторинга I>>>3 избегать лишних сущностей и обрезать по возможности. I>>>4 соблюдать соглашения, давать качественные имена I>>>5 следить за локальностью
vsb>>Правила хорошего тона для любого языка на мой взгляд.
I>Приоритеты разные. Скажем, п2, п4 и п5 для C# или джавы вообще можно выкинуть
Не понимаю, почему. Если речь о том, что в Java можно выжить без читаемых имён, а в JS можно сразу застрелиться, то, возможно, соглашусь, но зачем так жить. Лучше писать нормально.
Здравствуйте, vsb, Вы писали:
I>>А что ты хочешь от этой нормальной библиотеки функций ?
vsb>1. Развитый и расширяемый набор классов для коллекций.
Это самоцель такая ? Ты лучше задачи расскажи, которые тебе надо решать.
>Iterable, Collection, Set, List, ArrayList, LinkedList, HashSet, TreeSet, Map, HashMap, TreeMap. Эти все классы я использую достаточно часто и не представляю, как без них можно жить. В принципе есть ещё некоторые структуры данных вроде AVL-Tree, Trie, Ropes, BTree, которые используются редко, но почему бы их не иметь в стандартной библиотеке коллекций. Ещё есть бесконечные списки-генераторы, тоже могут быть полезны.
Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.
vsb>2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.
var y = x.map(function(item) { return item.run(); })
Тут у тебя волосы шевелятся ?
I>>Там прототипное ООП, в ём реализуемо всё что тебе надо.
vsb>На С тоже реализуемо всё, что надо. Но писать классы в Java-стиле как то проще и понятней, в том числе для новичков. А прототипно-ориентированное программирование некоторыми ставится как отдельная дисциплина. В целом мне оно нравится, но всё же я не считаю его эталоном ООП.
скажи сразу — дело привычки и все.
I>>>>Есть несколько правил в JS — нужно, в порядке убывания важности I>>>>1 избегать лишних связей и обрезать оные по возможности. I>>>>2 держать код в виде пригодном для рефакторинга I>>>>3 избегать лишних сущностей и обрезать по возможности. I>>>>4 соблюдать соглашения, давать качественные имена I>>>>5 следить за локальностью
vsb>>>Правила хорошего тона для любого языка на мой взгляд.
I>>Приоритеты разные. Скажем, п2, п4 и п5 для C# или джавы вообще можно выкинуть
vsb>Не понимаю, почему. Если речь о том, что в Java можно выжить без читаемых имён, а в JS можно сразу застрелиться, то, возможно, соглашусь, но зачем так жить. Лучше писать нормально.
потому что там искаропки есть отличный рефакторинг, подсказки компилятора и интелисенс и это само по себе решает вагон проблем, потому п2 и п4 отпадают. п5 отпадает, потому что дизайн джавы и шарпа такой.
Здравствуйте, Ikemefula, Вы писали:
I>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.
А ты вообще пишешь что-нибудь сложнее Hello World?
Здравствуйте, Ikemefula, Вы писали:
I>Вот простой пример — есть два файла, в которых надо чего то писать. Одна цепочка пишет в файл унутре асинхронного мутекса и там же пытается записать в другой файл, так же унутре асинхроного мутекса, но другого. Другая цепочка делает тоже самое, но наоборот.
Простите, но я не знаком с таким понятием как "асинхронный мьютекс" (может под другим названием), если вам не трудно дайте ссылку "на почитать".
Если брать пример когда 2 цепочки пишут 2 файла но в разном порядке, то не понятно как получается дедлок. Если "блокировка" происходит по средствам чего-то вроде Deferred Object (который непереиспользуемый -- один раз отпустив его вы уже не сможете его поднять, то есть на роль мьютекса не особо подходит), то полочить дедлок вы можете только намерено, при том оба "потока" должны знать друг о друге (поскольку "блокировка" принадлежит "потоку") в таком контексте более естественным решением будет сделать цепочку из них. То есть в теории можно написать "дедлок", но на практике я не вижу способа как это можно получить по ошибке (а не намеренно).
Если вас не затруднит, то приведите пример кода, возможно так мне будет легче понять.
Здравствуйте, silverwolf, Вы писали:
S>Простите, но я не знаком с таким понятием как "асинхронный мьютекс" (может под другим названием), если вам не трудно дайте ссылку "на почитать".
Это легко гуглится. примитивы синхрнизации, гонки, дедлоки есть в любой многозадачности. Повторяю — в любой.
S>Если брать пример когда 2 цепочки пишут 2 файла но в разном порядке, то не понятно как получается дедлок. Если "блокировка" происходит по средствам чего-то вроде Deferred Object (который непереиспользуемый -- один раз отпустив его вы уже не сможете его поднять, то есть на роль мьютекса не особо подходит), то полочить дедлок вы можете только намерено, при том оба "потока" должны знать друг о друге (поскольку "блокировка" принадлежит "потоку") в таком контексте более естественным решением будет сделать цепочку из них.
Блокировки есть в любой многозадачности, отсюда ясно, что для дедлока нужно минимально
1 два примитива синхронизации, в данном слчае мутекса
2 две нитки(задачи)
Это понятно, или надо объяснять ?
Не ясно, к чему ты притянул Defered Object Мутекс он переиспользуемый, т.к. для синхронизации нужен, и это очевидно.
Блокировка не может принадлежать потоку, она всегда и везде вне потока, неважно, какая многозадачность, кооперативная или вытесняющая.
Например обычные мутексы принадлежат процессу или ОС, потоки их захватывают. В кооперативной навроде асинхронщины блокировки так же не принадлежат потоку.
И, что очевидно, ни одна из ниток не знает про другую — все что они знают, это про асинхронные блокировки.
Вот простейший асинхронный мутекс, точнее его вызов
Отсюда ясно, что промис(DeferredObject) и мутекс это две большие разницы.
lock если свободен, запускает функцию. Если занят — ставит функцию в очередь.
operation — стартует асинхронную цепочку, которая выполнится унутре мутекса.
Как только она завершится, мутекс освободится. Далее из очереди берется следующий клиент и с ним всё по кругу.
> То есть в теории можно написать "дедлок", но на практике я не вижу способа как это можно получить по ошибке (а не намеренно). S>Если вас не затруднит, то приведите пример кода, возможно так мне будет легче понять.
Итого — дедлок налицо. Каждая из цепочек может войти в первую операцию и если обе войдут, то каждая потом зависнет во второй.
Поскольку код асинхронный, цепочки легко стартуют одна за другой
fiber1();
fiber2();
поскольку код асинхронный, то обе цепочки могут одновременно спать или ожидать скажем IO. Т.е. пока первая унутре mutex1 ожидает IO, вторая входит в мутекс2 и так же начинает ожидать IO. Потом одна из них пробуждается и пробует захватить второй мутекс и попадает в очередь. Далее вторая попадется точно так же.
Здравствуйте, Cyberax, Вы писали:
I>>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год. C>А ты вообще пишешь что-нибудь сложнее Hello World?
Как говорил IT, правильно спроектированая программа состоит из большого количества Hello World
C>Да, кстати, как там по хэш-карте в JS пройтись?
Здравствуйте, Ikemefula, Вы писали:
S>>Простите, но я не знаком с таким понятием как "асинхронный мьютекс" (может под другим названием), если вам не трудно дайте ссылку "на почитать".
I>Это легко гуглится. примитивы синхрнизации, гонки, дедлоки есть в любой многозадачности. Повторяю — в любой.
Если бы оно легко гуглелось, я бы не третировал вас на форуме У меня в выдаче противопоставления мьютекса и промисов.
>> То есть в теории можно написать "дедлок", но на практике я не вижу способа как это можно получить по ошибке (а не намеренно). S>>Если вас не затруднит, то приведите пример кода, возможно так мне будет легче понять.
I>Показываю страшное
Та ничего страшного. Код вполне валидный и при этом теоретический.
На практике джаваскрипт-программист не придумает использовать мьютексы при наличии более простых способов "синхронизации", что делается довольно просто в условиях именно однопоточной среды. Поэтому я и писал что "убирают/уменьшают вероятность дедлоков" (согласен что "убирают" таки довольно резкое утверждение). Поэтому и просил привести реальный пример (реальную ошибку которую кто-то уже допустил при решении реальной задачи).
Здравствуйте, silverwolf, Вы писали:
S>Поэтому я и писал что "убирают/уменьшают вероятность дедлоков" (согласен что "убирают" таки довольно резкое утверждение).
Вполне нормальное утверждение, поскольку в каноническом js в принципе этих проблем быть не может. В здравом уме и памяти
никто переть мьютексы в js не будет, поскольку там нет такой пробелмы, которую они решают. (тыц,тыц). Другое дело webworker'ы, но это другая история...
Здравствуйте, silverwolf, Вы писали:
I>>Это легко гуглится. примитивы синхрнизации, гонки, дедлоки есть в любой многозадачности. Повторяю — в любой. S>Если бы оно легко гуглелось, я бы не третировал вас на форуме У меня в выдаче противопоставления мьютекса и промисов.
А оно действительно легко гуглится Я когда то нагуглил целую кучу асинхронных примитивов синхронизации.
>>Показываю страшное S>Та ничего страшного. Код вполне валидный и при этом теоретический.
Дедлок ты увидел или считаешь, что там дедлока нет ?
S>На практике джаваскрипт-программист не придумает использовать мьютексы при наличии более простых способов "синхронизации", что делается довольно просто в условиях именно однопоточной среды.
А если я тебе скажу, что в апи может и не быть синхронных методов в файл, что ты ответишь ?
Я сильно пудозреваю, ты с таким и не сталкивался.
Сейчас почти любая задача которая работает с IO проводит 90% времени в ожидании. Это значит, что даже на мега-быстродейственном С++ ты используешь максимум 10% процессора.
Сейчас самое узкое место в компе это IO. И по этой причине синхронный АПИ это убыток, неоправданная роскошь. Скажем для С++ это можно амортизировать, заюзав треды, а в джаваскрипте у тебя один единственный поток, синхронные вызовы сделают из без того тормозной джаваскрипт(сравнвая с С++) в черепаху.
>Поэтому я и писал что "убирают/уменьшают вероятность дедлоков" (согласен что "убирают" таки довольно резкое утверждение). Поэтому и просил привести реальный пример (реальную ошибку которую кто-то уже допустил при решении реальной задачи).
Я привел тебе ральный пример, только имена не из продакшна, ибо незачем.
Здравствуйте, Ikemefula, Вы писали:
S>>Если бы оно легко гуглелось, я бы не третировал вас на форуме У меня в выдаче противопоставления мьютекса и промисов. I>А оно действительно легко гуглится Я когда то нагуглил целую кучу асинхронных примитивов синхронизации.
Ну хоть название перечислите (выдача гугла персонализированная, может мне просто не везет)
I>Я привел тебе ральный пример, только имена не из продакшна, ибо незачем. I>Дедлок ты увидел или считаешь, что там дедлока нет ?
Дедлок я увидел. Просто тот пример что вы привели мне показался чисто теоретическим/надуманным, но раз вы говорите что такое мог написать живой человек в реальном коде прийдется поверить.
S>>На практике джаваскрипт-программист не придумает использовать мьютексы при наличии более простых способов "синхронизации", что делается довольно просто в условиях именно однопоточной среды.
I>А если я тебе скажу, что в апи может и не быть синхронных методов в файл, что ты ответишь ?
Что это не новость. В той же ноде в реальных задачах не используют синхронное АПИ (для некоторых наоборот людей открытие что в ноде существуют синхронные АПИ ).
От только эта асинхронная природа как раз таки уменьшает вероятность появления дедлока, так как та операция ради которой вы хотели залочиться, как правило, "атомарна", то есть управление вам передастся после ее завершения и необходимости делать явный лок (и разгребать все связанные с этим проблемы) нет, в отличии от многопоточной среды.
Помимо того что этот код проще он еще и более правильный так как гарантирует атомарность пары операций над file1Path и file2Path,
что были призваны обеспечить внешние вызовы mutex1.lock и mutex2.lock.
Поскольку такой вариант проще, то увеличивается вероятность того что он будет выбран вместо разгребания с парой мьютексов.
Здравствуйте, silverwolf, Вы писали:
S>>>Если бы оно легко гуглелось, я бы не третировал вас на форуме У меня в выдаче противопоставления мьютекса и промисов. I>>А оно действительно легко гуглится Я когда то нагуглил целую кучу асинхронных примитивов синхронизации. S>Ну хоть название перечислите (выдача гугла персонализированная, может мне просто не везет)
Обычно атомарна, но это не всегда так.
S>Поскольку такой вариант проще, то увеличивается вероятность того что он будет выбран вместо разгребания с парой мьютексов.
Теоретически проще все колбасить в декларативном виде, вероятность по идее должна увеличиться. А на практике люди часто пишут такой код, что обфусцировать не надо
Я конечно не в восторге от такого подхода, но вообще качество кода в большинстве проектов куда то на второй план уходит. Что с этим делать, не знаю.
Скажем, такую свертку как у тебя, типа _.partial, почему то мало где видел
Вообще в js почему то принятно злоупотреблять анонимными функциями, наверное потому что так проще брейкпоинты расставлять при отладки.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, c-smile, Вы писали:
C>>>Да, кстати, как там по хэш-карте в JS пройтись? CS>>то как раз легко. C>Авотфиг.
Извиняюсь, так вот надо
for( var k of map.keys() )
{
var v = map[k];
...
}
Отвечаю поздно, писал ответ давно, но рсдн его съел и сказал error
vsb>>1. Развитый и расширяемый набор классов для коллекций.
I>Это самоцель такая ? Ты лучше задачи расскажи, которые тебе надо решать.
1. Переопределение функции хеширования для своего объекта, чтобы использовать его в виде ключа. Сейчас всё конвертируется в строку, в итоге если мы хотим делать своё хеширование, нам надо переопределять метод toString. Бред.
2. Класс-множество. Нужен очень часто. Сейчас приходится использовать map[item] = true, но нормальный интерфейс куда удобней.
3. Двоичное дерево. Очень удобно, когда у нас есть сравнение ключей и мы хотим, чтобы ключи автоматом сортировались.
4. Связный список. Нужен не часто, но когда нужен, аналогов нет.
5. Нормальный Array, который не будет превращаться в HashMap незаметно от пользователя.
>>Iterable, Collection, Set, List, ArrayList, LinkedList, HashSet, TreeSet, Map, HashMap, TreeMap. Эти все классы я использую достаточно часто и не представляю, как без них можно жить. В принципе есть ещё некоторые структуры данных вроде AVL-Tree, Trie, Ropes, BTree, которые используются редко, но почему бы их не иметь в стандартной библиотеке коллекций. Ещё есть бесконечные списки-генераторы, тоже могут быть полезны.
I>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.
Это кирпичики для интерфейса между библиотеками. Если у тебя есть lib1, в которой list1, lib2 в которой list2, то придётся писать глупый и лишний код по преобразованию между этими списками. Если у нас есть чёткие кирпичики в виде интерфейсов, значит никаких проблем с использованием и сопряжением библиотек не будет. Ну а если у нас есть интерфейсы, как то глупо не включить реализацию.
vsb>>2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.
I>
I>var y = x.map(function(item) { return item.run(); })
I>
I>Тут у тебя волосы шевелятся ?
> ['1', '2', '3'].map(parseInt)
< [1, NaN, NaN]
Вот тут. Ещё можно почитать примеры тут и тут
I>>>>>Есть несколько правил в JS — нужно, в порядке убывания важности I>>>>>1 избегать лишних связей и обрезать оные по возможности. I>>>>>2 держать код в виде пригодном для рефакторинга I>>>>>3 избегать лишних сущностей и обрезать по возможности. I>>>>>4 соблюдать соглашения, давать качественные имена I>>>>>5 следить за локальностью
vsb>>>>Правила хорошего тона для любого языка на мой взгляд.
I>>>Приоритеты разные. Скажем, п2, п4 и п5 для C# или джавы вообще можно выкинуть
vsb>>Не понимаю, почему. Если речь о том, что в Java можно выжить без читаемых имён, а в JS можно сразу застрелиться, то, возможно, соглашусь, но зачем так жить. Лучше писать нормально.
I>потому что там искаропки есть отличный рефакторинг, подсказки компилятора и интелисенс и это само по себе решает вагон проблем, потому п2 и п4 отпадают. п5 отпадает, потому что дизайн джавы и шарпа такой.
Это кажется. На деле лапшу нерефакторизуемую на джаве соорудить легко. И никакие инструменты не помогут. Кстати в Java качественные имена я наблюдаю почему то гораздо чаще, чем в JS.
Про локальность тоже не понял, что там с дизайном не так. Глобальных переменных нафигачить — как раз плюнуть можно. И потом не то, что тестировать, баг отлавливать замучаешься.
Здравствуйте, vsb, Вы писали:
I>>Это самоцель такая ? Ты лучше задачи расскажи, которые тебе надо решать.
vsb>1. Переопределение функции хеширования для своего объекта, чтобы использовать его в виде ключа. Сейчас всё конвертируется в строку, в итоге если мы хотим делать своё хеширование, нам надо переопределять метод toString. Бред.
В итоге надо писать своё хеширование. toString или нет, это дело десятое.
vsb>2. Класс-множество. Нужен очень часто. Сейчас приходится использовать map[item] = true, но нормальный интерфейс куда удобней. vsb>3. Двоичное дерево. Очень удобно, когда у нас есть сравнение ключей и мы хотим, чтобы ключи автоматом сортировались. vsb>4. Связный список. Нужен не часто, но когда нужен, аналогов нет. vsb>5. Нормальный Array, который не будет превращаться в HashMap незаметно от пользователя.
Задачи какие решаешь ?
I>>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.
vsb>Это кирпичики для интерфейса между библиотеками. Если у тебя есть lib1, в которой list1, lib2 в которой list2, то придётся писать глупый и лишний код по преобразованию между этими списками. Если у нас есть чёткие кирпичики в виде интерфейсов, значит никаких проблем с использованием и сопряжением библиотек не будет. Ну а если у нас есть интерфейсы, как то глупо не включить реализацию.
Ты лучше про задачу расскажи, а то ты выдаёшь клочки какого то своего решения. А вот я скажу, что в C#, Java, C++ отстой ибо нельзя сделать вот так
obj.toString = function() {}
И что ?
vsb>>>2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.
I>>
I>>var y = x.map(function(item) { return item.run(); })
I>>
Это отстой. Ты задачу какую решаешь ? У меня в проекте около 7 мб джаваскрипта и я не наблюдаю тех ужасов, о которых ты говоришь Надо полагать я чтото не так делаю ?
I>>потому что там искаропки есть отличный рефакторинг, подсказки компилятора и интелисенс и это само по себе решает вагон проблем, потому п2 и п4 отпадают. п5 отпадает, потому что дизайн джавы и шарпа такой.
vsb>Это кажется. На деле лапшу нерефакторизуемую на джаве соорудить легко.
Это только кажется. На самом деле количество шагов рефакторинга увеличится.
vsb>И никакие инструменты не помогут. Кстати в Java качественные имена я наблюдаю почему то гораздо чаще, чем в JS.
Потому и наблюдаешь чаще, что там рефакторинг есть. Самый частый рефакторинг это переименование.
vsb>Про локальность тоже не понял, что там с дизайном не так. Глобальных переменных нафигачить — как раз плюнуть можно. И потом не то, что тестировать, баг отлавливать замучаешься.
Локальность это не про глобальные переменные. Локальность это значит, что на объект влияет только непосредственное окружение.
Здравствуйте, Ikemefula, Вы писали:
I>>>Это самоцель такая ? Ты лучше задачи расскажи, которые тебе надо решать.
vsb>>1. Переопределение функции хеширования для своего объекта, чтобы использовать его в виде ключа. Сейчас всё конвертируется в строку, в итоге если мы хотим делать своё хеширование, нам надо переопределять метод toString. Бред.
I>В итоге надо писать своё хеширование. toString или нет, это дело десятое.
toString это конвертация объекта в строку, а не хеширование. В том и беда JS, он постоянно всё подпирает костылями. Если я пишу своё хеширование, я его могу протестировать на данных, улучшить. Я чётко понимаю, как работает это хеширование. Как работает хеширование на toString-е? Это загадка, покрытая мраком. Очевидно только, что в каждом браузере по-разному. Ну и вообще я хочу иметь нормальный toString для отладки. Какое он отношение имеет к хешированию?
vsb>>2. Класс-множество. Нужен очень часто. Сейчас приходится использовать map[item] = true, но нормальный интерфейс куда удобней. vsb>>3. Двоичное дерево. Очень удобно, когда у нас есть сравнение ключей и мы хотим, чтобы ключи автоматом сортировались. vsb>>4. Связный список. Нужен не часто, но когда нужен, аналогов нет. vsb>>5. Нормальный Array, который не будет превращаться в HashMap незаметно от пользователя.
I>Задачи какие решаешь ?
Разные задачи. Не понимаю вопроса. Ну банально — приходят данные, их надо вставлять в упорядоченный список (например по имени). Если у меня есть дерево, я просто строю дерево по имени и вставляю, операция вставки занимает O(1), всё моментально обновляется. Если у меня нет дерева, мне приходится использовать массив, двоичным поиском искать место для вставки (кстати какая стандартная функция в JS для двоичного поиска?) и впихивать туда элемент, получая O(N) и тормоза.
I>>>Их вообще не должно быть в стандартной либе джаваскрипта, то есть, вообще. мене например половина этих вещей вообще никогда не была нужна, а остальные далеко не все нужны хотя бы раз в год.
vsb>>Это кирпичики для интерфейса между библиотеками. Если у тебя есть lib1, в которой list1, lib2 в которой list2, то придётся писать глупый и лишний код по преобразованию между этими списками. Если у нас есть чёткие кирпичики в виде интерфейсов, значит никаких проблем с использованием и сопряжением библиотек не будет. Ну а если у нас есть интерфейсы, как то глупо не включить реализацию.
I>Ты лучше про задачу расскажи, а то ты выдаёшь клочки какого то своего решения.
Я описываю, зачем в стандартной библиотеке любого языка нужны общепринятые коллекции.
vsb>>>>2. Функциональный интерфейс ко всему этому. map, foldl, foldr, foreach, может ещё что. Причём сделанный так, как как это сделано в других языках, а не свой особый путь, заставляющий изредка шевелиться волосы.
I>>>
I>>>var y = x.map(function(item) { return item.run(); })
I>>>
vsb>>Вот тут. Ещё можно почитать примеры
I>Это отстой. Ты задачу какую решаешь ? У меня в проекте около 7 мб джаваскрипта и я не наблюдаю тех ужасов, о которых ты говоришь Надо полагать я чтото не так делаю ?
Не знаю, что ты не так делаешь. Писать можно и на бейсике, если аккуратно. Это не отменяет минусов языка. Как минимум нужно знать про все расставленные грабли. Нужно помнить, что map передаёт в функцию-маппер не просто объект а ещё и его индекс и исходную коллекцию с какого то фига. Нужно помнить про все особенности parseInt, про то, что в старых браузерах он 010 пропарсит как 8, а в новых как 10, нужно помнить, что parseInt возвращает NaN для ошибок, но не всегда, а только если не смог пропарсить даже первый символ. И куча подобных мелочей. Огромная куча нелогичного контекста.
Здравствуйте, vsb, Вы писали:
vsb>Не знаю, что ты не так делаешь. Писать можно и на бейсике, если аккуратно. Это не отменяет минусов языка. Как минимум нужно знать про все расставленные грабли. Нужно помнить, что map передаёт в функцию-маппер не просто объект а ещё и его индекс и исходную коллекцию с какого то фига. Нужно помнить про все особенности parseInt, про то, что в старых браузерах он 010 пропарсит как 8, а в новых как 10, нужно помнить, что parseInt возвращает NaN для ошибок, но не всегда, а только если не смог пропарсить даже первый символ. И куча подобных мелочей. Огромная куча нелогичного контекста.
Скажем, если взять DOM, то таких нелогичностей будет на два-три порядка больше, при чем JS к этому никакого отношения не имеет — все эти грабли вылезут и в С++, если появится желание работать с DOM из С++.
Есть целый сайт, wtf.js, там много нестыковок. Представь, ни одна из них и даже почти все вместе они ничего ровным счетом не означают.
I>>В итоге надо писать своё хеширование. toString или нет, это дело десятое.
vsb>toString это конвертация объекта в строку, а не хеширование.
Я же внятно сказал — надо писать своё хеширование — понятно что это означает ?
toString или нет, это дело десятое — понятно что это означает ?
>В том и беда JS, он постоянно всё подпирает костылями. Если я пишу своё хеширование, я его могу протестировать на данных, улучшить. Я чётко понимаю, как работает это хеширование. Как работает хеширование на toString-е? Это загадка, покрытая мраком. Очевидно только, что в каждом браузере по-разному. Ну и вообще я хочу иметь нормальный toString для отладки. Какое он отношение имеет к хешированию?
У меня ощущение, что тебя ктото запрещает свои методы вводить.
I>>Задачи какие решаешь ?
vsb>Разные задачи. Не понимаю вопроса.
Опиши внятно что за область, обработка звука, вычисления или еще что.
>Ну банально — приходят данные, их надо вставлять в упорядоченный список (например по имени). Если у меня есть дерево, я просто строю дерево по имени и вставляю, операция вставки занимает O(1), всё моментально обновляется. Если у меня нет дерева, мне приходится использовать массив, двоичным поиском искать место для вставки (кстати какая стандартная функция в JS для двоичного поиска?) и впихивать туда элемент, получая O(N) и тормоза.
Ты описываешь какую то свою вычислительную модель. В зависимости от других сведений, которые ты стесняешься сообщить, тебе может сгодиться и образца 80х Бейсик а может быть не хватит и шаблонов С++
I>>Ты лучше про задачу расскажи, а то ты выдаёшь клочки какого то своего решения.
vsb>Я описываю, зачем в стандартной библиотеке любого языка нужны общепринятые коллекции.
Не любого и везде разные. Вот в С++ есть dequee, а в дотнете нет — ужос. Всяких мега-деревьев в дотнете тоже нет — снова ужос.
I>>Это отстой. Ты задачу какую решаешь ? У меня в проекте около 7 мб джаваскрипта и я не наблюдаю тех ужасов, о которых ты говоришь Надо полагать я чтото не так делаю ?
vsb>Не знаю, что ты не так делаешь. Писать можно и на бейсике, если аккуратно. Это не отменяет минусов языка. Как минимум нужно знать про все расставленные грабли. Нужно помнить, что map передаёт в функцию-маппер не просто объект а ещё и его индекс и исходную коллекцию с какого то фига.
И это правильно. Вот есть у тебя функция, которая для элемента i возвращает скажем, усредненное значение по соседним элементам , значение. Покажи как ты применишь не передавая в маппер ни индекс, ни исходную коллекцию.
>Нужно помнить про все особенности parseInt, про то, что в старых браузерах он 010 пропарсит как 8, а в новых как 10, нужно помнить, что parseInt возвращает NaN для ошибок, но не всегда, а только если не смог пропарсить даже первый символ. И куча подобных мелочей. Огромная куча нелогичного контекста.
Чудеса, в JS мизерная стандартная библиотека, в ней три с половиной функции. В дотнете том же сотни классов и в каждом из них есть нелогичности в методах. В джаве — тоже самое. В С++ в принципе более менее нормально.
Берешь в инете любую библиотеку для любого языка и найдешь вагоны нестыковок и их будет на порядки больше, чем в джаваскриптовой полу-библиотете.
С другими языками тебя это не смущает, а в джаваскриптом пугает ажно спать не можешь.
Реальность примерно такая — стандартная библиотека джаваскрипта это 1% необходимого для работы функционала, в ней основные функции это те, что в Array и String. Все юзать не надо — не понимаешь как работает функция — не используй. Не нравится — не используй.
Объяснение простое — для реальной работы в стандартной либе есть 1% необходимого для работы функционала.
Здравствуйте, Ikemefula, Вы писали:
I>Скажем, если взять DOM, то таких нелогичностей будет на два-три порядка больше
Грабли DOM каким-то магическим образом отменяют грабли JS.
I>Есть целый сайт, wtf.js, там много нестыковок. Представь, ни одна из них и даже почти все вместе они ничего ровным счетом не означают.
Бгг. Оver 9000 граблей и целые сайты занимательных wtf ничего не означают, over 9К фреймворков(когда я в послелний раз интересовался я нашёл сотни три, но я не сильно активно искал), так или иначе реализуют "классический" ООП поверх js ничего не означают, over 9K велосипедов(см ссылку выше), что бы писать не на JS а на чём-то другом тоже.
Это называется "хоть плюй в глаза — всё то Божья роса".
Здравствуйте, Yoriсk, Вы писали:
I>>Скажем, если взять DOM, то таких нелогичностей будет на два-три порядка больше
Y>Грабли DOM каким-то магическим образом отменяют грабли JS.
Если ты работаешь с DOM, то у тебя голова в 99% занята вовсе не языком программирования.
I>>Есть целый сайт, wtf.js, там много нестыковок. Представь, ни одна из них и даже почти все вместе они ничего ровным счетом не означают.
Y>Бгг. Оver 9000 граблей и целые сайты занимательных wtf ничего не означают,
Эти "целые сайты", во первых, содержат кучу ошибок, во вторых, слишком часто делают из мухи слона, и, самое главное, показывают одно и то же.
>over 9К фреймворков(когда я в послелний раз интересовался я нашёл сотни три, но я не сильно активно искал), так или иначе реализуют "классический" ООП поверх js ничего не означают, over 9K велосипедов(см ссылку выше), что бы писать не на JS а на чём-то другом тоже.
Ты наверное чего то не понимаешь — JS сейчас самый массовый язык. На нём пишет людей больше, чем на любом из оставшихся языков. Вот какой фокус — сейчас днем с огнем надо искать программиста с опытом, который не знает джаваскрипт и не пишет на нём хотя бы время от времени.
Отсюда растут фремворки — программисты, известно, учиться не любят и больше всего обожают изобретать велосипеды.
Y>Это называется "хоть плюй в глаза — всё то Божья роса".
У меня в данный момент это основной язык, а у тебя только сказки из интернета.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, Sharov, Вы писали:
S>>А у каких библиотек, платформ есть легковесные потоки, не считя erlang?
EP>В Rust вроде встроены зелёные потоки.
И всё ? С учетом того, что Rust по большому счету еще никуда не вышел, остаётся только Эрланг.
>А так, наборы "сделай сам" в виде coroutines/fibers есть практически для всех языков — C++, D, Go, Python.
И животноводтство. Если эти вещи использовать один к одному вместо потоков, то Адъ И Израиль гарантирован.
Здравствуйте, vsb, Вы писали:
vsb>Модель обслуживания выбрана спорная. Легковесные потоки по всем параметрам предпочтительней. И работают не хуже, и многопроцессорность можно сделать, и код получается читабельным, а не лапша из коллбэков.
Хуже, намного хуже. Синхронный код давно уперся в потолок. Сейчас софт, который сильно завязан на IO, очень неэффективный, если написан синхронным кодом. 99% времени такой софт занимается ожиданием IO.
25 лет назад IO можно было подождать просто выполняя десяток-другой холостых циклов. Сейчас для ожидания IO надо заводить сервисный поток, ибо холостые циклы это слишком дорого, или делать ожидание унутре основного потока.
Лапшу из колбеков можно устранить многими путями
1. промисы
2. новый стандарт, промисы заменить на короутины и тд
3. язык навроде Coffee или Typescript
Многопроцессорность это ни о чем. node.js нужен там, где мало вычислений и много IO или коммуникации. Они никогда не догонит С++, потому вариант с многопроцессорностью это тупик.
Зато многопроцессорные системы можно и нужно использовать с node.js — эта хрень очень качественно масштабируется. С++ так не умеет.
vsb>ЯП спорный. Сам по себе JS мне очень нравится, но наслоения со времён 90-х, невнятная стандартная библиотека, это всё делает его очень спорным выбором.
У JS есть большой плюс — адски простое метапрограммирование, настолько простое, что даже студенты сами не замечают, как начинают пользоваться.
vsb>Ещё мне понравилось коммьюнити. Очень интересные миниатюрные библиотеки, отличное качество документации. Но это, наверное, не заслуга языка. Поэтому пока интересует исключительно технические плюсы.
Это именно заслуга языка. Сейчас это самый массовый язык, его аудитория намного больше аудитории любого другого языка.
Отсюда следствие — для написания либ полно квалифицированых рук, а не так как в с++ — язык знает много экспертов, а ни одной нормальной либы до сих пор нет.
Здравствуйте, Ikemefula, Вы писали:
I>Хуже, намного хуже. Синхронный код давно уперся в потолок. Сейчас софт, который сильно завязан на IO, очень неэффективный, если написан синхронным кодом. 99% времени такой софт занимается ожиданием IO.
9000 потоков ожидают IO 1000 потоков ждут пока им дадут процессор, 4 потока работают. Что тут неэффективного? Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Ikemefula, Вы писали:
I>>Хуже, намного хуже. Синхронный код давно уперся в потолок. Сейчас софт, который сильно завязан на IO, очень неэффективный, если написан синхронным кодом. 99% времени такой софт занимается ожиданием IO.
vsb>9000 потоков ожидают IO 1000 потоков ждут пока им дадут процессор, 4 потока работают. Что тут неэффективного?
Каждый из этих потоков ест адресное пространство, кучу памяти и вносит общую производительность.
>Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
Назови такой язык, кроме эрланга, где есть легковесный поток весом в одно замыкания для колбека.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, vsb, Вы писали:
vsb>>Здравствуйте, Ikemefula, Вы писали:
I>>>Хуже, намного хуже. Синхронный код давно уперся в потолок. Сейчас софт, который сильно завязан на IO, очень неэффективный, если написан синхронным кодом. 99% времени такой софт занимается ожиданием IO.
vsb>>9000 потоков ожидают IO 1000 потоков ждут пока им дадут процессор, 4 потока работают. Что тут неэффективного?
I>Каждый из этих потоков ест адресное пространство, кучу памяти и вносит общую производительность.
Если легковесный, кучу памяти не ест и на производительность не влияет.
>>Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
I>Назови такой язык, кроме эрланга, где есть легковесный поток весом в одно замыкания для колбека.
Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
Здравствуйте, vsb, Вы писали:
>>>Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
I>>Назови такой язык, кроме эрланга, где есть легковесный поток весом в одно замыкания для колбека.
vsb>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
Еще кусочек экзотики. Такие языки будут востребованы, когда легковесные потоки будут поддерживаться в ОС, потому что вся эта лёгкость это на деле фейк.
Кроме того, в браузерах еще долго ничего кроме JS не будет.
Здравствуйте, Ikemefula, Вы писали:
>>>>Неэффективно тут будет с расходом памяти, если поток идентичен потоку ОС, но если поток легковесный, то он занимает размер такого же порядка, как и размер замыкания для callback-а и в итоге эта модель ничем не хуже. Callback-и это и есть имитация легковесных потоков, только без нормальной поддержки компилятора.
I>>>Назови такой язык, кроме эрланга, где есть легковесный поток весом в одно замыкания для колбека.
vsb>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
I>Еще кусочек экзотики.
Почему экзотики? Вполне практичный язык, как я понимаю. Своё место он уже занял и в ближайшее время никуда не денется.
I> Такие языки будут востребованы, когда легковесные потоки будут поддерживаться в ОС, потому что вся эта лёгкость это на деле фейк.
Легковесность в том числе подразумевает отсутствие переключений контекста. Если ОС переключает множество потоков, выходит довольно большой процент накладных расходов. Какого рода поддержка от ОС нужна? Всё, что нужно для легковесных потоков — планировщик потоков (в программе), вставка определенных инструкций в код в некоторых местах (желательно, чтобы вечный цикл в одном потоке не вешал всю программу) и вызов этого планировщика в библиотечных функциях I/O.
I>Кроме того, в браузерах еще долго ничего кроме JS не будет.
Это относится к серверному софту, браузеру эти вещи ни к чему.
Здравствуйте, vsb, Вы писали:
vsb>>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
I>>Еще кусочек экзотики.
vsb>Почему экзотики? Вполне практичный язык, как я понимаю. Своё место он уже занял и в ближайшее время никуда не денется.
Практичный это язык который хотя бы в десятке массовых. А язык который появился вчера и у него только местечковое применение это экзотика.
Нравится — пиши на нём, зачем тебе плохой джаваскрипт ?
I>> Такие языки будут востребованы, когда легковесные потоки будут поддерживаться в ОС, потому что вся эта лёгкость это на деле фейк.
I>>Кроме того, в браузерах еще долго ничего кроме JS не будет.
vsb>Это относится к серверному софту, браузеру эти вещи ни к чему.
Ну тогда тебе и джаваскрипт не нужен, пиши на эрланге, там как раз нужные тебе легкие потоки.
Здравствуйте, vsb, Вы писали:
vsb>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
Здравствуйте, Sharov, Вы писали:
vsb>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
S>миллион соединений операционка не потянет...
Здравствуйте, Ikemefula, Вы писали:
vsb>>>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти.
I>>>Еще кусочек экзотики.
vsb>>Почему экзотики? Вполне практичный язык, как я понимаю. Своё место он уже занял и в ближайшее время никуда не денется.
I>Практичный это язык который хотя бы в десятке массовых. А язык который появился вчера и у него только местечковое применение это экзотика.
node и современный JS появился совсем недавно.
I>Нравится — пиши на нём, зачем тебе плохой джаваскрипт ?
Формирую мнение о технологиях, чтобы делать правильный выбор.
I>>> Такие языки будут востребованы, когда легковесные потоки будут поддерживаться в ОС, потому что вся эта лёгкость это на деле фейк.
I>>>Кроме того, в браузерах еще долго ничего кроме JS не будет.
vsb>>Это относится к серверному софту, браузеру эти вещи ни к чему.
I>Ну тогда тебе и джаваскрипт не нужен, пиши на эрланге, там как раз нужные тебе легкие потоки.
Эрланг чересчур чужеродный на мой взгляд. Но свои плюсы у него, конечно, есть. Это уже тема отдельного обсуждения.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, vsb, Вы писали:
S>>>миллион соединений операционка не потянет...
vsb>>Почему?
S>Тут неплохое обсуждение и ссылки полезные.
Ну в итоге всё упирается в память. Никаких проблем обслуживать миллион соединений на хорошем сервере я не вижу, если аккуратно всё написать.
Здравствуйте, vsb, Вы писали:
vsb>Ну в итоге всё упирается в память. Никаких проблем обслуживать миллион соединений на хорошем сервере я не вижу, если аккуратно всё написать.
Здравствуйте, vsb, Вы писали:
>>Практичный это язык который хотя бы в десятке массовых. А язык который появился вчера и у него только местечковое применение это экзотика.
vsb>node и современный JS появился совсем недавно.
Ну да, 15 лет это копейки.
I>>Ну тогда тебе и джаваскрипт не нужен, пиши на эрланге, там как раз нужные тебе легкие потоки.
vsb>Эрланг чересчур чужеродный на мой взгляд. Но свои плюсы у него, конечно, есть. Это уже тема отдельного обсуждения.
Есть только один способ внятно оценить язык — решить на нем какую нибудь важную для тебя задачу. Незачем протаскивать язык в продакшн, что бы оценить выхлоп. Если это много времени, возьми либу из твоей области и посмотри внутрь.
Если либ в твоей области нет, то однозначно ты хочешь чудес.
Здравствуйте, Sharov, Вы писали:
vsb>>Ну в итоге всё упирается в память. Никаких проблем обслуживать миллион соединений на хорошем сервере я не вижу, если аккуратно всё написать.
S>От операционки все же:
S>
S>... которая в свою очередь ограничена железом. Т.е. своими усилиями аккуратно не получиться. Необходимо S>совместное взаимодействие.
Дескриптор это 4-байтовое целое, физическое ограничение — миллиарды. Можно искусственно его ограничить, как это обычно делается, чтобы сошедшая с ума программа не положила всю ОС, но это всё настраивается, если такая нужда возникнет.
Здесь скорее вопрос в алгоритмах TCP-стека, достаточно ли они хороши и масштабируются на такое количество потоков. Но по идее всё должно быть нормально, Linux в хайлоаде используется не первый год.
vsb>Дескриптор это 4-байтовое целое, физическое ограничение — миллиарды. Можно искусственно его ограничить, как это обычно делается, чтобы сошедшая с ума программа не положила всю ОС, но это всё настраивается, если такая нужда возникнет.
vsb>Здесь скорее вопрос в алгоритмах TCP-стека, достаточно ли они хороши и масштабируются на такое количество потоков. Но по идее всё должно быть нормально, Linux в хайлоаде используется не первый год.
Не спорю, а какой до селе придел соединений на одну машину? Миллион все-таки крутова-то.
А на линупс я бы не смотрел, поскольку он используется по известным причинам.
А вот серверная венда интересна в этом плане. Думаю у нее планка повыше будет, но она и подороже.
Здравствуйте, Sharov, Вы писали:
S>А на линупс я бы не смотрел, поскольку он используется по известным причинам. S>А вот серверная венда интересна в этом плане. Думаю у нее планка повыше будет, но она и подороже.
ROTFL.
Здравствуйте, Ikemefula, Вы писали:
>>>Практичный это язык который хотя бы в десятке массовых. А язык который появился вчера и у него только местечковое применение это экзотика.
vsb>>node и современный JS появился совсем недавно.
I>Ну да, 15 лет это копейки.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, Sharov, Вы писали:
vsb>>>Ну в итоге всё упирается в память. Никаких проблем обслуживать миллион соединений на хорошем сервере я не вижу, если аккуратно всё написать.
S>>От операционки все же:
S>>
S>>... которая в свою очередь ограничена железом. Т.е. своими усилиями аккуратно не получиться. Необходимо S>>совместное взаимодействие.
vsb>Дескриптор это 4-байтовое целое, физическое ограничение — миллиарды.
Это чушь. Путь задаётся строкой , но почему то длина пути MAX_PATH в виндовс всего 260 символов.
Пример понятен ?
С дескрипторами тоже самое — физическое ограничение это какая то константа, которая завязана на особенности ввода вывода или управления памятью еще в ДОС 4.0
>Можно искусственно его ограничить, как это обычно делается, чтобы сошедшая с ума программа не положила всю ОС, но это всё настраивается, если такая нужда возникнет.
Ну настрой MAX_PATH, а то мне мало 260 символов.
vsb>Здесь скорее вопрос в алгоритмах TCP-стека, достаточно ли они хороши и масштабируются на такое количество потоков. Но по идее всё должно быть нормально, Linux в хайлоаде используется не первый год.
Здравствуйте, vsb, Вы писали:
vsb>>>node и современный JS появился совсем недавно.
I>>Ну да, 15 лет это копейки.
vsb>node появился в 2009 году. go тоже.
node это просто фремворк. Он популярен в первую очередь потому, что основной язык это джаваскрипт, который сейчас знает почти каждый разработчик
Отсюда понятно, почему аудитория нода на порядки превышает аудиторию go
Здравствуйте, Sharov, Вы писали:
vsb>>Go. Весом в одно замыкание он не обязан быть, достаточно веса, приемлемого для практики. 10 килобайтов скажем приемлемо, даже миллион соединений будут занимать всего 10 гигабайтов памяти. S>миллион соединений операционка не потянет...
Операционка как раз потянет. Сотни тысяч соединений на одном сервере делаются при желании.
Проблема в другом — если на миллионе соединений получать по одному пакету в минуту, то это уже окло 40 тысяч пакетов в секунду. Сетевой стек это ещё выдержит, но вот всё остальное уже загнётся совершенно точно.
Далее, минимальный размер очередей и обслуживающих структур для соединения в Линуксе — это окло 4Кб. Плюс ещё 4-8Кб транзиентных данных. Для миллиона соединений это около 4Гб и 4-8Гб транзиентных. На таких объёмах уже будут происходить вторичные эффекты из-за промахов в кэше, так как внутренние структуры сети не оптимизированы под такой абьюз.
Тем не менее, миллион соединений достижим в лабораторных условиях.
Здравствуйте, Ikemefula, Вы писали:
I>Лапшу из колбеков можно устранить многими путями I>1. промисы I>2. новый стандарт, промисы заменить на короутины и тд I>3. язык навроде Coffee или Typescript
В Питоне используют gevent и не занимаются фигнёй. Stackfull coroutines — наше фсьо.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
S>>А на линупс я бы не смотрел, поскольку он используется по известным причинам. S>>А вот серверная венда интересна в этом плане. Думаю у нее планка повыше будет, но она и подороже.
C>Ровно наоборот ситуация.
Угу, сглупил. Когда написал комментарий, тут же подумал, что не прав.
Поскольку венду в силу понятных причин для хайлода никто использовать не будет, то там на эти вещи
видимо слегка подзабили.
C>Проблема в другом — если на миллионе соединений получать по одному пакету в минуту, то это уже окло 40 тысяч пакетов в секунду. Сетевой стек это ещё выдержит, но вот всё остальное уже загнётся совершенно точно.
Все остальное это что?
C>На таких объёмах уже будут происходить вторичные эффекты из-за промахов в кэше, так как внутренние структуры сети не оптимизированы под такой абьюз.
Что понимается под внутренней структурой сети? Не очень понятна связь промахов в кэше с их неоптимизированностью.
Я не хайлоад-программист, если что, потому могу спросить странную вещь.
C>Тем не менее, миллион соединений достижим в лабораторных условиях.
Здравствуйте, Cyberax, Вы писали:
I>>Лапшу из колбеков можно устранить многими путями I>>1. промисы I>>2. новый стандарт, промисы заменить на короутины и тд I>>3. язык навроде Coffee или Typescript C>В Питоне используют gevent и не занимаются фигнёй. Stackfull coroutines — наше фсьо.
В node.js тоже есть stackfull короутины. Насколько я понял, ТС сам не знает, где ему нужен джаваскрипт, не то в браузере, не то на сервере.
Здравствуйте, Sharov, Вы писали:
C>>Проблема в другом — если на миллионе соединений получать по одному пакету в минуту, то это уже окло 40 тысяч пакетов в секунду. Сетевой стек это ещё выдержит, но вот всё остальное уже загнётся совершенно точно. S>Все остальное это что?
Обработчики, которые будут с пакетами делать что-нибудь полезное.
C>>На таких объёмах уже будут происходить вторичные эффекты из-за промахов в кэше, так как внутренние структуры сети не оптимизированы под такой абьюз. S>Что понимается под внутренней структурой сети? Не очень понятна связь промахов в кэше с их неоптимизированностью.
Под сетевые соединения в ядре выделяются объекты, которые отслеживают их состояние (sk_buff и связанные с ним). Там используются структуры, которые плохо масштабируются для больших объёмов, так что процессор будет при обращении к этим структурам вынужден постоянно прыгать по всей RAM.
C>>Тем не менее, миллион соединений достижим в лабораторных условиях. S>Сначала сделайте хотя бы в лабораторных условиях.
Делали 250k. До миллиона можно было бы довести, но не было смысла.
Здравствуйте, Cyberax, Вы писали:
C>>>На таких объёмах уже будут происходить вторичные эффекты из-за промахов в кэше, так как внутренние структуры сети не оптимизированы под такой абьюз. S>>Что понимается под внутренней структурой сети? Не очень понятна связь промахов в кэше с их неоптимизированностью. C>Под сетевые соединения в ядре выделяются объекты, которые отслеживают их состояние (sk_buff и связанные с ним). Там используются структуры, которые плохо масштабируются для больших объёмов, так что процессор будет при обращении к этим структурам вынужден постоянно прыгать по всей RAM.
Значит все-таки в ограничения или недостатки реализации ОС уперлись?
S>>Сначала сделайте хотя бы в лабораторных условиях. C>Делали 250k. До миллиона можно было бы довести, но не было смысла.
Здравствуйте, Sharov, Вы писали:
C>>Тем не менее, миллион соединений достижим в лабораторных условиях. S>Сначала сделайте хотя бы в лабораторных условиях.
Итоги эксперимента:
"Node.js v0.8 позволяет обрабатывать 1 млн одновременных HTTP Comet соединений на Intel Core i7 Quad/16 Gb RAM практически без дополнительных настроек."
Автор приводит подробные инструкции по повторению эксперимента, так что можно все проверить самому.
Здравствуйте, Sharov, Вы писали:
C>>Под сетевые соединения в ядре выделяются объекты, которые отслеживают их состояние (sk_buff и связанные с ним). Там используются структуры, которые плохо масштабируются для больших объёмов, так что процессор будет при обращении к этим структурам вынужден постоянно прыгать по всей RAM. S>Значит все-таки в ограничения или недостатки реализации ОС уперлись?
Это скорее просто ограничения, связанные с целевым примененим. Делать миллион соединений просто не имеет никакого смысла.
S>>>Сначала сделайте хотя бы в лабораторных условиях. C>>Делали 250k. До миллиона можно было бы довести, но не было смысла. S>А где можно почитать?
Мы это для себя делали — тупо брали libuv и запускали на тестовом стенде.
Ты лучше задачи расскажи, которые тебе надо решать.
