Разработчики Mozilla сообщили (https://blog.mozilla.org/javascript/2012/09/12/ionmonkey-in-.../) о миграции JavaScript-движка экспериментальной ветки Firefox на IonMonkey (https://wiki.mozilla.org/Platform/Features/IonMonkey), JIT-компилятор следующего поколения, который позволит значительно повысить производительность JavaScript приложений за счёт использования нового метода JIT-компиляции и передовых техник оптимизации. Первым релизом, перешедшим на IonMonkey, станет Firefox 18, выход которого запланирован на начало января.
Одним из ключевых новшеств IonMonkey является система вероятностной оценки типов, в рамках которой предложен гибридный метод статического и динамического анализа, позволяющий точно сопоставить типы для каждой переменной и каждого свойства JavaScript-программы. Напомним, что JavaScript является языком с динамической типизацией, с одной стороны это предоставляет большую гибкость для разработчиков, но с другой стороны создает трудности при создании JIT-компиляторов. Так как невозможно заранее определить какой тип данных будет содержаться в переменной, возникают трудности при сопоставлении переменной с определенными фиксированными инструкциями, рассматривающими эту переменную, например, как строку или число. IonMonkey сделал существенный шаг вперёд в плане решения данных проблем и позволил избавиться от выполнения большого числа дополнительных проверок в процессе работы JavaScript-программы.
Другим важным улучшением является использование адаптивных методов выбора той или иной техники оптимизации для выполняемого JavaSvript-кода. Если JIT-компиляторы первых двух поколений (TraceMonkey и JägerMonkey) поддерживали только прямую однонаправленную трансляцию JavaScript в машинные инструкции, то IonMonkey дополнительно снабжён средствами для обратной связи, позволяющими оценить эффективность результата выполнения сгенерированных инструкций и при необходимости внести корректировки и оптимизации, учитывающие особенности JavaScript-кода.
Архитектура IonMonkey разделена на три компонента: трансляция JavaScript в промежуточное представление (IR), применение различных алгоритмов к IR и трансляция финального IR в машинный код. Подобное разделение значительное увеличило гибкость работы JIT-компилятора и упростила сопровождение кода и его доработку. Например, добавление новых алгоритмов оптимизации теперь напоминает написание плагинов.
Среди других улучшений можно отметить: задействование техники LICM (Loop-Invariant Code Motion) для выноса инструкций за пределы циклов; поддержка метода GVN (Global Value Numbering) для ликвидации избыточного кода; реализация линейной схемы распределения регистров LSRA (Linear Scan Register Allocation), применяемой также в таких проектах, как HotSpot JVM и LLVM; поддержка DCE (Dead Code Elimination) для удаления неиспользуемого кода; новый анализатор границ, позволяющий обойтись без лишних проверок выхода за границы буфера. В настоящее время IonMonkey поддерживает генерацию кода для архитектур i386, x86_64, и ARM.Итогом проделанной работы стало значительное повышение производительности выполнения кода JavaScript. При выполнении тестового комплекта Kraken (http://krakenbenchmark.mozilla.org/) Firefox 18 с IonMonkey показал прирост производительности на 26%, по сравнению с Firefox 15 и тестовой версией Firefox 17.
<center><a href="https://blog.mozilla.org/javascript/files/2012/09/chart_2.pn... src="https://www.opennet.ru/opennews/pics_base/0_1347445330.png" style="border-style: solid; border-color: #606060; border-width: 15x;" title="" border=0></a></center>В тесте V8 benchmark Firefox 18 опередил Firefox 17 на 7%, а текущий релиз Firefox 15 на 20%.
<center><a href="https://blog.mozilla.org/javascript/files/2012/09/chart_1.pn... src="https://www.opennet.ru/opennews/pics_base/0_1347445365.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
URL: https://blog.mozilla.org/javascript/2012/09/12/ionmonkey-in-.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=34814
Имея старый, просто таки древний комп (на работе) я таки вижу только увеличение тормозов, поюзал плюнул вернулся на 3.6 те сайты что мне нужны работают как часики!
А ФФ 2 работает ещё лучше!
Ну тогда лучше вспомнить про FF1. Хотя лучше тогда нарыть самый ранний mozilla suite.
исправления ошибок безопасности удалось бэкпортировать?
Я вот всё жду когда же они начнут собирать с SSE2, чтоб желающие запускать свежий фокс на древней рухляди наконец свалили куда-нибудь подальше. И да, я «увеличения тормозов» на своей двухядерной рухляди пятилетней давности не вижу. По сравнению с 3.6 отзывчивость просто прекрасная. 3.6 же у меня еле ворочался с моей историей, закладками и всем прочим. Голый-то он летал.
Двухядерная рухлядь? Да ты зажрался.
поработай месяц
> Двухядерная рухлядь? Да ты зажрался.Дешёвый двухядерный процессор + материнка + память стоят копейки сейчас. Особенно б/у. Посмотри на форуме своего города — наверняка кто-то продаёт.
Дорого однако. У меня ноут с 4 пнем и как бы проблем не испытываю. Потому как виртуальные машины на серваке никто не отменял, а Х-ы в себе содержат сетевой протокол.
> Двухядерная рухлядь? Да ты зажрался.Нынче 2 и даже 4 ядра бывает даже в телефонах. Все-таки 2012 год а не 2002 нынче. Впрочем, как правило 2-ядерные системы рухлядью не являются.
> Я вот всё жду когда же они начнут собирать с SSE2Use AMD64, Luke! Там SSE2 - гарантирован. Процов с AMD64 без SSE2 просто не было, поэтому компиляция под AMD64 означает и юзеж SSE2 заодно.
У меня убунтовская 64-битная версия. ХЗ как она собрана.
Но я не затем жду, чтоб скорости получить, скорость меня устраивает. :)
> У меня убунтовская 64-битная версия. ХЗ как она собрана.Так же как и все остальное, скорее всего. Ну разве что убунтуи любят таким вещам подтягивать секурити еще. Подробнее тут: about:buildconfig
> Но я не затем жду, чтоб скорости получить, скорость меня устраивает. :)
Ах, вы не любите некроманов? Используйте осиновые колья и серебряные пули, говорят помогает :)
gentoo ждет тебя
> gentoo ждет тебяЯ уже говорил тут, что скорость меня не волнует. Вон там выше. ↑
В крайнем случае я фокс пересоберу если они и к 18й версии GStreamer не включат по-умолчанию.
> только увеличение тормозов, поюзал плюнул вернулся на 3.6... плюнул и поставил SeaMonkey, работает как часики! =)
Вернулся на Оперу. За те полтора года что я пользовался FF они наконец-то починили ее крахи под Линуксом (из-за них и ушел). Вот где скорость отзывчивости! Доволен как слон.
полтора года чинить крахи - это да, скорость отзывчивости девелоперов во всей красе
> полтора года чинить крахи - это да, скорость отзывчивости девелоперов во всей красеА еще опера нынче тормознее лиса и хрома в плане работы с KS и отстает в реализации новых фич :D.
Если не гонять какие-нибудь браузерные игры - незаметно совершенно. Зато памяти жрёт меньше и по отзывчивости она существенно лучше файрфокса и тем более хрома начиная вкладок с 50. А без модных анимашек я уж как-нибудь проживу.
еще скажите, что и все сайты (а не только Яндекс) корректно открывает и не крэшится
> еще скажите, что и все сайты (а не только Яндекс) корректно открывает
> и не крэшитсяты просто не поверишь…
> ты просто не поверишь…Тебе - не поверю. Ты наверное за пределы пары сайтов вообще не высовываешься. Гики они такие, да :)
> Ты наверное за пределы пары сайтов вообще не высовываешься.да ну, прон есть на гораздо большем количестве сайтов, чем два.
> да ну, прон есть на гораздо большем количестве сайтов, чем два.Ну да, там опера если и упадет - то только потому что сплойт не осилил экзотичную гиковскую конфигурацию прошибить, будучи ориентирован на хомячков :)
Я по "модным" сайтам не особо брожу, но то, где бываю - вроде бы всё работает.
Крахи то как раз и не починили. А памяти стало жрать нереально много, даже если ограничивать memory cache. Например установил значение кеша в 140 МБ , при этом памяти отжирало 500 МБ , и загрузка процессора 28%. И это при 10 вкладках. Крешится Опера стабильно . За часа 2 работы как минимум раз упадёт. Это на линуксе.
Сижу на ней только из-за удобного сервиса синхронизации
УМВР, у меня Опера не падает. Жрет памяти прилично, это да, но память для того и покупается, чтобы ее использовать на кэши и прочие вещи, ускоряющие работу. Толку-то от "экономной" лисы, если с большим количеством вкладок она начинает просто тормозить.
> прочие вещи, ускоряющие работу. Толку-то от "экономной" лисы, если с большим
> количеством вкладок она начинает просто тормозить.В лисе есть удобнй аддон NoScript, чтобы вырубить фоновые JS, после чего при куче вкладок все работает как часики. А в опере ничего сравнимого по удобству вообще нет. А в паре с адблокплюсом - еще и рекламе хана. У оперы опять же нет ничего сравнимого по функционалу.
> А в опере ничего сравнимого по удобству вообще нет.есть. открываем настройки, отрываем все «плугины» и весь «js». всё, ура, ничего не тормозит.
ах, да: если сайт не работает без js — тем хуже для сайта. в блокер его, чтобы больше время не тратить на этот хлам.
Там вроде в персональных настройках для сайта можно включить было
> Там вроде в персональных настройках для сайта можно включить быломожно. но зачем?
правда, при отключеном js умирают и юзерскрипты и расширения, поэтому пришлось запилить себе простенький аналог noscript. в общем-то оно несложно, средства есть. а вот зачем нужны «плугины» — я не знаю. равно как и «онлайн-видео».
эм... ну вот чтобы на опеннете комментарии раскрывались аяксом и в форуме ответ с цитированием работал. В общем, если без js работает - это ж не значит что всегда надо обходиться, главное чтобы оно было в разумных пределах.
> эм… ну вот чтобы на опеннете комментарии раскрывались аяксом и в форуме
> ответ с цитированием работал.первое нафиг не надо. а второе если без js не работает — то это @#$@%%!ц.
сначала за себя ответь а потом говори нужно оно или нет
> есть. открываем настройки, отрываем все «плугины» и весь «js». всё,
> ура, ничего не тормозит.Угу, и половина сайтов не работает.
> ах, да: если сайт не работает без js — тем хуже для
> сайта. в блокер его, чтобы больше время не тратить на этот хлам.Да ну нафиг, недостаточно радикально. Лучше со Столлмана пример брать: если сайт не открывается телнетом - забываем о нем. Юзать проприетарную затычку для того чтобы в ней гшольный хтмл смотреть - маразм вообще. Особенно при 2 живых открытых браузерных движках.
>> есть. открываем настройки, отрываем все «плугины» и весь «js». всё,
>> ура, ничего не тормозит.
> Угу, и половина сайтов не работает.каких? а, понял: фкантагтег, аднаклассники, мордокнига. не нужны.
> Да ну нафиг, недостаточно радикально.
ты можешь поступать радикальней — разве я запрещаю?
> . За часа 2 работы как минимум раз упадёт.интересно, как этого можно добиться. работает неделями, не падает. о! видимо, у тебя всякие ненужные флэши включены? выключи.
p.s. полнотекстовый поиск по истории тоже не нужен, полезно вырубать.
> тебя всякие ненужные флэши включены? выключи.
> p.s. полнотекстовый поиск по истории тоже не нужен, полезно вырубать.А если браузер не запускать - станет вообще хорошо. Хотя лучше совсем не включать компьютер. На всякий случай. Для надежности надо отключить питание: без питания выжрать оперативку - задача вообще нетривиальная :)
а, любитель смотреть флешерекламу. тогда не жалуйся.p.s. да, ты не поверишь: фичи жрут память. правда, удивительно? и почему они не могут «как-нибудь так»?
Так в фоксе тоже есть сервис синхронизации. Или он неудобный?
Хорошо, скорость - это то, что сейчас больше всего нужно для ФФ.
> Ага. Как всегда скорость повышается за "счет использования возможностей процессоров последнего поколения"...и где здесь проблема?
что ты имеешь против возможностей процессоров последнего поколения?
В деньгах всё дела, типа я такой со старым компом и вы все должны быть на моём уровне и под меня всё делать. С другой стороны сейчас многие программные продукты действительно клали на оптимизацию в чём-либо.
Дело то не в том, что делать под кого-то со старым компом - дело в том, что современные приложения требуют при равных условиях больше ресурсов для выполнения задач на одних и тех же входных данных нежели их предыдущие версии
> дело в том, что современные приложения требуют при равных условиях больше ресурсов для выполнения задач на одних и тех же входных данных нежели их предыдущие версииэт что ещё за те же входные данные? 6 лет назад Javascript вообще использовалься для целей типа бегущая строка в title-сайта :-D . и прочие сугубо УКРОШАТЕЛЬСТВА (а не для целей прикладных полезных функций).
а о том что будут хоть-сколько-комфортные web-приложения -- в 2006 году можно было только мечтать [каждое web-приложение 2006-года постоянно обновляло свою страничку при любом говнодействии пользователя]
>эт что ещё за те же входные данные?
>6 лет назад Javascript вообще использовалься для целей типа
>бегущая строка в title-сайта :-D . и прочие сугубо УКРОШАТЕЛЬСТВА (а не для целей >прикладных полезных функций).Там ему и место
> Там ему и местоВот как-раз там ему вообще не место.
>Вот как-раз там ему вообще не место.Ну тогда для ботнетов там всяких лучше не придумаеш
> Ну тогда для ботнетов там всяких лучше не придумаешНи разу ботнетов на JS не видел, да и для установки идиоту этой дряни JS не нужен. Достаточно фэйкового порно-торрент-трекера… который отдаёт exe-файлы вместо torrent-ов. И ботнет тебе обеспечен.
лучше бы на этом и остановились
Зато теперь в браузере запускают Linux.
Вы несёте чушь, с учетом того что я в Google Mail зарегистрирован с начала 2006 года. А он изначально был на AJAX-е.
> УКРОШАТЕЛЬСТВАУкрощательства :)
>> УКРОШАТЕЛЬСТВА
> Укрощательства :)Укрэшательства :))
> Укрэшательства :))Укрощательства укрэшательств :P
> а о том что будут хоть-сколько-комфортные web-приложения — в 2006 году можно
> было только мечтатьда и сейчас то же самое. ну неудобен этот ваш браузер в качестве замены «обычного десктопного» софта, неудобен.
чем же?
> чем же?всем.
> да и сейчас то же самое. ну неудобен этот ваш браузер в
> качестве замены «обычного десктопного» софта, неудобен.Обалденная аргументация. Хотя если ты о потугах заменить вебапликухами обычные - да, это криво. Но перенять некоторые их фичи вебу не помешало бы.
> Обалденная аргументация.разговор об этом даже на опеннете уже был неоднократно. в очередной раз доказывать, что кубические колёса плохо подходят для массового автомобиля — мне лень.
Не лень тебе а не можешь, но вякаешь)
ну ок, не могу. теперь тебе стало лучше и ты будешь крепче спать? на здоровье.
> разговор об этом даже на опеннете уже был неоднократно. в очередной раз
> доказывать, что кубические колёса плохо подходят для массового автомобиля — мне лень.Как бы что хорошо подходит для массового автомобиля в основном определяет рынок. Рынок достаточно благосклонен к HTML5 и его возможностям. По факту довески типа сильверлайта и флеша просто издохли на фоне данной перспективы. Куда и дорога.
Тебе могут до упора нравиться паровые машины, но в роли автомобиля у них фатальный недостаток: долго ждать растопки котла. За это их и заменили бензиновые. Хоть дрова и были дешевле и не требовали никакой промышленной базы. По той же самой причине AJAX, вебсокеты и прочие SPDY постепенно выпнут классическую модель с запрос - ждем полчаса - грузим еще полчаса огромную простыню. Долго и неудобно.
ты Одепт Невидимой Руки Рынка или просто глупый со своим «определяет рынок»?
Многопоточность там нужна нормальная. Тормозов при браузинге и так не наблюдается уж давно.
> Многопоточность там нужна нормальная. Тормозов при браузинге и так не наблюдается уж
> давно.Многопоточность там давно уже есть и весьма хорошая, в htop посмотри, например, нажав там F5. Вот многопрцессности, как в Хроме, нет… и не надо.
Конечно, не надо. Ведь тогда не получится в каждом релизе рапортовать, что устранены утечки памяти. Зачем прерывать многолетнюю традицию?
А если серьезно, системный менеджер памяти лучше справляется с освобождением памяти нежели тот "велосипед", что изобретают мозиловцы.
> А если серьезно, системный менеджер памяти лучше справляется с освобождением памяти нежели
> тот "велосипед", что изобретают мозиловцы.Вот только есть одна проблема — вы же первый взвоете почему фокс на 10 вкладках начал жрать в несколько раз больше памяти, чем раньше. Большие расходы памяти это как-раз проблема многопроцессной модели. Разве что отдают всю сразу, а не передают эту задачу сборщику мусора. А ещё дополнительная нагрузка на процессор для организации общения процессов между собой. Лучше пусть утечки лечат.
Ну-ну. Только хром при этом жрёт памяти больше файрфокса в разы. Интересно, с чего бы это...
Надо же где-то в ОЗУ хранить собранную о пользователе информацию перед отправкой на сервер. По крайней мере, это единственное объяснение существования "Процесса GPU", потребляющего 56 Мбайт в простое на системе без поддержки аппаратного ускорения видео.
И вовсе не грандиозное увеличение производительности.
Наверняка это нарушит кучу тупых америкосовских софтовых патентов.
Да сколько ж можно-то?! Intel с их EXA, UXA, SNA и GLAMOR - ничто по сравнению с тем как Mozilla меняет движок JavaScript.
Intel делает это довольно быстро и никто не страдает, хотя и бывают регрессии в отношении производительности на некотором их видео, но они не заставят никого переписывать софт. А тут таки проблема может возникнуть, и даже пнуть потом некого, кроме Лисы.
Я страдаю. Это д*мо трапается. То на GE то на Marble, теперь стало даже на xrestop.
> Я страдаю. Это д*мо трапается. То на GE то на Marble, теперь
> стало даже на xrestop.Может, вы что-то делаете не так? Почему у меня ничего не трапается? Вы случайно не гентушник, собирающий весь софт с -O9?
> с -O9?выше O3 продлолжается O3.
>> с -O9?
> выше O3 продлолжается O3.Наверное вы имели в виду ПродЛажается ;). Есть класс граждан упоротых на коНпелировании. Они не особо понимают что делают ключи компилера но втыкают в параметры компиляции все что по их мнению относится к оптимизации. А потом идут в багтрекер и слезно вещают что вот, нас тут укусил жуткий баг вашей программы. На поверку оказывается что баг - у одного дурика на всю планету, в силу общей ж@порукости. Вот я и пытаюсь выяснить - не такой ли это случай. Просто странно если у всех работает а у кого-то бац и наворачивается на ровном месте. Такое конечно иногда бывает, но если бы это было фундаментальным свойством браузера - программерский мозг давно бы уже скушали хомячки.
>> выше O3 продлолжается O3.
> Наверное вы имели в виду ПродЛажается ;).опечатка, конечно, но разве плохое слово вышло? «продЛОЛжается». мне даже понравилось.
> Да сколько ж можно-то?!Нет предела совершенству. Поэтому да, столько сколько получится и столько сколько будет нужно.
всеравно медленее v8, чтоб с ним тягаться надо раза в 2-2.5 поднимать
> всеравно медленее v8, чтоб с ним тягаться надо раза в 2-2.5 подниматьНеправда, см. http://arewefastyet.com/ В кракене новый движок уже обогнал V8.
Ну не знаю как они там тестят, а я сам проверяю, на элементарных циклах, ветвлениях, выражениях, фокс заметно отстает, причем чем больше время теста тем это заметно сильнее.
Впрочем извиняюсь, ситуация быстро меняется) пару недель назад сравнивал 14 фокс с нодой, было как сказал, сейчас прогнал пару тестов на 15 фоксе и 0.8.9 ноде - равны, а 21 хром вообще слил в полтора раза) Война однако, не уследишь) По большому счету наверное все это фигня когда в условиях постоянной гонки ктото немного отрывается, завтра глядишь его настигли, а послезавтра и черт не знает что будет)
синтетические тесты — говно.
> синтетические тесты — гoвно...и только Кэп с отключенным JS весь в белом :)
Не забывай дописывать сам, какого черта я должен твои фразы за тебя дописывать?!
> Не забывай дописывать сам, какого черта я должен твои фразы за тебя
> дописывать?!а почему я один должен трудиться? и ты поработай.
> Неправда, см. http://arewefastyet.com/ В кракене новый движок уже обогнал V8....но не в V8bench...
Во-первых там всё равно не вдвое, а во-вторых - этот тест, судя по всему, с самого начала разрабатывался так, чтобы показать ерутость v8, и объективность его несколько под сомнением. Это не знасит, что стремиться не надо - но и париться на этот счёт я бы тоже не стал.
> Во-первых там всё равно не вдвое, а во-вторых - этот тест, судя
> по всему, с самого начала разрабатывался так, чтобы показать ерутость v8,
> и объективность его несколько под сомнением. Это не знасит, что стремиться
> не надо - но и париться на этот счёт я бы тоже не стал.Так поэтому и надо смотреть на различных тестах. Но в целом JS в хроме порезвее. Что не мешает лисе его местами натягивать. У любого двигуна есть сильные и слабые стороны. Вон doom на JS на хроме вообще тупил дико из-за бага в хроме. А в лисе вполне себе работал...
> передовых техник оптимизацииЭто они про кеширование всего подряд в оперативе что ли?
По копейкам оптимизируют раход памяти в течение релизов, уменьшают оное процентов на 15, а потом БАЦ, новая "оптимизация", и памяти уже требуется в несколько раз больше, чем раньше.
>> передовых техник оптимизации
> Это они про кеширование всего подряд в оперативе что ли?
> По копейкам оптимизируют раход памяти в течение релизов, уменьшают оное процентов на
> 15, а потом БАЦ, новая "оптимизация", и памяти уже требуется в
> несколько раз больше, чем раньше.Грабь, убивай, комментируй не читая!
Браузер в дерьмо превращается. Имею на ноуте 8гб оперативы, оставил на ночь почтовый клиент, скайп и фаирфокс, утром получил сообщение что свободной оперативы не осталось, все выжрал фаирфокс. Повторил процедуру на следующий день, сообщений не появилось, зато перезапустить фаирфокс не получилось без киляния процесса вручную. Каждый день гамнище какое-то.
> оставил на ночь почтовый клиент, скайп и фаирфоксчтобы дрова рубили, пока админ спит?
>> оставил на ночь почтовый клиент, скайп и фаирфокс
> чтобы дрова рубили, пока админ спит?Биткоины считали :)
Бред полный. Тут явно проблема не в файрфоксе, а в каком-то из установленных плагинов.
2 чашки чая этому господину.
> Бред полный. Тут явно проблема не в файрфоксе, а в каком-то из
> установленных плагинов.Или расширений. Из плагинов так шутит обычно только флэш и только потому, что забывает выгружать видео из памяти, идиот он такой.
> оставил на ночь почтовый клиент, скайп и фаирфокс, утром получил сообщение что свободной оперативы не осталось, все выжрал фаирфоксчто за такое сообщение? как мне его полчить? откуда оно вообще появляется?
часто оставляю на ночь комп (да и вообще не выключаю полностью никогда.. максимум в sleep перевожу) но такой вот фигни не наблюдал.
Поддерживаю. Зимой создавал тему об этом: http://www.linux.org.ru/forum/talks/7273029
> Поддерживаю. Зимой создавал тему об этом: http://www.linux.org.ru/forum/talks/7273029Файрфоксу приписано только 400 метров RSS. Куда остальное жрется - хороший вопрос. И какую именно свободную память показывает этот манагер процессов? Он буфера считает за таковую или нет?
> Каждый день гамнище какое-то.У вас или засраный профайл, или кривые аддоны. Или просто какая-то веб-страница дико борзеет. Сам по себе лис подобными проблемами не страдает. Ну вот например 15-я лиса, пущена неделю назад. Жрет какие-то 800Mb RSS на 100500 вкладок. Не вижу криминала.
На какие только извращения не пойдёшь, чтобы ускорить нечто тормозное by design
> На какие только извращения не пойдёшь, чтобы ускорить нечто тормозное by designУ Хрома тоже шустрый JS движок. Даже шустрее фокса. Хром тоже тормозной по-дизайну, раз ему такой движок сделали?
> Хром тоже тормозной по-дизайну, раз ему такой движок сделали?Не Хром, а парадигма создания тяжёлых программных интерфейсов на связке HTML+JavaScript. HTML предназначен для вёрстки текста, а JavaScript - для маленьких и лёгких программ. Он же не типизированный и не компилируется (значит, не проверяется статически).
> не компилируется (значит, не проверяется статически).Давно уже динамически компилируется, а теперь ещё и динамически типизируется. Хром, кстати, типизацию уже давно умеет.
Интересно, а есть ли смысл мутить какой-нить режим, который нужно будет самому руками активировать и в котором нужно будет самому руками всё типизировать?
> Интересно, а есть ли смысл мутить какой-нить режим, который нужно будет самому
> руками активировать и в котором нужно будет самому руками всё типизировать?Так уже замутили — opalang.org
И от этих костылей на самом же жабаскрипте растёт производительность? Я имел ввиду на уровне движка. Вон у в ECMAScript 5 есть режим "use strict".
Это кто-то Perl переименовал что-ли?
Не надо ничего активировать и все типизировать, просто в тех местах где надо/критично пользуйтесь типизированными контейнерами, где не надо - можете не пользоваться, при этом нетипизированные места движок постарается за вас оттипизировать автоматически.
У типизациии есть плюсы и кроме скорости. Самый жирный - это лишний уровень документации. Вот здесь арбузы храним а здесь - попугаев. По типам это сразу видно. Ну и что не сложишь арбузы с попугаями - тоже хорошо.
> У типизациии есть плюсы и кроме скорости. Самый жирный - это лишний
> уровень документации. Вот здесь арбузы храним а здесь - попугаев. По
> типам это сразу видно. Ну и что не сложишь арбузы с
> попугаями - тоже хорошо.Ещё проверка. В общем, в любом случае, в JS, как правило, не используется статическая компиляция. А это значит, что не производится даже убогий компиляционный статический анализ.
Это совершенно необязательная вещь, когда программы маленькие, когда всё умещается на страничку. Но если программы диких размеров, то тут стат. анализ крайне желателен.
Если программы диких размеров то тут не статанализ желателен а биореактор
> Если программы диких размеров то тут не статанализ желателен а биореакторВы вообще смотрели размер исходников хоть одной программы, на которой работаете?
И, кстати, знаете ли вы какой объём JS кода качается туда-сюда при загрузке GMail?
Не путайте общий объем и размер модуля
Только без типов модуль не имеет внятного интерфейса, ему запросто можно скормить любую чушь и не заметить.
Нельзя, ибо он это проверяет динамически.
> Нельзя, ибо он это проверяет динамически.Если при тестировании какая-то ветвь не сработала (скажем очень редка), проверит он это только в работе. И долбанётся у пользователя.
Статические проверки хороши тем, что они проверяют всё, все ветви программы. Даже те, что выполняются раз в 2 года. А с помощью одних динамических проверок вы за два дня тестирования не пройдёте по таким веткам. В результате, они долбанутся у клиента.
Формальный синтаксис проверяется полностью и в динамических языках, а вот что касается логических ошибок в ходе исполнения, то ситуация в статике не лучше - точно также может быть неверный код вызывающий ошибку не проявляющийся при первом тестировании.
> Формальный синтаксис проверяется полностью и в динамических языках,Мы с вами немножечко смешали две "фичи" JS, неприятные на больших проектах - динамическую систему типов и интерпретацию.
Из-за интерпретации формальный синтаксис у JS проверяется только там, где происходит выполнение. У статически компилируемых языков все ветви проверяются на стадии компиляции. Уж хотя бы по синтаксису, а чаще и ещё глубже.
> а вот что касается логических ошибок в ходе исполнения, то ситуация в статике не лучше
Почему же? Если не использовать массивы и другие хаки, то можно быть уверенным в том, что левый тип передан не будет. То есть, то, что вы получите структуру ровно такого размера/объёма, какую заказывали.
В большинстве мест в программе массивы не передаются => вы уже от серьёзной части ошибок избавились.
> Из-за интерпретации формальный синтаксис у JS проверяется только там, где происходит выполнение.Ну здаровьте живете, если на JS не пишите то чего говорите то? Во первых он не интерпретируется а компилируется, во вторых синтаксис таки проверяется везде:
if (true) {
alert(1);
}
else {
alert(2;
}Ошибка: SyntaxError: missing ) after argument list - alert(2;
Почему же? Если не использовать массивы и другие хаки, то можно быть уверенным в том...
Массивы это хаки? Выдыхай бобер) Это очень часто используемая конструкция, дело даже не в их передаче а в работе с ними, например очень часто приходится работать с кусками памяти, выделять из нее значения накладывая структуры и приводя типы, так вот если вы гденить размер какогонить поля в структуре измените без соответствующего рефакторинга остальных кусков, то нифига компилятор ваш этого не просечет и вывалит ошибку времени исполнения, хотя формально по типам все верно) и таких мест хренова куча.
Это суровая системщина какая-то у вас, если приводить типы постоянно надо. Впрочем в JS массивы (а особенно объекты) действительно часто применяются там, где нужна была бы структура ( в сиысле сишного struct, возможно - расширенного необязательными полями, как в protobufs) - что очень даже способствует багам.
Конечно системщина, единственная нормальная ниша для сей. Да, у JS полно своих косяков, просто не надо заявлять что при жестком типизировании компилятор все проверит и укажет на ошибки, точно так же многое не проверит. Реально, на практике, работаю как с сями так и с JS кодом, и косяков при поддержке одинаково, потому что подавляющая их масса связана не с типизированием.
1) си строгостью типизации ну никк не отличаются2) кроме системщины есть куча областей, где строгая типизация даёт выигрыш по надежности софта, и воевать с ней не нужно - это, в общем-то, любая более-менее крупная приклажная софтина. А уж если разрабатывается парой десятков человек - тем более.
Да не воюю я с типизацией) вещь хорошая, просто когда некоторые совершенно не знающие js начинают пороть чушь то их надо ставить на место, в том числе и когда они начинают абсолютизировать типизацию вроде "можно быть уверенным в том, что левый тип передан не будет".Конечно типизация это благо, но не всегда, и не всегда необходимое, если ктото не видит этих мест и не способен на этом выиграть, не теряя в остальном, то это его проблемы.
Ну здесь да, спорить не о чем.
> Из-за интерпретации формальный синтаксис у JS проверяется только там, где происходит выполнение.FYI: даже самая первая версия Брэндана использовала компиляцию в байт-код. откуда у JS растут некоторые забавные фичи: например, непривычное действие var.
Именно. Вообще за большие программы в браузере надо отгрызать голову, но раз уж оно приползло - неплохо бы хоть поддержку приличную...Впрочем, документация, которую дают типы, набольших проектах ещё важнее, как по мне.
> Интересно, а есть ли смысл мутить какой-нить режим, который нужно будет самому
> руками активировать и в котором нужно будет самому руками всё типизировать?Dart, Python, как замена js
Питон в браузере? Это где ж такое? А Dart - ну да, ждём, если выстрелит
> Интересно, а есть ли смысл мутить какой-нить режим, который нужно будет самому
> руками активировать и в котором нужно будет самому руками всё типизировать?Зачем? Давным давно (с 78-го года) есть метод выведения типов в выражении. То есть, в строго-типизированном языке с выводом типов вы указываете тип только в одном месте, а всё остальное выводится компилятором. Вот, например, код на OCaml:
let sqr x = x *. x;;
Printf.printf "%f\n" (sqr 2.0);;
Компилятор уже в функции sqr понимает, что x - вещественное число, т.к. используется вещественный оператор. То есть, если за определением написать
let z = sqr "Привет";;
то на стадии компиляции произойдёт ошибка. При этом, заметьте, нигде названия типа float не упомянуто. Достаточно уже того, что *. умножает float'ы и 2.0 - это float.
Угу. Только явноеfloat x;
куда яснее выражает намерения разработчика. Даже если компилятору всё равно - человеку, читающему код, много понятнее. Особенно если там не float а какой-то свой сложный тип - можно сразу ткнуться в его документацию, например.
> Угу. Только явное
> float x;
> куда яснее выражает намерения разработчика. Даже если компилятору всё равно - человеку,
> читающему код, много понятнее.Если этих флоатов много, они уменьшают читаемость.
> Интересно, а есть ли смысл мутить какой-нить режим, который нужно будет самому
> руками активировать и в котором нужно будет самому руками всё типизировать?Типизированные массивы сделали, например, на радость игроделам и подобным. Лиса и хром вроде как умеют, остальные - без понятия.
> Давно уже динамически компилируется, а теперь ещё и динамически типизируется. Хром, кстати, типизацию уже давно умеет.Речь идёт не о динамической компиляции, а о статической. То есть, обычной. При статической компиляции происходит проверка синтаксиса, небольшая проверка логики.
Собственно, я бы ничего не имел против встраивания в браузер LLVM машины и передачи скриптов страницы, если они такие тяжёлые, в виде LLVM кода. Если лёгкие, то и JS движок можно не оптимизировать столь тщательно.
> HTML предназначен для вёрстки текста...Вылезайте из 90х, и у HTML уже давно другая роль, и JS типизируют и компилят.
> Вылезайте из 90х, и у HTML уже давно другая роль, и JS
> типизируют и компилят.Ну как-раз HTML своей роли не менял. Разве что помимо картинок теперь можно к тексту приложить звук и видео. Но он как был языком разметки текста, так и остался.
> как был языком разметки текста, так и остался.Не вебдев вы, сразу видно, иначе объясните зачем из по вашему мнению "языка разметки текста" убрали управление шрифтами? или например почему все нововведения текста никак не касаются?
Потому что для этого CSS есть, который как раз именно для управления шрифтами подходит в 100500 раз лучше?
Потому что разметка текста в HTML уже давно не основное.
> Потому что разметка текста в HTML уже давно не основное.А какое? Что теперь стало основным?
разметка вообще, а не текста, и выполнение роли контейнера, т.е. объединение сопутствующих технологий в единое целое
> разметка вообще, а не текста,Тогда выучи наконец значение буквы H в HTML: http://en.wikipedia.org/wiki/Hypertext
Он никогда и не был языком разметки только текста. Иначе он бы назывался TML.
Ну и о чем тогда спорим? Я отвечал челу который по сути выразился вроде "html это всего лишь язык разметки текста а на нем пытаются создавать тяжелые интерфейсы" см. выше. И про изменение роли я отвечал ему же, тому кто считает что разметка текста это до сих пор, как на заре, основная функция, а не тем людям которые понимают что кроме разметки текста у современного html куда бОльшая куча др. функций)
Я и не веб-дев, но чья бы корова мычала. Какое отношение управление шрифтами имеет к разметке гипертекста на логические блоки?
И какие такие «все нововведения»? Звук и видео? А возможность вставлять картинки в нём тебя всё это время не смущала? Что это меняет, помимо того, что теперь рядом с блоком текста можно поместить блок с видео, а не только с картинкой?
> Я и не веб-дев, но чья бы корова мычала. Какое отношение управление
> шрифтами имеет к разметке гипертекста на логические блоки?
> И какие такие «все нововведения»? Звук и видео? А возможность вставлять картинки
> в нём тебя всё это время не смущала? Что это меняет,
> помимо того, что теперь рядом с блоком текста можно поместить блок
> с видео, а не только с картинкой?
> он как был языком разметки текста, так и осталсяОчевидно что начавший ветку говорил об основной функции языка, в начале по факту она такой и была, ибо странички были в основном текстовые, и даже шрифтами рулили из html, однако в настоящее время бОльшая часть html кода страницы к тексту отношения не имеет, это логические блоки, картинки, и куча др. контейнеров, понятно что html никогда не был исключительно разметкой текста, но в начале по факту это было основным, теперь же это и по факту не так, поэтому с точки зрения человека считающего что основная функция html это разметка текста, можно говорить о изменении роли.
> Очевидно что начавший ветку говорил об основной функции языка, в начале по
> факту она такой и была, ибо странички были в основном текстовые,
> и даже шрифтами рулили из html, однако в настоящее время бОльшая
> часть html кода страницы к тексту отношения не имеет, это логические
> блоки, картинки, и куча др. контейнеров, понятно что html никогда не
> был исключительно разметкой текста, но в начале по факту это было
> основным, теперь же это и по факту не так, поэтому с
> точки зрения человека считающего что основная функция html это разметка текста,
> можно говорить о изменении роли.Да, именно так.И я, в основном, о том, что это изменение роли произошло эволюционным путём. Со всеми присущими эволюционному подходу недостатками: необходимостью держать совместимость + костыли.
Ну, в сях/плюсах например костылей на порядок больше, впрочем они конечно и старше, куда ж мы все вообще без костылей то?)
> Ну, в сях/плюсах например костылей на порядок больше, впрочем они конечно и
> старше, куда ж мы все вообще без костылей то?)Вообще-то, сейчас С++, к счастью, уже уходит. Вот и HTML+JS туда же пора.
>> Ну, в сях/плюсах например костылей на порядок больше, впрочем они конечно и
>> старше, куда ж мы все вообще без костылей то?)
> Вообще-то, сейчас С++, к счастью, уже уходит. Вот и HTML+JS туда же
> пора.С++ еще и нас переживет
> Вообще-то, сейчас С++, к счастью, уже уходит. Вот и HTML+JS туда же пора.Куда? :) Все серьезные игроделы на нем пишут. Просто потому что альтернатив нет. А си вон вообще опять на 1-е место вырвался по популярности, обув жабу. Что и не удивительно. Вон например толпа ардуинщиков повылезла - си и си++. Опять.
> Просто потому что альтернатив нет.это заблуждение.
нет, мне лень аргументы писать, у меня ваще голова болит.
> с точки зрения человека считающего что основная функция html это разметка текста, можно говорить о изменении роли.С точки зрения фаллообразного пришельца с юпитера у человека самый мудрый орган находится промеж ног и у половину человечества разум вообще отсутствует. И он даже будет не очень далёк от истины, как ни странно.
А неправы будут оба.
> Вылезайте из 90х, и у HTML уже давно другая роль,Вот именно об этом и речь. Изначально HTML предназначался для вёрстки, его определённым кол-вом подпорок превратили в язык создания интерфейсов.
> и JS типизируют и компилят.
Его компилируют перед тем, как выкладывать на сервер?
Не, html это не язык создания интерфейсов, так что концептуальных потпорок нет, это язык верстки, объединения, компоновки элементов, его не во что не превращали, основная идея осталась прежней, его просто модифицировали, чтото выкинули, типа управления шрифтами, чтото добавили, типа разных блоков, чтото вынесли в др. языки типа CSS, т.е. в конечном счете как это не удивительно обобщили и сконцентрировали на верстке вообще, в т.ч. верстке программного кода, хотя конечно многое пока еще оставляет желать лучшего, ну так и процесс не окончен)Ктото наверное JS и предварительно компилит, перед выкладыванием на сервер, но в мэйнстриме (V8 и т.п.) он компилится движком перед выполнением а затем частично кешируется. Да, у статической компиляции есть свои плюсы, а у динамической свои) В идеале динамическая компиляция более эффективна статической с точки зрения производительности, что на некоторых примерах подтверждается уже сейчас, но в общем на текущий момент JS пока еще проигрывает плюсам порядка 30%. Типизация в JS постепенно внедряется, а значит плюсы статики рано или поздно будут сведены на нет, а вот плюсы динамики никуда не денутся, вот и думайте)
HTML 5, извините, потерял совместимость с HTML 1?> Да, у статической компиляции есть свои плюсы, а у
> динамической свои)На больших проектах статическая компиляция предпочтительнее тем, что она проверяет все ветви исполнения программы. То есть, если вы написали код
if( rand() == 1)
{
белиберда
} else
{
return 0;
}то несмотря на то, что шанс попадения в первую ветку очень мал, статический компилятор gcc обнаружит синтаксическую ошибку. И вы её исправите. А в динамическом языке эта конструкция будет чаще всего работать и изредка вылетать. :-) Причём вылетать так редко, что на тестировании вы это пропустите.
Скорость компиляции, если это не переусложнённый язык типа C++, весьма мала. Те же самые скрипты на OCaml можно компилировать каждый раз непосредственно перед выполнением.
Конечно потерял, я вам про <font> же говорил уже, и далеко не он один.Бросьте, в статике тоже может быть белиберда и компилятор ее не проверит, точно также выкинет ошибку времени исполнения, иначе акцесвиалейшены и "программа выполнила недопустимую операцию" в статике откуда? Может быть не синтаксическая а логическая ошибка, может быть неправильная постановка задачи, и т.п. По факту, из практики, не вижу разницы в сопровождении что статики что динамики, гораздо большее зависит от уровня программиста.
> Бросьте, в статике тоже может быть белиберда и компилятор ее не проверит,
> точно также выкинет ошибку времени исполнения, иначе акцесвиалейшены и "программа выполнила
> недопустимую операцию" в статике откуда?Может быть. Но дополнительная проверка сделает её менее вероятной.
Согласен, но отсутствие необходимости явной компиляции и приведения типов экономит время, т.е. как бы не то на то, также динамическая оптимизация дает плюсы в производительности, ну и в конце концов, никто не запрещает и в динамике использовать типизацию и соответствующий анализ, сейчас это пока еще очень слабо но дело к тому идет. Короче, предлагаю не скатываться в частности, и не спорить в ключе что статика всегда лучше а динамика это оно)
И вообще, почему мы статику противопоставляем динамике? она прекрасно включает в себя статику, некоторые элементы есть уже сейчас, процесс идет, JS типизируется, думаю вполне можно ожидать следующим шагом за JIT появление в мейнстриме статических анализаторов) ну впрочем коечто уже есть) Не плохой бы язык по моему был, если к JS добавить модули и типизацию по выбору разраба, да динамическую оптимизацию развить, тогда бы и по производительности всех сделали, и при необходимости по строгости, и по удобству)
Тогда си можно будет хоронить, а движок JS встраивать в процессор вместо текущего интерпретатора "нативного" кода :)
> И вообще, почему мы статику противопоставляем динамике? она прекрасно включает в себя
> статикуПотому, что решения задач построения десктопных приложений давным давно отработаны. Практика показала, что большие десктопные приложения удобно делать с компилируемыми статически типизированными языками.
А ведь именно в сторону больших десктопных программ и пришла связка HTML+JS. Посмотрите, сколько JS кода качает браузер, когда первый раз заходим на GMail или другой AJAX сайт.
> , некоторые элементы есть уже сейчас, процесс идет, JS типизируется, думаю
> вполне можно ожидать следующим шагом за JIT появление в мейнстриме статических
> анализаторов) ну впрочем коечто уже есть) Не плохой бы язык по
> моему был, если к JS добавить модули и типизацию по выбору
> разраба, да динамическую оптимизацию развить, тогда бы и по производительности всех
> сделали, и при необходимости по строгости, и по удобству)Ну это вы из JS хотите сделать очередной С++. Такая штука взлетает, но летит крайне хреново.
Ещё что плохо в HTML+JS по сравнению с компиляцией в промежуточное представление, которое бы выполнялось в браузере на llvm - это то, что разработчик ограничен именно этими 2-мя языками. Разработчик не может взять, скажем, F# или D или Ruby. Он должен ваять на JS.
Практика показала что на JS еще удобнее)
Нет. Он выиграл за счёт дешевизны деплоя и доставки приложений и контроля над ними вендора (что нам с вами ещё аукнется). Сама платформа неудобна до ужаса, просто деваться некуда.
> Согласен, но отсутствие необходимости явной компиляции и приведения типов экономит время,На современном лёгком языке компиляция мгновенна. Посмотрите на OCaml, к примеру. В современных языках со статической типизацией совершенно необязательно везде указывать тип переменных, как в С. Компилятор их выводит сам.
В общем, я про то, что задачи, которые возлагаются на JS уже переросли его. Эти задачи уже много лет прекрасно решают компилируемые языки (не важно, в промежуточное представление или прямо в маш. код).
Из-за этого несоответствия JS и возлагаемых на него задач мы и наблюдаем все эти мегаоптимизации, вкладывание диких средств в производительность JS движков. Тогда как обычные компиляторы обычных языков достигают такой же производительности без вложений таких диких средств.
Кроме производительности обычных компиляторов обычных языков есть еще их распространенность, удобство, сопутствующая инфраструктура, кадры и т.п, на дотяжку которых, потребуются все те же дикие средства, ну или расскажите это гуглу, они наверное глупенькие не знают.
ну да, цена эволюционного развития и несогласованности вендоров. Вот как вы себе предсавляете договор гугла, эппла и майкрософта о введении нового языка вместо JS? Хотя байткод прямо напрашивается...
> Хотя байткод прямо напрашивается...Я думаю, что если тот же Google возьмёт ?независимую? llvm и встроит в Chrome, дав возможность тому резко поднять производительность и удобство разработки, то остальным делать будет нечего.
Это, всё-таки, не жалкие 2 раза будут. А уж тем более, не 20%.
Во-первых, много разных языков => колоссально вырастет производительность программистов. Во-вторых, значительно выше скорость выполнения, значительно ниже требования мощности машины, в том числе, и памяти.
Говорю тебе бобер, выдыхай) то у тебя js не компилируется, то синтаксические ошибки не ловит, теперь вот еще одну басню про производительность завел. Не пишешь на современном JS, не сравниваешь, так помолчал бы.Откуда там резкий подъем производительности если v8 js вплотную стоит к C++, отставание в среднем 30%, и по памяти - используй типизированные массивы будет один в один столько же, что же касается десяти метров на движок то в тех областях где js применяется это просто ничто.
И от много разных языков производительность программистов не вырастет, доказано практикой, а вот геморой вырастет легко.
Производительность-то программистов как раз вырастет - в разных областях применения разные языки удобны. Где-то вообще функциональщина подойдёт больше, где-то контракты будут на пользу... Да много чего придумано.Но вот "байткод от гугла" уже есть - NaCl - но не взлетел особо.
Да, кстати - это, что ли, 30%? http://shootout.alioth.debian.org/u64/benchmark.php?test=all...
Это оно в теории вырастет, а на практике код чаще поддерживается чем пишется, и поддерживается зачастую совсем другими людьми, один выиграл при написании а потом трое трахаются с незнакомым языком, плавали, знаем, и спецов под конкретный язык при их зоопарке искать гораздо сложнее. Вообще языков конечно должно быть много, но не в мэйнстриме.Ну уж не досуг анализировать как они там ухитрились получить слив от js в сотни раз, даже старые дремучие perl/php так не сливают, я же проверяю на элементарных сравнимых операциях:
node 0.8.8 x64, MS VS 2012, Q9400 1 core
--------------------------------------------------
int64_t i, j;
j = 0;
for (i = 0; i < 10000000000; i++) {
j++;
}
printf("%I64d", j);= 13 сек
--------------------------------------------------
var j = 0;
for (var i = 0; i < 10000000000; i++) {
j++;
}
console.log(j);= 18 сек
--------------------------------------------------
int64_t i, j;
j = 0;
for (i = 0; i < 2000000000; i++) {
if (i > 600000000) j++;
if (i < 1000000000 && j > 200000000) j++;
if (i > 1400000000 || j > 600000000) j--;
}
printf("%I64d", j);= 14 сек
--------------------------------------------------
var j = 0;
for (var i = 0; i < 2000000000; i++) {
if (i > 600000000) j++;
if (i < 1000000000 && j > 200000000) j++;
if (i > 1400000000 || j > 600000000) j--;
}
console.log(j);= 11 сек
и т.п. В среднем нода уступает 30%.
На таких же элементарных примерах сравнивал расход памяти, если юзать нетипизированные массивы то раза в 3 больше, если типизированные то совершенно одинаково.
а никто не говорит, что в одном проекте обязатлеьно должна быть пачка языков (хотя два-три - часто выгодны).А в тестах - разница в том, что у вас чистейшая синтетика, которая идеально преобразуется JIT'ом. Джависты примерно на таких же примерах то же самое показать пытались - а на практике тормоза джава-софта невооруженным глазом заметны, и чем больше приложение - тем более заметны (особенно когда GC всё же вступает в дело).
Хотя если есть желение - возьмите исходники с шутаута, чем черт не шутит - может правда в условиях начудили.
Ну вот по моему языки только на простейшей синтетике и можно сравнивать, а как только реал начинается так тут уже не столько от языка начинает зависеть сколько от соответствия задачи и программиста)Таже жаба например, есть такое подозрение что большая часть ее тормозов связанна не столько с тормозами машины сколько с тараканами в головах разрабов, их идеалогией, ну и честно надо сказать с требованиями ынтерпрайза тоже) Вся эта их мегаобъектность, меташаблонность, ормы и т.п, вся эта куча прослоек, защит и расширений икается.
Ну или иначе не знаю, какие еще могут быть причины? Если исходные кирпичи/раствор одинаковые (а те тесты что я привел это какраз и есть исходные кирпичи) то почему у одних из них получается нормальный дом а у других сыпется?
Хз, может быть еще из-за того что теже сишники например вынуждены постоянно следить за тем что делают, ибо прощелк на любом уровне тут же все завалит, а у др. есть возможность расслабится)
Насчет жабы и сишников согласен, но вот насчет простейшей синтетики и кирпичей/раствора - не особо. Потому что
1) в ваших тестах одна математика - а в нынешнем софте она отнюдь не доминирует. А что-нибудь вроде стоимости вызова функций, создания объектов и т.д. вы не меряли.
2) разные языки провоцируют разный стиль. То чо в плюсах решится объектом в джаваскрипте окажется замыканием, где-то будет лок, а где-то - коллбек и т.п. В этом смысле шутаут как рза очень показателен - берем пачку релаьных задач и стараемся на каждом языке какждую задачу решить побыстрее - любой ценой. Учитывая, что варианты решения принимаются извне и лучщее решение заменяет худшее - на криворукость авторов результат не спишешь, остаётся винить конкретный язык или его реализацию. Ну ещё опции запуска иногда - но здесь хозяин идёт на встречу охотно, насколько я помню.3) то что оптимизатор справился с очень предсказуемым кодом, повторяющимся миллионраз - не показатель, что он справится с несинтетическим случаем, когда логика чуть сложнее, или что-то вклинивается в цикл, и т.п.
Хорошо, мне тоже интересно, возможно ошибаюсь, вечером потестирую еще, выложу, но по шутауту не согласен, 10 сишников это 10 голов, каждая со своим опытом и оптимизацией, а 1 jsник это один jsник, ну вы поняли.
чем меньше, блин, сишный код «оптимизируют», тем лучше (понятно, это не касается вещей типа замены сортировкой «пузырьком» на нечто более вменяемое).
не надо слов, покажи класс брат
> не надо слов, покажи класс браткакой? ты считаешь, что сумеешь микрооптимизациями обскакать хороший компилятор? ну, вперде. желаю потом весёлого квеста в поддержке такого кода.
а я тебе просто желаю счастья и не лезть не в свое)
> и не лезть не в свое)я и не лезу. а вот «мегопрограммисты» лезут почему-то постоянно. и очень удивляются, когда им говоришь, что их код — неподдерживаемое гуано, и работать они конечно будут, но точно не у нас.
int64_t t(int64_t a) {
return a + 2;
}int64_t i, j;
for (i = 0; i < 3000000000; i++) {
j = t(i);
}
printf("%I64d", j);= 6 сек
--------------------------------------------------
function t(a) {
return a + 2;
}for (var i = 0; i < 3000000000; i++) {
var j = t(i);
}
console.log(j);= 9 сек
тут есть момент, до 3G итераций нода выигрывает в 1.5 раза, после - резко ступенькой начинает проигрывать в 2, далее с увеличением кол-ва итераций разрыв не растет.
Сравнимого примера работы с объектами родить не смог, статические объекты сей рвут js'ную динамику как тузик грелку! десятки раз, теоретически тут надо сравнивать с <map>, но практически это наверное в пользу бедных, объекты используются часто, и если их много то общий слив может быть весьма приличным.
Далее тест на GC и память:
int64_t i, j;
vector<int> *p[100000];for (i = 0; i < 100000; i++) {
p[i] = new vector<int>;for (j = 0; j < 50000; j++) {
p[i]->push_back(j);
}if (i > 2000) { delete p[i - 2000]; }
}30 сек 480Мб
--------------------------------------------------
var s = [];for (var i = 0; i < 100000; i++) {
s[i] = new Int32Array(50000);for (var j = 0; j < 50000; j++) {
s[i][j] = j;
}if (i > 2000) { s[i - 2000] = null; }
}22 сек 530Мб
в диспетчере по динамике памяти видно что GC работает, объем памяти достаточно быстро стабилизируется, правда у ноды его колбасит на протяжении всего процесса +/- 100Мб, что в общем то понятно, кроме того есть милая фишка - если у ноды закомментить последнюю строчку с очисткой то она насмерть вешает винду, в дрова, только аппаратный сброс)
Поторопился, разобрался, с объектами таки не все так плохо:class c {
public:
int64_t x;
c(int64_t v);
};c::c(int64_t v) {
x = v;
}c *p[10000001];
int64_t i, j;
j = 0;
for (i = 0; i < 100000000; i++) {
p[j] = new c(j);
p[j]->x++;j++;
if (j > 10000000) j = 0;if (i > 10000000) delete p[j];
}11 сек 200Мб
--------------------------------------------------
o = [];
var j = 0;
for (var i = 0; i < 100000000; i++) {
o[j] = {
x: j
}
o[j].x++;
j++;
if (j > 10000000) j = 0;if (i > 10000000) o[j] = null;
}19 сек 700Мб (в процессе периодически колбасится от 400 до 900, - работает GC)
Данный вариант (без методов) наиболее употребим в JS т.к. в нем нет структур и они реализуются объектами, но без ложки дегтя всетаки не обошлось, если к JS объектам добавлять методы (функции) то они начинают существенно проигрывать, причем тем больше чем больше функций, при добавлении 1 - в 4 раза, 3 - в 7 раз и т.д. Это конечно печально, но и сравнивать тут в прямую нельзя, в плюсах методы статические, в JS же - динамические, их код может формироваться в ходе исполнения, как говорится 2 большие разницы.
Так что остаюсь при своем мнении что в общем JS проигрывает совсем не много (при соответствующем применении) но засады есть, где ж их нет, их надо знать, также надо не забывать что типизация в JS находится в зачаточном состоянии - может вылезти некоторый перерасход памяти. Производительность в большинстве тестов +/-1.5 раза, расход памяти от аналогичного до 3-5 раз больше, по моему все это весьма не плохо, тем более для динамического языка)
> Согласен, но отсутствие необходимости явной компиляции и приведения типов экономит время,...кроме случая когда программер зеленеет пытаясь поймать редкий баг, а на JS такое сплошь и рядом попадается. Так по опыту :)
> …кроме случая когда программер зеленеет пытаясь поймать редкий баг, а на JS
> такое сплошь и рядом попадается. Так по опыту :)волшебное слово: «тесты». не, не слышал?
> Конечно потерял, я вам про <font> же говорил уже, и далеко не
> он один.Вот только это ни на что не влияет. Влепи правильный доктайп и верстай соблюдая его стандартны. С выходом HTML5 все его предыдущие версии ни кто не отменял и поддержку из браузеров не удалял. Главное скажи браузеру какой версии HTML ты используешь.
А язык разметки от этого изменения только избавился от лишнего мусора, которому в разметке вообще не место.
> У Хрома тоже шустрый JS движок. Даже шустрее фокса. Хром тоже тормозной
> по-дизайну, раз ему такой движок сделали?А у хрома тормозят другие вещи. Например, загрузка страниц. Хрен знает почему, но у лисы пайплайнинг намного лучше отрабатывает.
> На какие только извращения не пойдёшь, чтобы ускорить нечто тормозное by designВ общем, да. HTML+JavaScript не особо предназначены для создания десктопных программ. А ведь это сейчас народ и пытается на них делать.
---------------------------------------------------------------------------------
Мне, кстати, непонятно такое: разница между движками 20%. Это совершеннейшие копеечки. Практически ошибка эксперимента. И был ли смысл огород городить?Ещё два раза куда бы то ни шло. Хотя тоже не сильное обоснование менять движок.
> HTML+JavaScript не особо предназначены для создания десктопных программА QML+JS?) Смотря что вы подразумеваете под десктопом. Для интерфейсов и клиентов в общем, HTML/QML/JS+обвеска типа дома/ноды по моему самое то, кросплатформенно, без лишних заморочек, и весьма немалую обработку тут же прикрутить можно, в т.ч. и серверную если на ноду посмотреть. А вот чтото чисто системное или совершенно жестко цифродробильное, типа скажем драйверов, или там СУБД, конечно не их, ну так ниша и без этого есть, на той же делфе с 98г пишу по сей день, казалось бы куда более удобно для таких целей, ан нет, на HTML+JS всеже приятнее получается, а в последние 3 года так и вообще не хуже.
> А QML+JS?)JS, как динамически типизируемый язык плохо предназначен для создания больших программ. Он хорош там, где нужны маленькие скрипты.
Впрочем, сейчас, в связи с распространением языков с автоматическим выводом типов, и в скриптах вполне можно использовать языки со строгой типизацией. Например, слегка подпилив OCaml (в сторону упрощения) можно сделать отличный скриптовый язык для замены sh.
Кроме того, вы разве компилируете программы на JS? Вы проводите его статический анализ? А ведь этот анализ значительно упрощается и легче ловит ошибки, если язык типизированный.
В общем, вы забыли упомянуть, что за связкой QML+JS стоит старый, древний, костыльный, но всё-таки приспособленный для создания больших программ, С++.
Проблема больших программ это проблема древних как оно мамонта сей, когда нет модульности и указатели по всему адресному пространству процесса, а когда у вас модульность и нет средств залезть в другой модуль кроме как через официальный интерфейс, то этой проблемы нет, я не хочу сказать что в JS с этим нет проблем, тоже есть свои грабли, но вообще это проблема другого уровня.
> Проблема больших программ это проблема древних как оно мамонта сей, когда нет
> модульности и указатели по всему адресному пространству процесса, а когда у
> вас модульность и нет средств залезть в другой модуль кроме как
> через официальный интерфейс, то этой проблемы нетЭто как это нет? Ну разделили вы на модули и что? Библиотека хочет целое число, а вы случайно туда передаёте строку. Если этот код очень редко выполняется, на стадии тестирования у вас есть большие шансы пропустить ошибку. В то же время любой статически типизируемый язык ловит такое на стадии компиляции.
Ну и не надо думать, что все языки на С++ и закончились. JS должен не с ними конкурировать, а со всякими F# и т.д.
Ну вот нет, по определению, потому что модуль обязан проверять входящие данные в динамике, а не уповать на состояние во время компиляции а потом вдруг падать наглухо если левое подсунут, он должен писать ошибку в лог и продолжать, впрочем практические плюсы у статики конечно есть, я же говорил, не отрицаю, но у динамики есть свои)А с тем что JS не должен конкурировать с сями я полностью согласен, вот с плюсами уже спорно, ибо у них понтов слишком дофига)
> Ну вот нет, по определению, потому что модуль обязан проверять входящие данные
> в динамикеНу проверит, поймёт, что ему 4999 раз выдавали целое, как надо, на 5000-й раз передали строку. И что дальше он будет делать с этой строкой - неправильным типом? Программа-то тогось. Самое разумное, что можно сделать - это вывалиться с ошибкой.
А со статической компиляцией вы бы такой ляп исправили бы ещё до тестирования. Компилятор вывел и проверил типы. И всё.
Ещё раз, статическая типизация совершенно не означает, что вы везде должны указывать тип. В подавляющем большинстве мест в современном языке тип выражения компилятор определит сам.
И, фактически, для вас динамическое типизирование от статического с системой вывода типов отличается только тем, что в паре мест типы нужно привести явно, да компилятор в статике проверит корректность вывода типов. Всё остальное - такое же.
Это при жесткой статике когда нет рантаймовых проверок она тогось, с переполнениями, затираниями, нарушениями доступа и пр. прелестями, а при нормальных раскладах проверила, обматюкалась куда положено, и поехала дальше.И хрен компилятор проверит типы, т.к. входные данные это динамика из вне, проверки по любому нужны. Внутри же модуля, когда вы работаете с уже проверенными данными, статические проверки - не пришей кобыле хвост, ибо нормальный небольшой модуль решает строгую простую задачу и косяконуть с типами сложно, в крайнем случае это выявится при первом же прогоне.
Запросто накосячить- софт же развивается и требования к параметрам меняются. А если нет типов - проследить, что из одного модуля в другой транзитом именно нужный объект пришел сложновато. А если промежуточных штук шесть, да еще разными могут быть - легче просто помолиться. Особвнно учитывая идиотские джаваскриптовые преобразования типов.
Да накосячить можно где угодно, при жесткой типизации также, изменили вы например размер поля, в некой структуре памяти, в середине цепочки, и писец, все обвалится, и проследить потом так же, легче помолиться, ибо придется пошагово раскручивать с самого начала.
Напишете то же самое на каноничном D (да, на нём системщину можно писать) - он ругнётся. Это вам как раз хреновая типизация сей в ногу стреляет. Наверняка и ещё пара языков кроме D найдётся, которые нужные типы описать дадут.
P.S. Собственно, даже в сях битовые поля никуда не девались, и так просто начудить вроде и не выйдет, разве что извне откуда-то структуру принимаете в виде массива или void*.
О том и говорил, см. выше, входные данные это динамика из вне
> И хрен компилятор проверит типы, т.к. входные данные это динамика из вне,
> проверки по любому нужны.Нужны. Но статический анализ идёт в дополнение к этому. Понимаете - в обычном компилируемом языке - как бесплатное дополнение.
Есть ещё лучше ситуации. Вы приняли какую-то пачку параметров (как водится в JS - объектом) и отдаёте её ещё одному модулю (возможно после некоторых преобразований). А потом у него изменяются требования и эта пачка параметров должна быть несколько другой - например обязательный параметр добавился. Согласовать эти три модуля, чтобы всё корректно во всех случаях отдавали в большом проекте - врагу не пожелаешь. Никакое тестирование не помогает при вложенности коллбеков эдак в десятку - тупо не сделаешь все mockup'ы.
Ровно на такие же как сделать нечто тупое by design более человечным)
Интересно прирост скорости на WebGL тоже отразиться..
> Интересно прирост скорости на WebGL тоже отразиться..Сильно зависит от того во что сцена упиралась. Если в JS то отразится. Правда, может быть, тогда это сигнал к тому что надо выпустить нормальную версию на си++? Оно там нахаляву раз так в эн подтянется хотя-бы просто за счет статической типизации и прочая :)
> эн подтянется хотя-бы просто за счет статической типизации и прочая :)вот привязался же к «статической типизации», а… да не даёт она мегавыигрыша в долгосрочке, не даёт. все нормальные JIT'ы сейчас способны собрать статистику и сгенерировать один/несколько вариантов кода функции для разных типов. а в простейших случаях и так выводят.
алсо: удачи тебе — с твоей типизацией — в универсальной реализации базовых алгоритмов. ну, например, qsort: правда ведь, няшный костыль получился?
впрочем, я понимаю: алгоритмы переписывать под новые типы нескучно. и разбираться в выхлопе шаблонизатора (который ещё и компилируется в час по чайной ложке) тоже: ведь не зря шаблоны — тюринг-полный функциональный язык, правда?
Интересно узнать: представленные результаты тестов нового движка лучше конкурентов? Я имею в виду Opera и Chrome.
21 хром обгоняет 14 фокса по моим прикидочным тестам приблизительно раза в 2, ну и многие также около того отзываются, таким образом рост производительности на 20-25% кардинально не решает, но всеже приятно)
Жалко. Интересно было бы узнать мнение людей. Огнелис, и громоптица, мореобезьяна.. (Кто там говорил про зоопарк?)неплохо звучат. Но Серьезному браузеру - достойное имя!
Internet Explorer. Серьёзней некуда.
> Internet Explorer. Серьёзней некуда.Разведчик интернета. Почему разведчик? Потому что влобовую биться очкует - слишком очевидно неравенство сил :)
Пока весь фокс - всего лишь один процесс, тормоза обеспечены, ускоряй жабаскрипт, не ускоряй...
Вот тогда он точно от гига жрать будет)
Землю-крестьянам! Заводы-рабочим! Ребенку-многопроцессорность!
И как мы раньше жили без этого? А тут прям все. Тупик. И жизни дальше нет.
Гражданин, залезьте обратно в свой ДОС.
Если кто не в курсе:1) в браузере куча интерпретируемого кода, который для операционки виден как данные. Этот код не шарится между инстансами. То есть зазря пропадает память.
2) у потоков общая память, что шутсрее любого IPC (даже быстрее shared memory у профессов, AFAIK - но браузерным процессам shared memory может сделать только полный кретин - замучаешься синхронизировать, да и выгод от изоляции не получить).
> Пока весь фокс - всего лишь один процесс,Мсье, один процесс может запускать более одного треда, внезапно. Используя более 1 CPU. Кстати веб-воркеры в FF уже умеют использовать все ядра процессора, что прекрасно видно например в бенчмарке Peacekeeper (та часть где параллельный обсчет нескольких картинок с разной яркостью).
Вышла финальная версия Firefox 18 - http://compforgames.ru/download/browser/firefox_18/
