Comments 90
Сделали бы сборку мусора отдельным потоком.
штука полезная, я думаю гугл это направление быстро раскачает, что будет только на пользу
Скорее бы в NodeJS новый движок появился, там это будет очень актуально
Крутовато.
Так еще пару раз и я выкину свой ICC
Так еще пару раз и я выкину свой ICC
«Вы не поверите», но отдельные личности уже сделали биндинг FFTW3 для Node.js. Скоростью не интересовался, но самим фактом был поражён.
Ура! node.js станет еще лучше!
Блин, зависть гложет. На питоновый jit они похоже забили :(
UFO just landed and posted this here
Можно линк? Или просто поподробнее, что-то нагуглить не смог
UFO just landed and posted this here
Я думал что-то ещё, именно официальное заявление и рекомендации всем программистам, а не просто констатация факта, что во внутренних процессах они python избегают по таким-то причинам. Как я уже говорил (хорошая у Вас память :) ) требования к проектам гугла несколько отличаются от требований простых смертных…
Гугл рекомендовал перейти? Что за бред. Вы по ссылке то своей пройдите, прочтите внимательно, и не несите чушь.
UFO just landed and posted this here
Вы чувствуете разницу между «у Google есть более приоритетные проекты» и «рекомендуем не использовать этот язык»? :)
UFO just landed and posted this here
То есть очень лень подтверждать свои слова? Ну тогда может не стоит высказываться столь сомнительно?
Простите, Вы реально не понимаете, или прикидываетесь? Если крупная компания вкладывает огромные ресурсы что бы начать проект, а потом закрывает его. О чем это говорит? Вы так же видимо не понимаете, что сотрудники такой компании не могут и никогда не скажут Вам открыто, что Python бесперспективен и компания рекомендует перейти на другие языки при создании новых проектов. Вы понимаете, как такое заявление будет воспринято такими фанатиками как Вы, и какие последствия будут у таких заявлений? Видимо нет.
Если у Вас достаточно свободного времени, be my guest и прочитайте больше 4 тысяч сообщений в группе, при должном внимании Вы сможете найти нужное. Большинству же достаточно этого сообщения что бы понять что думает Google о Python.
Считаю разговор закрытым.
Если у Вас достаточно свободного времени, be my guest и прочитайте больше 4 тысяч сообщений в группе, при должном внимании Вы сможете найти нужное. Большинству же достаточно этого сообщения что бы понять что думает Google о Python.
Считаю разговор закрытым.
Я не понимаю, как google может рекомендовать язык? Facebook использует php, следует ли все проекты писать на php? Все крупные компании переписывают критичные куски не то что на C, на ассемблере, всем программировать на ассемблере?
Вы городите чушь. Вот когда вы будете размером с google, тогда вам использование python, ruby, etc может очень дорого встать, но до таких масштабов надо дорасти.
И еще — расскажите, на чем же рекомендует разрабатывать google, раз уж у вас с ним ментальная связь, и вы зрите между строк.
И да, я думаю на двух программистах google разорился просто, им было нелегко прекратить финансирование столь важного проекта, после таких тотальных растрат.
Вы городите чушь. Вот когда вы будете размером с google, тогда вам использование python, ruby, etc может очень дорого встать, но до таких масштабов надо дорасти.
И еще — расскажите, на чем же рекомендует разрабатывать google, раз уж у вас с ним ментальная связь, и вы зрите между строк.
И да, я думаю на двух программистах google разорился просто, им было нелегко прекратить финансирование столь важного проекта, после таких тотальных растрат.
> Если крупная компания вкладывает огромные ресурсы что бы начать проект, а потом закрывает его. О чем это говорит?
Это говорит о том, что проект не выстрелил. И причин тут может быть много. Вот GoogleWave не выстрелил, Google Buzz не выстрелил, Orkut не выстрелил, это если только гугловые вещи смотреть. Почему не выстрелили — каждый по своей причине. Это не значит, что всё — социальные сети это мертворожденная идея, инкерементальное версионное общения с широким спектром типов контента — мертворожденная идея и т.п. и гугл не рекомендует никому ничего такого писать.
Что касается питона, то он не подходит для них по причинам, которые они обозначили. Нормальные люди с мозгами воспримут эту информацию так «в условиях, в которых находятся сервисы Google питон как язык не окупается в бизнес-модели Google». Если у них сильно другая бизнес-модель или сильно другие условия у сервисов, то им бояться нечего.
Более того, в Google не дураки, чтобы утверждать глупости вроде «Python бесперспективен».
Это говорит о том, что проект не выстрелил. И причин тут может быть много. Вот GoogleWave не выстрелил, Google Buzz не выстрелил, Orkut не выстрелил, это если только гугловые вещи смотреть. Почему не выстрелили — каждый по своей причине. Это не значит, что всё — социальные сети это мертворожденная идея, инкерементальное версионное общения с широким спектром типов контента — мертворожденная идея и т.п. и гугл не рекомендует никому ничего такого писать.
Что касается питона, то он не подходит для них по причинам, которые они обозначили. Нормальные люди с мозгами воспримут эту информацию так «в условиях, в которых находятся сервисы Google питон как язык не окупается в бизнес-модели Google». Если у них сильно другая бизнес-модель или сильно другие условия у сервисов, то им бояться нечего.
Более того, в Google не дураки, чтобы утверждать глупости вроде «Python бесперспективен».
Не надо читать между строк то, чего там нет. Сотрудник гугла прямо говорит, что гугл забил на US.
Все собственно, о чем он говорит. Он не говорит, что теперь весь гугл дрочит на V8.
Надеюсь на то, что вы усмирите свое воображение.
Все собственно, о чем он говорит. Он не говорит, что теперь весь гугл дрочит на V8.
Надеюсь на то, что вы усмирите свое воображение.
PyPy нас спасёт. Лет через 20. :)
Просто оставлю это здесь: fprog.ru/2010/issue6/dmitry-demeshchuk-node.js-vs-erlang/
Да-да, читали…
В смысле это я насчет Node.JS.
А за сам движок v8 бескрайне рад!
Это ж надо умудриться создать интерпретатор довольно мощного языка программирования таким, что он успевает проделать парсинг, кучу оптимизаций, jit компиляцию в код, сравнимый по скорости работы с компилируемыми языками, за то время, пока у меня открывается страничка в браузере!
А за сам движок v8 бескрайне рад!
Это ж надо умудриться создать интерпретатор довольно мощного языка программирования таким, что он успевает проделать парсинг, кучу оптимизаций, jit компиляцию в код, сравнимый по скорости работы с компилируемыми языками, за то время, пока у меня открывается страничка в браузере!
Не очень понятно, чему вы радуетесь? JS в Хроме отрезан от рендеринга. Быстрее страницы загружаться не будут.
Для минусующих фанатиков, которые с пеной у рта защищают якобы оболганый любимый браузер, поясняю. Для начала советую посмотреть вот эту статью, в которой есть пример того, что все супер-скорости V8 не спасают от проблемы с обратной связью от системы рендеринга. Ограниченичителем скорости является движок WebKit. А, как известно, скорость всей системы равняется по его самой медленной части.
Думаю минусуют не из-за этого, а потому что ваши слова только подтверждают слова seriyPS. Да и говорим мы тут в основном о V8, а не о Chrome :-)
Рассматривать v8 как отдельную сущность нельзя. Если он используется как компонент в общей системе, то надо рассматривать его именно как компонент. В посте seriyPS именно последняя его часть «за то время, пока у меня открывается страничка в браузере!» у меня вызывает претензии. V8 может тормозить именно потому, что страничка открывается.
Дурацкая статья ни о чем.
И на 100500% быстрее печатной машинки «IBM Wheelwriter 30».
Этот Crankshaft только в Chrome будет?
несколько уточнений к переводу:
«linear scan» это название семейства алгоритмов распределения регистров, которые оперируют на линеаризованном представлении графа потока управления, дословно не переводится.
«вычисление инвариантов циклов» => перемещение или вынос инвариантов цикла.
Дело не в том будет ли результирующий код быстрее, а в том выполняются ли предположения, при которых он был скомпилирован (предположения могут касаться, например, типов значений, которые могут оказаться в определенной переменной, или структуры цепочки прототипов некоторого объекта). Если оптимизированный код обнаруживает, что предположения, от которых зависит его корректная работа, нарушаются, то происходит возврат к неоптимизированному коду, который всегда корректен.
для таких оптимизаций, как вычисление инвариантов циклов, вынесение общих подвыражений и кода в ветвлениях, последовательное распределение регистров и встраивание.
«linear scan» это название семейства алгоритмов распределения регистров, которые оперируют на линеаризованном представлении графа потока управления, дословно не переводится.
«вычисление инвариантов циклов» => перемещение или вынос инвариантов цикла.
В случае, если результирующий код не будет быстрее, есть возможность вернуться к выполнению кода, полученного базовым компилятором.
Дело не в том будет ли результирующий код быстрее, а в том выполняются ли предположения, при которых он был скомпилирован (предположения могут касаться, например, типов значений, которые могут оказаться в определенной переменной, или структуры цепочки прототипов некоторого объекта). Если оптимизированный код обнаруживает, что предположения, от которых зависит его корректная работа, нарушаются, то происходит возврат к неоптимизированному коду, который всегда корректен.
Спасибо за пояснения :)
Хочу уточнить насчёт оптимистичности предположений: неужели возможен случай, когда генерируется некорректный код? Или, всё-таки, код получается верный, но по каким-то причинам раздутый?
Хочу уточнить насчёт оптимистичности предположений: неужели возможен случай, когда генерируется некорректный код? Или, всё-таки, код получается верный, но по каким-то причинам раздутый?
ну смотря что понимать под некорректным =)
наивный такой пример (не соответствует полностью действительности, но суть передает):
в оптимизированном коде загрузка поля будет выглядить примерно так:
в не оптимизированном:
вот этот код
Может возникнуть вопрос: проверка же вроде и там и там есть, в чем же цимес?
Существенное отличие тут в том, что в оптимизированный код перестает выполняться когда уловие нарушается: получается, что если проверка прошла, то предположение верно на оставшемся куске оптимизированного кода (либо на «оставшемся» куске кода без побочных эффектов, зависит от свойства которое проверяется). Это открывает множество возможностей для оптимизации, которые до этого были закрыты постоянными
наивный такой пример (не соответствует полностью действительности, но суть передает):
в оптимизированном коде загрузка поля будет выглядить примерно так:
if not (object obj has field x by offs y) then deoptimize; v = *(addressof(obj) + y)
в не оптимизированном:
if (object obj has field x by offs y) then v = *(addressof(obj) + y) ; inlined cache for common case else GenericLoadProperty(obj, 'x') ; call runtime function end
вот этот код
v = *(addressof(obj) + y) верен только в предположениях относительно «типа» obj. проверка if not (object obj has field x by offs y) then deoptimize; называется guard'ом, она проверяет корректность предположений. Может возникнуть вопрос: проверка же вроде и там и там есть, в чем же цимес?
Существенное отличие тут в том, что в оптимизированный код перестает выполняться когда уловие нарушается: получается, что если проверка прошла, то предположение верно на оставшемся куске оптимизированного кода (либо на «оставшемся» куске кода без побочных эффектов, зависит от свойства которое проверяется). Это открывает множество возможностей для оптимизации, которые до этого были закрыты постоянными
if then else end в коде. Ведь после end нельзя было сказать, какая ветвь исполнилась. Спасибо :-) Надо будет почитать англоязычную википедию на тему компиляторов и оптимизаторов.
О! Разработчик v8 детектед!
Для начала выражаю огромную благодарность за то, что во многом благодаря вам так ускорился современный web и за то, что показываете что нет предела совершенству))
И теперь вопрос: как вы относитесь к NodeJS? Как считаете, подходит ли v8 для написания серверных приложений? Какие могут быть подводные камни? Рассчитан ли v8 на такое использования?
Для начала выражаю огромную благодарность за то, что во многом благодаря вам так ускорился современный web и за то, что показываете что нет предела совершенству))
И теперь вопрос: как вы относитесь к NodeJS? Как считаете, подходит ли v8 для написания серверных приложений? Какие могут быть подводные камни? Рассчитан ли v8 на такое использования?
Лично я отношусь к node.js положительно: пользовательская база от этого расширяется.
Оценить пригодность V8 в целом для написания произвольного серверного приложения я не могу, приложения то бывают разные. Страничка на PHP тоже в каком-то смысле серверное приложение.
Из подводных камней могу упомянуть проблемы со сборкой мусора на боооольших кучах и общий лимит кучи 1.9gb.
Оценить пригодность V8 в целом для написания произвольного серверного приложения я не могу, приложения то бывают разные. Страничка на PHP тоже в каком-то смысле серверное приложение.
Из подводных камней могу упомянуть проблемы со сборкой мусора на боооольших кучах и общий лимит кучи 1.9gb.
Да, пожалуй эти две проблемы являются самыми заметными в серверном коде… Когда израсходовано много оперативной памяти то GC начинает есть много CPU и замедляет приложение.
а постойте, погодите. я что-то не сразу сложил foo и bar сообразил, что вы написали для ВК XMPP сервер на node.js.
Очень, конечно, интересно было бы услышать ваш так сказать опыт. Насколько большие кучи вы жаждете и насколько маленькие паузы. И как сейчас вы боретесь с несовершеннствами сборщика.
Очень, конечно, интересно было бы услышать ваш так сказать опыт. Насколько большие кучи вы жаждете и насколько маленькие паузы. И как сейчас вы боретесь с несовершеннствами сборщика.
по 8 воркеров на машине работают более менее нормально, хотя недавно был нападок спамеров, которые сильно мучали сервера (пришлось усилить флудконтроль)
Ещё приходится перезагружать воркеры… это делается плавно, вечером запускаются новые а старые перестают принимать новые соединения, утром старые убиваются…
Сейчас примерно такая картина:
Cpu(s): 19.2%us, 0.7%sy, 0.0%ni, 79.1%id, 0.0%wa, 0.5%hi, 0.4%si, 0.0%st
heap ~ 113076624 на воркер
Ситация с GC видится совсем не смертельной, за удобство нужно платить. Иногда задержки ощущаются но тоже не смертельно.
Ещё приходится перезагружать воркеры… это делается плавно, вечером запускаются новые а старые перестают принимать новые соединения, утром старые убиваются…
Сейчас примерно такая картина:
Cpu(s): 19.2%us, 0.7%sy, 0.0%ni, 79.1%id, 0.0%wa, 0.5%hi, 0.4%si, 0.0%st
heap ~ 113076624 на воркер
Ситация с GC видится совсем не смертельной, за удобство нужно платить. Иногда задержки ощущаются но тоже не смертельно.
Смысл в том, что оптимизация строится на основании статистики. Например, функция была вызвана 100 раз и всегда вызывалась с одним входящим параметром. Оптимизатор предположил, что она всегда вызывается с одним параметром и оптимизировал код так, что функция как будто всегда принимает один параметр — то есть получили частный случай, который работает гораздо быстрее общего. Но через тысячу вызовов этой функции, внезапно, делает ее вызов с двумя параметрами, что означает, что все таки функция может быть вызвана и с двумя параметрами, а значит оптимизация была опрометчивой, и есть большая вероятность того, что оптимизированный код будет выполнен неверно (так как он не учитывал второй параметр). В таком случае сбрасывается оптимизированный код и используется изначальный.
Пример, конечно, высосан из пальца, но, думаю, общий смысл понятен.
Пример, конечно, высосан из пальца, но, думаю, общий смысл понятен.
Читали недавно про ИЕ9 пост? Там интересный кусок про то, на чём они свой браузер тестируют, для каких кейзов.
В частности более не на скорость яваскрипта, а на скорость работы DOM, говорят что очень много искуственных тестов которые не ускоряют используемые реально пользователями сайты и случаи.
В частности более не на скорость яваскрипта, а на скорость работы DOM, говорят что очень много искуственных тестов которые не ускоряют используемые реально пользователями сайты и случаи.
У вебкитов вроде и без этого нет больших проблем с быстродействием дома
Если случай, который описан в моей статье, не является большой проблемой, то я медный тазик.
после случая с DCE верится во все это с трудом.
Все это уже начинает напоминать рекламу туши для ресниц. Если просуммировать все обещания за несколько лет «на 50% больше», то у несчастных девушек ресницы должны уже волочиться по земле.
Каждый новый движок JS все быстрее и быстрее предыдущего. По рекламе и «некоторым тестам». Кажется скоро упремся в скорость света. ;)
Каждый новый движок JS все быстрее и быстрее предыдущего. По рекламе и «некоторым тестам». Кажется скоро упремся в скорость света. ;)
>Если просуммировать все обещания за несколько лет «на 50% больше», то у несчастных девушек ресницы должны уже волочиться по земле.
Вы только рекламу прокладок не смотрите…
Вы только рекламу прокладок не смотрите…
ну так вы возьмите первую версию хрома и первую версию файрфокса, и прогуляйтесь на выходных по интернету, и сравните это с последними версиями того же хрома и файрфокса.
Глючит ;-)
Uncaught SyntaxError: Invalid regular expression: /^(#)?([\w-\*]+)/: Invalid character range
Uncaught SyntaxError: Invalid regular expression: /^(#)?([\w-\*]+)/: Invalid character range
Чёрт, вот вложился бы так же гугл в Racket…
-который и так примерно такой же по скорости, как V8 JS
-у которого уже есть опциональная (!) система типизации с выводом типов — Typed Racket, способная статически проверять типы в отдельных модулях программы или даже в отдельных регионах кода в модуле и использовать эти данные для оптимизации (в первую очередь unboxing), при этом всё, что нужно — указать сигнатуру функции;
-который, по сути, не отличается от JS по стилю написания кода (те же игрища с замыканиями/функциями первого порядка, да и вообще JS это лисп для бедных), но при этом имеет модули, сильнейшие макросистемы (их больше одной), нормальный JIT, полноценное ООП, достаточно большое количество кода и крайне сильную академическую команду.
А всё из-за непривычности скобочек и префикса, необходимых для прозрачности макросистемы. Мда. Правда, может быть, JS всё-таки постепенно развернёт мейнстрим в эту сторону…
-который и так примерно такой же по скорости, как V8 JS
-у которого уже есть опциональная (!) система типизации с выводом типов — Typed Racket, способная статически проверять типы в отдельных модулях программы или даже в отдельных регионах кода в модуле и использовать эти данные для оптимизации (в первую очередь unboxing), при этом всё, что нужно — указать сигнатуру функции;
-который, по сути, не отличается от JS по стилю написания кода (те же игрища с замыканиями/функциями первого порядка, да и вообще JS это лисп для бедных), но при этом имеет модули, сильнейшие макросистемы (их больше одной), нормальный JIT, полноценное ООП, достаточно большое количество кода и крайне сильную академическую команду.
А всё из-за непривычности скобочек и префикса, необходимых для прозрачности макросистемы. Мда. Правда, может быть, JS всё-таки постепенно развернёт мейнстрим в эту сторону…
Да ладно, чего уж там мелочиться, даешь хаскель в браузеры!
Вы это написали просто потому, что слово модное и «илитарное»? При чём тут хаскель-то? Сходство между JS, Racket и Haskell примерно такое же, как между пони, лошадью и снегом, соответственно. Подход, породивший Хаски, вообще никак не относится к JS, в отличие от.
И да, браузеры тут тоже не при чём. Речь в топике идёт о V8, использующемся, в том числе, для node.js.
И да, браузеры тут тоже не при чём. Речь в топике идёт о V8, использующемся, в том числе, для node.js.
Всем очевидно что гугл оптимизирует javascript потому что от javascript-а в вебе в обозримое время никуда не деться.
А то, что V8 юзается в node.js — это проблемы node.js. Гуглю node.js, как и вообще серверное применение V8, пофигу. Иначе этот V8 можно было бы хотя бы в нескольких инстансах на один процесс запускать и по ошибкам выделения памяти не крешиться (http://sysoev.ru/prog/v8.html).
А то, что V8 юзается в node.js — это проблемы node.js. Гуглю node.js, как и вообще серверное применение V8, пофигу. Иначе этот V8 можно было бы хотя бы в нескольких инстансах на один процесс запускать и по ошибкам выделения памяти не крешиться (http://sysoev.ru/prog/v8.html).
Статья Игоря относится к другому применению JS, которое не относится к «серверным языкам», прочитайте внимательно заголовок :-)
Не знаю к чему оно не относится, но к node.js оно относится. Именно поэтому с node.js нельзя загрузить 8-ми ядерный процессор не запуская 8 node.js-процессов.
Nginx тоже не загрузит 8-ми ядерный процессор на 100%, если у него будет 1 worker, разве не так? Не вижу ничего плохого в том, что нужно запускать 8 процессов node, наоборот это добавляет гибкости. Можно, например, запустить на одном сервере два приложения с разным количеством процессов в каждом, подстраиваясь под текущую нагрузку. Разве что рядовому разработчику может быть неприятно, что это нужно делать самостоятельно, но это разница исключительно из-за того, что Nginx является готовым приложением с конкретными задачами, а Node.js по сути своей фреймворк и вся логика приложений реализуется в user-land.
Если говорить об аргументе Игоря про время создания контекста, то этот минус сказывается только там, где он собирался применять JS: как альтернативу Perl при обработке каждого запроса, т.е. для «встраивания», как скриптовый язык в другом приложении. Для Node.js это не играет никакой роли, так как контекст создаётся один раз при старте приложения. Для браузеров это не играет роли, так как загрузка и отрисовка страницы обычно происходит дольше, чем создание контекста для JS и его выполнение. А вот для конкретного случая, когда контекст нужно бы было создавать при каждом поступающем в Nginx запросе — да, это не эффективно. Но это совершенно не перечёркивает использование V8 в других типах приложений.
Если говорить об аргументе Игоря про время создания контекста, то этот минус сказывается только там, где он собирался применять JS: как альтернативу Perl при обработке каждого запроса, т.е. для «встраивания», как скриптовый язык в другом приложении. Для Node.js это не играет никакой роли, так как контекст создаётся один раз при старте приложения. Для браузеров это не играет роли, так как загрузка и отрисовка страницы обычно происходит дольше, чем создание контекста для JS и его выполнение. А вот для конкретного случая, когда контекст нужно бы было создавать при каждом поступающем в Nginx запросе — да, это не эффективно. Но это совершенно не перечёркивает использование V8 в других типах приложений.
В Node.js вроде есть какие-то пулы потоков, так что оно что-то все-таки умеет сейчас делать параллельно и сумеет наверное больше чем одно ядро загрузить.
Вообще несколько node.js может оказаться удобнее чем одна node.js с несколькими инстансами v8 внутри. Процессы ведь полностью изолированы друг от друга. Один может упасть, а остальные продолжат работу.
Вообще несколько node.js может оказаться удобнее чем одна node.js с несколькими инстансами v8 внутри. Процессы ведь полностью изолированы друг от друга. Один может упасть, а остальные продолжат работу.
несколько инстансов на один процесс — пожалуйста, с изолятами (отдельная экспериментальная ветка v8 в официальном репозитории).
не крашится по OOM? это в некотором роде философия обработки ошибок… ООМ это критическая ситуация, которая не должна случаться во время работы приложения. Много ли их способно грамотно продолжить работу, если где-то глубоко по стэку отказали в выделении памяти? сомневаюсь.
не крашится по OOM? это в некотором роде философия обработки ошибок… ООМ это критическая ситуация, которая не должна случаться во время работы приложения. Много ли их способно грамотно продолжить работу, если где-то глубоко по стэку отказали в выделении памяти? сомневаюсь.
>отдельная экспериментальная ветка v8 в официальном репозитории
Не знал, спасибо за наводку.
>не крашится по OOM?
Ну да, спорно. Но все-таки какую-то гибкость в этом хочется иметь, если уж встраивать V8 в серверный код.
Не знал, спасибо за наводку.
>не крашится по OOM?
Ну да, спорно. Но все-таки какую-то гибкость в этом хочется иметь, если уж встраивать V8 в серверный код.
несколько инстансов на один процесс — пожалуйста, с изолятамиА они умеют между ядрами процессора расползаться? В смысле, если я запущу несколько инстансов Node или еще чего то в этих изолятах на многопроцессорной машине, то у меня все ядра загрузятся или только одно?
изоляты это никак не регламентируют. они просто предоставляют возможность нескольким потокам иметь по отдельному независимому инстансу V8.
соответственно как напишите их использование, так все и загрузится.
соответственно как напишите их использование, так все и загрузится.
Да не волнуйтесь так! Скоро v8 так разгонят, что можно будет интерпретатор любого языка прям на JS писать и безболезненно встраивать в веб-страничку!!! xD
Sign up to leave a comment.
Новая версия V8 будет на 50% быстрее